Ok... after some researching:
(0.90.0000 hboot + 7.54.39.08M radio + 4K partition layout phone) look for the 6th bit at 0x201C in the misc partition. If it is '1' then we got s-on. If it is '0' we got hboot s-off.
So.. 2*, 3*, 6*, 7*, A*, B*, E*, F* would be also doing s-on.
It is possible that other hboots + radios have also that "hboot s-off flag"?
Filling all misc with FF or 00 doesn't do that so that mechanism doesn't exist or it's more complicated.
(0.90.0000 hboot + 7.54.39.08M radio + 4K partition layout phone) look for the 6th bit at 0x201C in the misc partition. If it is '1' then we got s-on. If it is '0' we got hboot s-off.
So.. 2*, 3*, 6*, 7*, A*, B*, E*, F* would be also doing s-on.
It is possible that other hboots + radios have also that "hboot s-off flag"?
Filling all misc with FF or 00 doesn't do that so that mechanism doesn't exist or it's more complicated.
Last edited:
I cannot explain this behaviour, however the "actual" secu_flag is not in "misc". In fact it's not anywhere in the "virtual NAND" that HBOOT and Android see. If you binary-compare the entire address space that aARM sees on a phone before and after achieving "Radio S-OFF" via xtc-clip, the only change you'll see is that the backup CID is erased from "misc". Everything else is bit-identical. The secu_flag resides in Iguana and cannot be accessed by aARM. The ways for achieving S-OFF are either ...
1. ... authenticate with Iguana so that it disables security. This is what xtc-clip does, but the authentication cannot be done in software.
2. ... flash Iguana so that it's S-OFF. Don't know if this is possible in software, since I don't know how updates for Iguana are performed.
3. ... make HBOOT never query Iguana for the status of the flag. This works in principle as is proven here, but the status doesn't "stick". "Something" (Iguana? HBOOT itself?) always "restores" an "original" HBOOT image after a very short period of time if you modify something in the HBOOT code. If we find the code where this happens we can most likely do something about it.
That "misc mechanism" probably only works with that strange "special" Radio. I don't have the phone anymore, but there definitely wasn't a single non-zero byte surrounded by many zero bytes somewhere in my "misc" partition and since you say bit unset (zero) is S-OFF, it would have to be set, since my phone was S-ON.
EDIT: Ah, I forgot. HBOOT must restore itself. If you overwrite HBOOT with some code that's really different from an HBOOT (say you overwrite it with no-operations and a jump back to the beginning), there's no HBOOT restored to that memory (and the infinite loop runs forever on aARM). So yes, we can definitely do something about it since we can overwrite the entire HBOOT via this "chainloader" exploit. We "only" have to find where this happens in the HBOOT. And it would be best if we could find it in the 1.09.0099 HBOOT since that's the one we've done the most analysis for.
1. ... authenticate with Iguana so that it disables security. This is what xtc-clip does, but the authentication cannot be done in software.
2. ... flash Iguana so that it's S-OFF. Don't know if this is possible in software, since I don't know how updates for Iguana are performed.
3. ... make HBOOT never query Iguana for the status of the flag. This works in principle as is proven here, but the status doesn't "stick". "Something" (Iguana? HBOOT itself?) always "restores" an "original" HBOOT image after a very short period of time if you modify something in the HBOOT code. If we find the code where this happens we can most likely do something about it.
That "misc mechanism" probably only works with that strange "special" Radio. I don't have the phone anymore, but there definitely wasn't a single non-zero byte surrounded by many zero bytes somewhere in my "misc" partition and since you say bit unset (zero) is S-OFF, it would have to be set, since my phone was S-ON.
EDIT: Ah, I forgot. HBOOT must restore itself. If you overwrite HBOOT with some code that's really different from an HBOOT (say you overwrite it with no-operations and a jump back to the beginning), there's no HBOOT restored to that memory (and the infinite loop runs forever on aARM). So yes, we can definitely do something about it since we can overwrite the entire HBOOT via this "chainloader" exploit. We "only" have to find where this happens in the HBOOT. And it would be best if we could find it in the 1.09.0099 HBOOT since that's the one we've done the most analysis for.
Last edited:
I rather thought about that may be two sec flags: h-boot s-flag and radio s-flag (master s-flag). You are right about "that strange "special" Radio" but why it works only with the 0.90.0000 hboot? 
BTW...
Look how the hboot is written in NAND. There is a lot of small differences... You use a raw hboot image but what if you could try with the hboot image extracted from the jtag dump (WildFireS_Full_alive.bin)? Maybe that causes restoring in your exploit?
RAW HBOOT IMAGE VS HBOOT from JTAG DUMP
BTW...
Look how the hboot is written in NAND. There is a lot of small differences... You use a raw hboot image but what if you could try with the hboot image extracted from the jtag dump (WildFireS_Full_alive.bin)? Maybe that causes restoring in your exploit?
RAW HBOOT IMAGE VS HBOOT from JTAG DUMP
Last edited:
(emphasis by me)(0.90.0000 hboot + 7.54.39.08M radio + 4K partition layout phone) look for the 6th bit at 0x201C in the misc partition. If it is '1' then we got s-on. If it is '0' we got hboot s-off.
Yes there are indeed two checks done, and you may have just shed some light on the second one!
The following code shows the whole of the secu_flag check in the 0.90 hboot, edited to show the program flow:
Code:
9D008698 STMFD SP!, {R4,LR} ; Save registers
9D00869C BL sub_9D04414C
9D04414C STMFD SP!, {R4,LR} ; save registers
9D044150 BL sub_9D04CE00
9D04CE00 STR R4, [SP,#var_4]!
9D04CE04 LDR R3, =0x9D086A8C
9D04CE08 LDR R4, [R3] ; R4 = 0xBD100000
9D04CE0C ADD R4, R4, #0xFC000 ; R4 = 0xBD1FC000
9D04CE10 ADD R4, R4, #0xA0 ; R4 = 0xBD1FC0A0
9D04CE14 LDR R0, [R4] ; value from 0xBD1FC0A0 into R0
9D04CE18 AND R0, R0, #1 ; clear all but 1st bit
9D04CE1C LDMFD SP!, {R4} ; restore registers
9D04CE20 BX LR ; return
9D044154 LDMFD SP!, {R4,PC} ; return again
9D0086A0 CMP R0, #0 ; if R0 is not 0...
9D0086A4 MOVNE R0, #1 ; ...load 1 into R0 ...
9D0086A8 LDMNEFD SP!, {R4,PC} ; ...and return
9D0086AC BL sub_9D00769C ; if the first check passed...
9D00769C STR R4, [SP,#var_4]! ; save registers
9D0076A0 LDR R3, =dword_9D07A2DC ; = 0x60303000
9D0076A4 LDR R4, [R3] ; R4 = 0x60303000
9D0076A8 LDR R3, =0x101C ; load the offset
9D0076AC LDR R0, [R4,R3] ; value from 0x6030401C into R0
9D0076B0 LDMFD SP!, {R4} ; restore registers...
9D0076B4 BX LR ; ...and return
9D0086B0 MOV R0, R0,LSR#5 ; shift to the right 5 times
; (move the 6th bit into 1st)
9D0086B4 AND R0, R0, #1 ; clear all but 1st bit
9D0086B8 LDMFD SP!, {R4,PC} ; returnThe interesting part is the second, at 0x9D00769C: loads a base address, adds the offset, and returns the 6th bit (!) of the value at 0x6030401C. It seems to be the "misc check", and if that fails, the end result of the secu_flag check will still show "s-on", it doesn't matter if you have radio s-off or not! The interesting info is that the misc partition (or at least part of it) is mapped in from the virtual address 0x60302000. :laugh:
This makes me think that the "jtag dump" is not accurate. I used the hboot's own built-in memory dump routine to extract the RAM content, and that dump is the exact match of the raw hboot data. Could you have a look at how often the differences occur? They seem to follow a pattern, like after every 0x200 bytes one 4-byte block is missing or something. EDIT: the missing bytes you highlighted are part of the page table and if they were really missing the whole thing wouldn't work. So the dump must be inaccurate.
Last edited:
Well, like I said, unfortunately I can't test anymore since I don't have the phone anymore. However, I think that the HBOOT that aARM "sees" (remember that this is not what's actually in NAND - for example the Radio code that aARM sees looks VERY different compared to the code that's actually stored in NAND) is the same that is in the nb0 and not what is in the JTAG dump (and therefore probably in physical NAND). But like I said I don't have the phone anymore so I actually cannot verify anything at the moment.
We have KNOWN for some time that they perform two checks, but why? Is it for easier testing? Their developers probably test on Radio S-OFF devices. Do they perform this "misc"-check to allow their devs to easily enable security temporarily on their devices by changing a bit in the "misc" partition?
We have KNOWN for some time that they perform two checks, but why? Is it for easier testing? Their developers probably test on Radio S-OFF devices. Do they perform this "misc"-check to allow their devs to easily enable security temporarily on their devices by changing a bit in the "misc" partition?
Last edited:
What happened to your phone?
The micro-switches were worn out. It was still usable, but I decided to send it to HTC to have it fixed before the warrenty period ends. However, they said that the board on which it is based is no longer produced by their supplier, so they can neither replace the board on it nor manufacture new devices of this type, so the device is basically discontinued. Since they don't have any devices left in stock, they could not send me a replacement device either, so they offered me a refund of the entire price I paid for it. Good news for me, as I basically had a phone now for one and a half years basically without paying anything for it, but it also means that I don't have access to the device anymore.
I'm on a Samsung Galaxy Nexus now. As you know that one's based on an OMAP4460 chipset, which has absolutely no security in place, so there's currently nothing I could hack.
Thanks BeciMester for explaining it to me.
I agree. Munjeni also said that. So that jtag dump may be proper.
BTW...
In the 1.09.0099 hboot, the whole value from 0x201C is used in two other places... @BeciMester do you know what for?
@n.h.b That's sad Hope you don't leave this thread... If you want I can send you one of my phones
----------------------------------
EDIT:
About comparing:
Yes, 90% is the some kind of pattern.
3% part from whole:
Bigger parts of non matched data:
Some insertion and all deletions:
no.human.being said:
I agree. Munjeni also said that. So that jtag dump may be proper.
BTW...
no.human.being said:
In the 1.09.0099 hboot, the whole value from 0x201C is used in two other places... @BeciMester do you know what for?
@n.h.b That's sad
Hope you don't leave this thread... If you want I can send you one of my phones ----------------------------------
EDIT:
About comparing:
Yes, 90% is the some kind of pattern.
3% part from whole:
Bigger parts of non matched data:
Some insertion and all deletions:
Last edited:
I first thought it may be proper, as I thought that JTAG had the stuff "inserted", so I thought that it might be some sort of redundancy that is created when HBOOT is written to NAND and stripped off again when loaded by the SBL, but now I've seen that the stuff is MISSING from JTAG but is THERE in the nb0, so I no longer think that it's proper. We can be quite sure that what's in the nb0 is what actually gets executed. This is what happens in HBOOT-0.90.0000 (nb0 version) after the MMU was set up.
Code:
4d4: e59f0010 ldr r0, [pc, #16] ; 0x4ec
4d8: e3500000 cmp r0, #0
4dc: ee011f10 mcr 15, 0, r1, cr1, cr0, {0}
4e0: e1a0f000 mov pc, r0
4e4: e1a00000 nop ; (mov r0, r0)
4e8: fff00000 ; <UNDEFINED> instruction: 0xfff00000 ; IMB
4ec: 9d000800 stcls 8, cr0, [r0, #-0]See that it jumps to 0x9d000800 virtual, which is 0x800 inside the nb0. There's the code that zeroes the BSS, then jumps to 0xbc8 ("main").
Code:
800: ea000001 b 0x80c
804: 9d0798d0 stcls 8, cr9, [r7, #-832] ; 0xfffffcc0
808: 9d08d324 stcls 3, cr13, [r8, #-144] ; 0xffffff70
80c: e51f0010 ldr r0, [pc, #-16] ; 0x804
810: e51f1010 ldr r1, [pc, #-16] ; 0x808
814: e3a02000 mov r2, #0
818: e5802000 str r2, [r0]
81c: e2800004 add r0, r0, #4
820: e1500001 cmp r0, r1
824: 1afffffb bne 0x818
828: e59fd37c ldr sp, [pc, #892] ; 0xbac
82c: ea0000e5 b 0xbc8So let's have a look at what's at 0xbc8.
Code:
bc8: e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr}Mmh, saves a lot of registers to the stack. Looks much like the beginning of a function (in fact it's function "main"). So far we've had one branch from 0x9d0004e0 to 0x9d000800 and one branch from 0x9d00082c to 0x9d000bc8 and they all ended up where we expected them.
Contrary, in your JTAG dump 4 bytes are missing at 0x202 to 0x205 and 0x40d to 0x410. That means that this thing at 0x9d000800 would actually be 8 bytes "earlier", at 0x9d0007f8. Thus setting the program counter to 0x9d000800 would actually end up two instructions "after" what we see inside the nb0 at 0x800. It would branch to what we see as 0x808. At this offset there is the word 0x9d08d324, which is clearly a virtual address and not an instruction.
Forget the JTAG dump, it's screwed.
The micro-switches were worn out. It was still usable, but I decided to send it to HTC to have it fixed before the warrenty period ends. However, they said that the board on which it is based is no longer produced by their supplier, so they can neither replace the board on it nor manufacture new devices of this type, so the device is basically discontinued. Since they don't have any devices left in stock, they could not send me a replacement device either, so they offered me a refund of the entire price I paid for it. Good news for me, as I basically had a phone now for one and a half years basically without paying anything for it, but it also means that I don't have access to the device anymore.
I'm on a Samsung Galaxy Nexus now. As you know that one's based on an OMAP4460 chipset, which has absolutely no security in place, so there's currently nothing I could hack.
No!! Chances of s-off our wfs will be gone
Sent from my HTC Wildfire S A510e using xda app-developers app
No!! Chances of s-off our wfs will be gone
Sent from my HTC Wildfire S A510e using xda app-developers app
yes and the world will burn in flames in december 2012 ...
stay on the ground. many people contributed in this thread. many without even owning a wfs. so don't cry
There is bound to be JTAG for the htc wildfire s specifically. I think the JTAG nhb got was a more generic arm jtag . But if we could get a specific JTAG for the marvel we would at least have a chance. Maybe we could all chip in and get it?
Sent from my HTC Sensation using xda premium
---------- Post added at 03:04 AM ---------- Previous post was at 02:51 AM ----------
http://www.fonefunshop.co.uk/cable_picker/94954_RIFF_Box.html
I have found this, and I saw an Adapter for the marvel as well. What do we think guys? Who here still has the device and the will to get this done?
Sent from my HTC Sensation using xda premium
Sent from my HTC Sensation using xda premium
---------- Post added at 03:04 AM ---------- Previous post was at 02:51 AM ----------
http://www.fonefunshop.co.uk/cable_picker/94954_RIFF_Box.html
I have found this, and I saw an Adapter for the marvel as well. What do we think guys? Who here still has the device and the will to get this done?
Sent from my HTC Sensation using xda premium
For the JTAG interface, you usually want to ensure that it's supported by OpenOCD (that's the debugging software). Many interfaces do not support actual "debugging" but merely "programming". This will be sufficient if you want to dump and modify NAND content, but with "debugging" capable interfaces you'll also be able to, well, debug the system code, which, while not absolutely neccessary under all circumstances, will of course be very nice to track what's actually going on inside the phone.
With a "debug capable" interface you can e. g. "trap" Iguana when it reaches a specific instruction (breakpoint) and then single-step it, etc. It's like the entire system was running inside a debugger. The interface I have is based on an FTDI FT2232 UART chip. It's capable of "debug mode", but, well, the voltages don't match.
Yeah, kinda. Say around 60 € for interface + adapter. And MAY you also need additional equipment (cables, clamps, resistors, regulated DC supply, ...) to get the device to boot. I don't think it's neccessary for programming, but it's almost certainly for debugging.
But probably the biggest problem is that, unless there is an interface that can work with 0.9 V targets and does support debugging (I found none) your only chance seems to be "handcrafted" circuitry. However, doing it all with discrete FETs will be a mess (end relatively expensive). It'd be much easier (and cheaper) if there was an "integrated" (IC) solution one could use, but none seems suitable. It's really strange, as I think there have to be a bunch of people that want to debug a low-voltage ARM11, but you really don't find anything about it. It's all for, say, 2.0 - 3.3 V.
Of course apart from a few that appearently work but may not support debugging.
With a "debug capable" interface you can e. g. "trap" Iguana when it reaches a specific instruction (breakpoint) and then single-step it, etc. It's like the entire system was running inside a debugger. The interface I have is based on an FTDI FT2232 UART chip. It's capable of "debug mode", but, well, the voltages don't match.
Are they expensive? Or will it just not work with jtag? Yes... I know of the voltage problems... I have been following this thread. But can we fix that?
Yeah, kinda. Say around 60 € for interface + adapter. And MAY you also need additional equipment (cables, clamps, resistors, regulated DC supply, ...) to get the device to boot. I don't think it's neccessary for programming, but it's almost certainly for debugging.
But probably the biggest problem is that, unless there is an interface that can work with 0.9 V targets and does support debugging (I found none) your only chance seems to be "handcrafted" circuitry. However, doing it all with discrete FETs will be a mess (end relatively expensive). It'd be much easier (and cheaper) if there was an "integrated" (IC) solution one could use, but none seems suitable. It's really strange, as I think there have to be a bunch of people that want to debug a low-voltage ARM11, but you really don't find anything about it. It's all for, say, 2.0 - 3.3 V.
Of course apart from a few that appearently work but may not support debugging.
so are we stuck atm without being able to debug? so shall we hunt for a jtag that is up to the challenge or find an electrician to wire us up a "rig" capable to do the voltage changes?
Maybe we should harass Lauterbach as Qualcomm use them
GT540 - E320 is poorly
GT540 - E320 is poorly
Maybe we should harass Lauterbach as Qualcomm use them
GT540 - E320 is poorly
OpenOCD supports these. Lauterbach is not among them. Like I said, most are based on the FTDI FT2232 or FT2232H (mine is based on the latter) UART.
Note that this is only a list of interfaces that OpenOCD supports for debugging. First, you'll only be interested in the USB variants, since practically no computer still features a parallel port these days.
The interfaces listed are all sorts of interfaces for all sorts of processors, so not all of them are for ARM. Some are only for specific versions of ARM. E. g. the STM32 is an ARM-clone, but JTAG interfaces that are specifically for STM32 will probably not support other types of ARM, otherwise they would be labelled interfaces for ARM.
Some of the interfaces (e. g. Segger JLINK) are processors themselves, since JTAG can also be used for inter-processor communication. This is of course a bit "overkill" though, since you have an entire processor (with its own firmware) in the box. They may be more prone to failure than the "simpler" UART-based interfaces and they're probably more expensive.
The list will shrink very rapidly based on our needs. Also the 0.9 V voltage is extremely low. The lowest that the site mentions is 1.8 V which is still TWICE AS MUCH as what the MSM7227 uses.
Last, but not least, note that the site mentions the following.
So at least it does not appear to be uncommon to require level conversion between the processor and the interface, however, I haven't found a suitable converter yet. Of course 3.3 V (interface) <--> 0.9 V (processor/target) would be ideal, then you could use an FTDI2232H-based interface. They are high-speed UARTS and cost around 45 €.
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
59[DEV][THE S-OFF CAMPAIGN] We need electrical engineers & experts in JTAG, OpenOCD!
Progress so far:
DEVELOPERS!
THIS CAMPAIGN IS STILL GOING!
Please try to read the latest posts in this thread if you would like to help!
---
S-OFF is still needed! Don't get happy with your HTC unlocked bootloaders, you have no more warranty! You still can't resizie your system partitions! You still can't flash the hboot, and many other things! You can get your warranty back, if we crack S-OFF!!
Well I basically did a lot of of low-level (mostly hardware) stuff to the phone recently, not so much actual development. I found out how to configure OpenOCD (don't know whether the configuration is any good, since lots of values are more "good guesses" than actual knowledge but at least it's a starting point). I found how to get the board to boot without being attached to the Lithium cell which is not important for getting JTAG access (because this works as long as the board has power supply, being booted is not neccessary for JTAG to work) but will later be needed for tracing through the boot code, since the phone won't boot without what it thinks is a Lithium cell. However, I didn't get the debugger running yet. I suspect that the processor's logic level might be too low for the JTAG equipment. I don't really have an idea how to work around that yet, I might need to build a circuit that boosts the processor's JTAG signal to the appropriate voltage level (a so-called "level-shifter").
Apart from that munjeni and Antagonist42 also seem to make progress, but I must admit that I wasn't really able to keep track of all the things that they were doing recently. So basically we're now down at the actual physical layer and messing around with the electrical stuff that's going on on the phone's board and trying to find a way of actually talking to the processor to get the on-chip debugging working.
The far goal will be getting a patched HBOOT that has signature verification removed loaded into the device's memory via JTAG, then flash a patched HBOOT image via Fastboot. If this works it will be the first S-OFF GSM WFS that's neither shipped S-OFF nor turned S-OFF via xtc-clip, but this might still be a long long way.35Get your Teeth into these
Do not PM requesting Documents unless.....
If you cannot satisfy the above, do not PM. Thank you
My DropBox is defunct :silly: , as i'm not now as active on XDA I will see about re-posting when I can get some time to sort it all out again (like my mind it's a mess ).... I'll leave page as-is until I can sort it out Thankyou for your patience... and thankyou dropbox for the total lack of any idea of what went wrong
QualcommRelease Info July 2010
Booting
Qualcomm Boot VM984
File Systems
Qualcomm Filesystem Overview
ARM sheets
ARM9 Compiled Framework - Translated
ARM926EJ-S pdf
ARM1136JF-S + J-S pdf
ARM Phone/PC/Chip Info doc
Qualcomm REX User Guide Rev C 2001
REX and common software
ARM9EJ-S r1p2 _ RETIRED _ DDI0222
ARM Architecture Reference Manual v6m _ DDI0194C
eMMC Electrical Standards
ARMv7
Architecture App Level Ref Manual v7-M
Architecture App Level Ref Manual v7-M
Architecture Ref Manual v7-M
ECC
Reed Solomon Error Correcting Codes - OhadRodeh
Qualcomm - System Boards / User System
MSM7xxx Q-Fuses and Security
USB Host Driver W2k/XP -80-V4609-1-Rev-E
Android Linux Device Bus Drivers
Qualcomm - AMSS / Radio ... non user
AMSS - D'ya wanna know how to?
AMSS Overview 7x27 EBI1 cfg Original pdf
AMSS Overview 7x27 EBI1 cfg Translated (roughly lol) rtf
AMSS/DMSS C Debug/Troubleshoot
CMX Overview 80-V1484-1 Rev H
AMSS Multimedia Concurrency
AMSS 6055/6065/6075/6085 Build Instructions and Environment
MSM7227 Info
MSM7200A Sales Datasheet
MSM7500 Sales Datasheet
TM7200 [Test Phone] Sales Datasheet
MSM7227/7227 - Turbo - Build your own!!! See Below For Chip Infos
MSM7227 Chip Training-Overview
MSM7227 modem pdf
Micron NAND information
Package Naming
Part Numbering
NAND or OneNAND + RAM pdf
Micron NAND 101
NAND Flash Memory for MT29F4G08AAA, MT29F8G08BAA, MT29F8G08DAA, MT29F16G08FAA
4Gb, 8Gb, and 16Gb x8 NAND Flash Memory Features
TN-29-16: Boot-from-NAND with the TI OMAP2420 Processor
TN-29-18: Booting from Embedded MMC
TN-29-13: Determining NAND Flash Ready/Busy Status
TN-00-25: Enabling a Flash Device into the Linux MTD
Samsung NAND information
512 NAND
K9K2G08(U/R)0A Datasheet
KFG1G16Q2M-DEB6 Datasheet
Lauterbach - NAND
NAND FLASH Programming User’s Guide
Board IC's
PM7540 Power Manager pdf
RTR6285 RF Transceiver IC pdf
RTR6285/6280 Specs pdf
RTR6285 RF SW Driver pdf
MSM7227 Boot doc - Chinese but mostly the actual android/linux we're after.
MSM7227 Boot - Translated (roughly) - doc
Qualcomm 7X27 Platform Training Summary - rtf
Contains Partition Info .Doc file
Program (Linux) Unsure of authenticity please be aware...
QualcommAuto Test - No idea, Linux OS, trying to find documentation.
MSM6025 QSC60x6
Data Sheet
Device Specification
User Guide
Chipset Training
MSM60x5 AMSS Secure Boot Overview
MSM60x5 AMSS Flash and Memory Layout
MSM60x5 AMSS Board Support
MSM6500
Chipset Training
Basband Ref Schematic
MSM7200/A
Software Interface Manual 80-VA736-2 Rev B
MSM7200A Chipset Training - Baseband Topics
MSM 7225
Device Specification 80-VF815-1 Rev E
MSM7625
MSM7625 Device Info pdf
MSM7627
MSM7627 RF Training pdf
MSM7627 SCHEMATIC pdf - try at your own peril
Training Baseband Topics-80vm151-25 - pdf
Training Baseband Topics-80vm151-25 - (plain text file) - pdf
SURF7627 Main Board Ref Schematic pdf
SURF7627 Platform User Guide
AMSS 7x27A Linux Release 2.0.35 (Modem, Multimode) for Android™
Platform-Enabled MSM7627A Devices Release Notes for M76XXUSNEKNLYM2035
MSM8260/8660
MSM8260/8660 Baseband Reference Schematic
APQ8060/MSM8260/8660 Mobile Station Modem
MSM8660 Voice/Audio Topology and Tools Overview
MSM8x60
MSM8X60 Modem Debug Guide
MSM8960
Schematic including PM8921 WCD9310
MSM8969 Boot Architecture
MSM8960 Chipset Training - Intro & Overview
QSC
QSC6240/QSC6270 Single Chip User Guide
MDM Series Chips
62+6600 User Guide
8200 User Guide
JTAG Info
AND72J v1.0 25.04.2011 doc
JTAG ETM Interface for ARM9
Lauterebach - ARM JTAG Interface Specifications
Program for JTAG
From above site - H-JTAG v2.1
H-JTAG User Documents
MSM Devices.
Lauterbach Dev Tools - Debugging Linux GDB Android
Trace32 Training not Qualcomm.
MSM7227 Schematic Chip Infos
B4B-PH-K_LF_SN
JST - PH Connector Info
CCM03-3013-LFT-R102
C&K Components - SIM Holder
CM1213-08MR
CMD California Micro Devices - 1, 2, 4, 6 and 8-Channel Low Capacitance ESD Protection Arrays
DTC124EE
ROHM Semiconductor - 100mA/50V Digital Transistors
DTC144WE
ROHM Semiconductor - NPN 100mA/50V Transistor
EMIF02-MIC02F2
ST Microelectronics - EMI/RFI Filter
HEC3650-018010
HOSIDEN Electronic Components - DC Power Jacks
IP4047CX6-LF
NXP (founded by Philips) - ESD protection EMI filter Level shifter and buffer
LP5900TL-3.3
Texas Instruments - Ultra Low Noise, 150 mA Linear Regulator for RF/Analog Circuits Requires No Bypass Capacitor
LT3465FA
Linear Technology - 1.2MHz/2.4MHz White LED Drivers with Built-in Schottky in ThinSOT
Linear Technology - High Efficiency ThinSOT White LED Driver Features Internal Switch and Schottky Diode – Design Note 325
MT46H32-64M16-32LF
Micron - Mobile Low-Power DDR SDRAM
NC7SP34L6X
Fairchild Semiconductor - TinyLogic ULP Single Buffer
NC7SZ74
Fairchild Semiconductor - TinyLogic UHS D-Type Flip-Flop with Preset and Clear
PACDN1404-D
On Semiconductor - ESD Protection Arrays in Chip Scale Package
ISP1362
USB Schematic Philips - Philips ISP1362 USB On-The-Go Expansion Board For Accelent IDP's
0522P_0524P
Semtech - Ultra Low Capacitance TVS Arrays
SI2333DS-T1-E3
Vishay Siliconix - P-Channel 12-V (D-S) MOSFET
ZXTD2M832
Zetex Semiconductors - MPPS Miniature Package Power Solutions DUAL 20V PNP LOW SATURATION SWITCHING TRANSISTOR
Programs
QXDM - 3.9.19 Still using 80-V1241-21 Rev. A November 21, 2001
With update info for Expected Differences Between QCAT Version 4 and QCAT Version 5 Output - 2006
QXDM Software Users Guide 80-V1241-21 X2 September 13, 2001
Other Stuff I have come across, passed on, may be of use/interest ...
Intel - Hex Addressing/Recording - Hexadecimal Object File Format Specification
LG VS930 Service Manual
LG KS20 Service Manual pdf - just for interest.
How the Dalvik Virtual Machine works
Qualcomm Rex Boot - Needs Translating though!
AMSS Doc Translated - rtf
Qualcomm OS Kernel Code REX Translated - rtf
Generate Release Version Android System Signature Translated - rtf
Translated Boot doc 1
Translated boot doc 2
Multi-Core Communication - Original txt pdf
Multi-Core Communicaton - Translated
Wavecom Open AT Firmware 7.4
Boot/Kernel Analysis Docs -
Simple Analysis Android Kernel rtf
Android Boot Proc 01 rtf
Android Boot Proc 02 rtf
Linux Kernel Porting (mini2440) rtf
Qualcomm Boot Analysis rtf
U-Boot Analysis rtf
A Physically Addressed L4 Kernel paper - pdf
L4 User Manual API Version X2 pdf
A Secure MicroKernel pdf
This document is intent to provide detailed instruction on building the Android Gingerbread BSP on the
SMDKV210 board.15
Proof (screenshot) is attached.
Yes I managed to "chainload" a patched ("exploit inject" generated) HBOOT on the device via Fastboot. Have prefixed it with a small (assembly language) exploit code that moves it to over to physical zero and jumps into it, then put it into an Android boot image created with mkbootimg_wfs and booted that via Fastboot. You have to hold Vol-Down when issuing the Fastboot command, since obviously otherwise it won't get into bootloader mode but boot straight into ROM. It shows S-OFF and "*** INJECTED ***" (which is the string that the exploit leaves inside the HBOOT image to prove that it worked - I've "stolen" the idea from Revolutionary that show "*** REVOLUTIONARY ***" or something like that). Cannot test whether it actually "acts S-OFF" (allows stuff like "fastboot flash hboot" etc.) since I have no way to enter Fastboot mode. It will boot straight into the ROM after checking the SD card for the PG76IMG.nbh.
Don't want to publish yet since the image obviously contains an entire HBOOT and while I really want to gain S-OFF on the device, I also respect HTC's copyright on their code. I have to turn this into an exploit that generates the image from an HBOOT dump pulled off the phone itself since then I do not have to ship any HTC code with it, which I'd consider "fair".9Haha it works!
Code:~ # cat /proc/mtd dev: size erasesize name mtd0: 00100000 00040000 "misc" mtd1: 00500000 00040000 "recovery" mtd2: 00340000 00040000 "boot" mtd3: 10400000 00040000 "system" mtd4: 02300000 00040000 "cache" mtd5: 09600000 00040000 "userdata" mtd6: 00a00000 00040000 "devlog" mtd7: 02fc0000 00040000 "radio" ~ #
I had a fastboot image of unknown origin that probably couldn't do it for whatever reason. I now used the fastboot that ships with the Android SDK and this one does it.
So yes people, we have access to the Radio!
Code:~ # cat /dev/mtd/mtd7 > /sdcard/radio.img
Succeeds so I'm now having the Radio firmware right on my SD card!
So victory I'd say! We just have to find the flag now. Memory protection is gone! The rest is "good programming work" and "finding out how APIs work" for programming the Flash via mtd devices. It's not that trivial as you have to do quite sophisticated "ioctl" calls to explicitely erase pages before programming them again, otherwise the memory won't be writable. But like I said this is just coding skills and API knowledge. We have passed the challenge, Radio protection is dead!9GOT IT! PHONE SHOWS S-OFF! Bootloader is unusable though. Shows boot screen (including S-OFF), then checks SD card for PG76IMG.nbh, then boots into ROM. No chance to do anything. But I think that only SMALL modification is required now.
