hboots do not have a kernel. the simple task it has to do does not require one.
hboots do not have a kernel. the simple task it has to do does not require one.
Yeah, HBOOT runs "on the metal" (no operating system beneath). Now as far as I understand there are two possible scenarios and we don't know for sure which one is implemented.
1. HBOOT sends "unlock" commands directly to the memory controller before booting the kernel. If this was the case, we'd have to modify the kernel to send more "unlock" commands after it has been booted.
2. HBOOT tells the Radio what to unlock via RPC and only Radio can talk to the memory controller. If this was the case, we may not only need to find a way of RPCing the Radio from within Android, but also a way of making it believe that we are HBOOT.
Case 1 is the "good case" and it's the case for e. g. the HTC Vision, where the NAND lock has already been broken, so I hope it's the case for the WFS as well.
Case 2 is much much worse, since the Radio could actually make use of cryptography to ensure that the HBOOT is authentic before fulfilling its requests. I think we'd be pretty much doomed if that was the case and there probably wouldn't be a way of breaking security other than xtc-clip or faking the signature of a patched HBOOT (which is infeasible when implemented correctly and private keys not leaked) or directly programmiing the chip via JTAG.
1. HBOOT sends "unlock" commands directly to the memory controller before booting the kernel. If this was the case, we'd have to modify the kernel to send more "unlock" commands after it has been booted.
2. HBOOT tells the Radio what to unlock via RPC and only Radio can talk to the memory controller. If this was the case, we may not only need to find a way of RPCing the Radio from within Android, but also a way of making it believe that we are HBOOT.
Case 1 is the "good case" and it's the case for e. g. the HTC Vision, where the NAND lock has already been broken, so I hope it's the case for the WFS as well.
Case 2 is much much worse, since the Radio could actually make use of cryptography to ensure that the HBOOT is authentic before fulfilling its requests. I think we'd be pretty much doomed if that was the case and there probably wouldn't be a way of breaking security other than xtc-clip or faking the signature of a patched HBOOT (which is infeasible when implemented correctly and private keys not leaked) or directly programmiing the chip via JTAG.
Last edited:
Bummer. Any luck with getting a kernals to go?
sent from my android powered beast!
sent from my android powered beast!
W
Wolf Pup
Guest
****. I don't like Case 2. How does XTC do it. Directly changing the byte or by patching HBOOT? Come on! If XTC can do it, so can we! Can someone please summarize what is happening at the moment.
I've lost track. And should the OP update the OP?
Sent from my HTC Wildfire S A510e using XDA
I've lost track. And should the OP update the OP?
Sent from my HTC Wildfire S A510e using XDA
even case2 is not unbreakable. the keys needed must be stored somewhere.
to come back to the clip: it does no magic. it mimics a probably leaked htc service sim and flashs the diagnostics tool. that does s-off. once s-off you can write supercid.
the most important thing is the sim emulator.
to come back to the clip: it does no magic. it mimics a probably leaked htc service sim and flashs the diagnostics tool. that does s-off. once s-off you can write supercid.
the most important thing is the sim emulator.
There is a possiblity that dopounutbear wire method works on ws, open the ws you will see contacts, let dopounutbear do its thing and its s off like the xtc clip style.
Directly programming which chip? the MMU or mARM via Jtag?
Qualcomm make specific use of protecting access to areas mARM stores security so Jtag can only access 'indirectly' via authentic software or have the keys/signature (forcing use of Jtag blows remaining Q-Fuses making finding the original Q-Fuse sequences even harder), aARM you can use Jtag on but even then to get in that way to mARM you still need the keys/signature to get into mARM's protected areas (if I remember rightly more specifically a 64kB section in IMEM's 256kB area in mARM) which mARM sets up during PBL and then has no direct access to it.
This is where I think using Official updates that we could alter may at least offer the best way in without crippling or destroying security, which to a certain extent helps protect the whole phone from being exposed to being hacked from outside sources other than the user (if you made use of the NFC and you have a rogue app that copies data and transmits it, essentially we'd have exposed our bank details for them)
Qualcomm make specific use of protecting access to areas mARM stores security so Jtag can only access 'indirectly' via authentic software or have the keys/signature (forcing use of Jtag blows remaining Q-Fuses making finding the original Q-Fuse sequences even harder), aARM you can use Jtag on but even then to get in that way to mARM you still need the keys/signature to get into mARM's protected areas (if I remember rightly more specifically a 64kB section in IMEM's 256kB area in mARM) which mARM sets up during PBL and then has no direct access to it.
This is where I think using Official updates that we could alter may at least offer the best way in without crippling or destroying security, which to a certain extent helps protect the whole phone from being exposed to being hacked from outside sources other than the user (if you made use of the NFC and you have a rogue app that copies data and transmits it, essentially we'd have exposed our bank details for them
)
Well again I have a xtc clip in Scotland if anyone is willing to provide a phone we can do the dumps and see
sent from my android powered beast!
sent from my android powered beast!
You need an ARM rompatcher, patch Hboot to S-off set to autorun on boot also custom keyboard so you could write to Data also System and other partitions except hboot where rompatcher running you can only use it when its booted to android.
Can write files to rom, with su, can flash roms, can flash kernels, cant and no flash splashscreen, and cant and no make custom partitions.
Download
Can write files to rom, with su, can flash roms, can flash kernels, cant and no flash splashscreen, and cant and no make custom partitions.
Download
Last edited:
JuopunutBear will probably not work. The so called wire-trick seems to work only on eMMC based devices which have a special qualcomm download mode. The WFS has no pins to connect to. it has several "holes" where a wire would fit in, but no contact pins. I don't think this will ever come to mtd devices.
Well again I have a xtc clip in Scotland if anyone is willing to provide a phone we can do the dumps and see
sent from my android powered beast!
We should come back to it later, when we succeeded writing to the radio area and our hboot exploit does not work out.
I don't think the rompatcher will help us flashing a hboot ;-)
The problem we have is the section 'Block Lock Feature' (p42 of the NAND chip), essentially we can write to NAND with updates, the AMSS or Radio data is write protected on NAND (and I think n.h.b. may have read same things that say the S-OFF is in the Radio or mARM system data as I have) even at boot time whilst the APPS/kernel aARM is not write protected so we can freely install things to a certain degree, if we could find out what, where and how the NAND is 'inverting' the Block Lock we can write in whatever we wanted and possibly simply 'turn' S-ON to S-OFF.
Seeing as you have to register with HTC to get the hboot updated (which I stripped it out and is hboot_1.10.0000.img) so as you can install roms etc there must be a difference between that and original hboot's that maybe 'pull's down' the lock enabled NAND on boot to make it writable seeing as there isn't an update for the AMSS/Radio of the system...... going to find a few hboot's to compare them and see what's what >
This is what we may need to know how to get at the S-ON/OFF as to how to turn the NAND's Block Lock on and off.
Seeing as you have to register with HTC to get the hboot updated (which I stripped it out and is hboot_1.10.0000.img) so as you can install roms etc there must be a difference between that and original hboot's that maybe 'pull's down' the lock enabled NAND on boot to make it writable seeing as there isn't an update for the AMSS/Radio of the system...... going to find a few hboot's to compare them and see what's what >
This is what we may need to know how to get at the S-ON/OFF as to how to turn the NAND's Block Lock on and off.
Last edited:
226 pages of pondering. Whoever engineered this phone better have had a legitimate reason for this.
Its obvious the reason for this is to prevent users just like us from hacking the crap out of HTC's phone lol.
If the Radio does really intercept all NAND access, it's quite easy to make it unbreakable.
Radio (pseudo-)code:
Code:
#define FALSE 0
#define TRUE -1
char memory_controller_read_nand(int);
void memory_controller_write_nand(int, char);
int is_kernel_running;
__remote_callable char nand_read(int address)
{
return memory_controller_read_nand(address);
}
__remote_callable void nand_write(int address, char data)
{
if ((!is_kernel_running) | (!memory_controller_check_locked_flag(address))
memory_controller_write_nand(address, data);
}
__remote_callable void booting_kernel()
{
is_kernel_running = TRUE;
}
int main() /* This is the entry point to the Radio firmware, mARM begins executing here after powering up */
{
is_kernel_running = FALSE;
while (true)
sleep(5);
}HBOOT (pseudo-)code:
Code:
extern "C" __remote_callable void booting_kernel(); // This is an RPC handle to the method in the Radio
void load_kernel();
int main()
{
if (flash_ruu) /* If we need to flash an RUU */
run_ruu_flash_process(); /* Actually flash the RUU */
else /* Otherwise */
{
booting_kernel(); /* Radio knows that at this point HBOOT is no longer running and will refuse all access to Radio area to aARM */
load_kernel(); /* This actually loads and executes the kernel */
}
}Now let's assume aARM doesn't have direct NAND access, so all our kernel can do after it has been loaded by HBOOT is do a remote-call to the "nand_write(...)" method in the Radio to request it to write. Since the Radio knows that a kernel has been loaded, it will no longer pass write commands to pages that are flagged as "locked" to the NAND. Of course it will also intercept the calls for changing these flags. Now you tell me how to break the security even in this "easy" example (which doesn't even make use of cryptography). You can't alter the "booting_kernel()" function in the Radio and also not the call to it in the HBOOT, since both lie within the protected area. ;-)
And the diagnostics tool is original HTC software and therefore signed.
Right. The software will check for the service SIM and a SIM card is actually a small microprocessor that will usually talk a cryptographic protocol to authenticate. It will encrypt or decrypt data that is passed through it with keys stored in its internal storage. The keys themselves will not be revealed in this process and the data stream to be encrypted can be randomly generated each time by the diagnostics tool, so eavesdropping on an xtc-clip won't help.
The NAND.
Well, indirectly. With JTAG, you can drive all output pins of a chip in real-time. Manufacturers use this feature to perform what they call "boundary scans". It's basically a facility for testing whether the conductive paths on the PCBs are ok. We take whatever processor the NAND is connected to and use JTAG to drive that one's I/O pins in the right manner to talk the protocol that is used for NAND access (which is probably SPI).
Lol, they certainly won't block JTAG access. It's too important for repair. Say someone steals a manufacturer's signature keys (e. g. a former employee smuggles them out), then releases a "firmware update" that will always completely lock the NAND, no matter what. If they disabled JTAG access, even HTC's engineers wouldn't have a way of getting a different firmware onto the phone after such an incident. Same scenario if HTC releases an update that just doesn't boot and locks up the mARM. Thousands of "dead" phones with controllers that are fully functional, but have "bad firmware" on them and disabled JTAG access. Hehe! No, you never disable such a thing.
Also, why should they lock it up so much? Ok, you mentioned NFC. This may actually be a security-relevant thing to justify such a protection. However apart from NFC (which our phone doesn't support afaik), it's just protecting intellectual property. You protect intellectual property by preventing your competitors from looking at it (since they could build a similar device and slap your firmware on), not from modifying it (they won't buy your hardware, slap their firmware on and sell it again
). So if every NAND access actually had to go through mARM and aARM could not directly talk to NAND, they certainly would filter the reading requests as well on the NAND pages that aARM doesn't have to read (the HBOOT area it has to read, but not the other Radio stuff). The only thing that write-protecting is useful for is preventing accidental (bricking) or intentional (malware) modifications to the firmware. And since your virus-app that you downloaded from Android Market certainly won't have JTAG access, why would you disable the JTAG port? ;-)Also remember that the mARM runs this Pistachio microkernel (which is basically just a scheduler) instead of a full-featured kernel like Linux. It does so because a complex operating-system kernel will usually do all sorts of stuff, e. g. processing interrupts, that could make it impossible to guarantee timing constraints that might be important to the network. Do you really think that they will "occupy" this processor with forwarding NAND requests for the aARM? (Remember that the NAND interface is quite wideband so there's gonna be a lot of traffic from the aARM.)
You see it all doesn't really add up. We're probably wrong with our assumption that mARM has NAND access and aARM does not. And at least on the HTC Vision it has already been verified that aARM has direct and exclusive NAND access, while mARM has to RPC the Android kernel running on the aARM for every page access. So it's actually the other way round. Android can intercept Radio's NAND access, which also makes sense from an architectural point of view, since the mARM is a sort of co-processor to the aARM and co-processors usually don't have direct memory access, while the main processor, the aARM, has.
The blocks can be unlocked simply by passing an "unlock" command to the NAND. If we can directly talk to the NAND and mARM is not somehow "intercepting" our communication (and then blocking these "unlock" commands), we will "just" have to implement a facility into the kernel's mtd driver to pass "unlock" commands to the NAND chip, just as it now passes ordinary "read" and "write" commands to the NAND chip. So as long as our aARM has direct I/O to NAND, it's definitely possible to overcome (even though it requires us to really customize that driver and remember we don't have a kernel dev here ;-) ). If mARM can intercept our I/O, well, then they can achieve some goddamn security level. See top of my post.
Last edited:
Document update
Recent Docs I grabbed and hopefully more to come
--->> AMSS <<--- This is a MUST!!!
--->> Build your own CPU <<--- If you got the gear
--->> Qualcomm Auto Test <<--- Unknown source and no documentation Beware!
Recent Docs I grabbed and hopefully more to come
--->> AMSS <<--- This is a MUST!!!
--->> Build your own CPU <<--- If you got the gear
--->> Qualcomm Auto Test <<--- Unknown source and no documentation Beware!
Ok
... mARM boots up, loads up boot loaders etc, sets up secure area in Imem etc and then sits in the background running the AMSS and spends the majority of it's time on EBI2 (slow Bus) running the peripherals (and NAND resides on EBI2) whilst aARM is running the apps, system, passing everything back and forth mainly on EBI1 (fast Bus) with access to some (if not all) peripherals, DDR Memory etc, the AXI bus is the crossover between both EBI1 and EBI2, anything that tries to access something on the EBI2 Bus is more than likely to be 'Quizzed' as to whether it has legitimate access (secure signature or Q-Fuse key) to alter the system or files, either a/mARM can pass a signature/key through to IMEM to attempt to pass, if true then the operation commences, false and nothing happens as neither ARM can directly 'read' the secure IMEM only pass a file in - result out, that's how I'm seeing how the mARM has the control over aARM as to writting to NAND and turning off the Block Lock or Tight Lock as NAND resides on EBI2 and access is through AXI bus and mARM (you knock on NANDS door and mARM barks his head off ).How to get around it? ......One thing you have to do seems to be 'Have Your Phone Turned On' (either with an EUU/RUU or the HTC Unlock) before you update, essentially android up and running and not booting up from power off, if android is up and running you could literally run a signed program to instruct a reboot with NAND Locks off or it's written into SMEM then stored and implemented on reboot (as the system info to re-use on a warm boot and does this if you reboot normally), so what if you were to turn off the BT Server and Sync Server Starter before you reboot? As I see it if you were to turn something off like this, put maybe the same thing into data that is reloaded from SMEM when you boot into fastboot you then have mARM maybe not communicating CELL side wise and a Sync Server that isn't Synced to say AXI Bus, then your system is on, you're running fastboot and any read/write/erase to NAND isn't signature/key checked (as these are placed into IMEM around PBL Loading) by mARM as it's been 'turned off'.
I think they do, not the whole chip but only what they don't want you to get at because of the very same reason if somebody 'stole' the keys......
Code:
[B]3.6.8.1 Modem subsystem security[/B]
The modem subsystem is protected from all outside masters by the unidirectional modem bridge.
In addition, there are non-trusted masters inside the modem subsystem:
1. ARM9 when running in user mode
2. Modem data mover channels controlled by ARM9 in user mode
The level of trust granted to the user-mode ARM9 and data mover masters is sufficient to access all modem components except the secure mode control (SMC) register map. Protection of the SMC is ensured by checking the HPROT[1] bit. This bit is set during accesses produced by the mARM while in supervisory mode and during accesses produced by DM channels in security domain 0. mARM software must ensure that the DM security domain 0 is only accessible to mARM in supervisory mode. No access to the SMC is allowed in user mode.
[B]3.6.8.2 Q-fuses[/B]
The MSM7227 IC includes on-chip non-volatile (NV) one-time programmable memory to store device configurations, hardware key values, boot ROM patch information, and memory redundancy information. These NV bits are electronic fuses called Q-fuses.
[B]Security-related NV content[/B]
Four Q-fuse chains are used for security-related applications; if compromised (modified and/or observed) they may cause a security breach:
[B]1. PRI_HW_KEY (128 bits + FEC)[/B] – contains the primary hardware key value that can be programmed after packaging. Once this chain is programmed its contents must be protected from observation or modification, so a CONFIG chain fuse is provided to [COLOR="Red"]disable JTAG access[/COLOR] to it. Secure software may read its value by accessing the SMC memory map.
[B]2. SEC_HW_KEY (128 bits + FEC)[/B] – contains the secondary hardware key value; all the [U][B]PRI_HW_KEY comments (#1 above)[/B][/U] apply to this chain as well.
[B]3. BOOT_ROOM_PATCH (2256 bits)[/B] – contains boot ROM patch information that is programmed and tested before packaging. Once this chain is programmed its contents must be protected from observation or modification, so a CONFIG chain fuse is provided to [COLOR="Red"]disable JTAG access to it[/COLOR]. There is no direct software access, but secure software may indirectly access its content by reading the boot ROM content.
[B]4. CONFIG (143 bits + FEC)[/B] – contains miscellaneous configuration information that can be programmed after packaging. Additional programming by handset designers (or their production staff) is allowed, if they weren’t already blown by Qualcomm. A fuse value of [COLOR="MediumTurquoise"]1[/COLOR] means it has been blown.As for NFC I'd guess if you have the MSM7227, a NAND/OneNAND, PM7540, RT6280/6285, Bluetooth, WiFi and all the rest then it's capable, they put it on my phone and my Base Motherboard of the phone is the HTC ChaCha so the ChaCha is capable if HTC put it on (or maybe they want to string out the phones a while longer 'til you upgrade
)No I think you have the NAND memory mixed up with the DDR RAM, NAND Resides solely on the EBI2 (SPB Slow Peripheral Bus), DDR Memory on EBI1 (FPB Fast Peripheral Bus), aARM is probably using NAND at boot via the AXI Bus
Code:
[B]3.3.2 Peripheral buses[/B]
The fast and slow peripheral buses (Figure 3-7) enable bus masters to connect with several peripheral devices and lower-bandwidth memories inside the MSM7227 IC and beyond, thereby offloading the buses to the high-speed EBI1. Five bus masters are supported: 1) the modem subsystem, 2) the applications processor subsystem, 3) the applications data mover, 4) the aDSP, and 5) the MDP.Why make the assumption that only ONE has access? don't forget that there are two Data Buses, two Data Movers, separate and joint RAM in MSM chip and two kernels running, one as a high level OS the other closer to machine code, it is quite viable they could both have access but only either one at a time or as the MSM chip is (and if the NAND is) capable as RISC operations.
If you know where the locked upper and lower partitions are (around what we have access to at the moment which is mainly in the visible system we can alter) we could simply dump all info surely? alter the partitions maybe? Get the phone to 'unlock' the 'Block Lock' then all data outside what we can map already should be mappable (if not already held in the radio area we cannot access), as any space as with oob is read around to the next readable location, the (lets say 2 seperate partitions - as we use the 1 in between them now) 2 partitions would simply be read and the oob section (our in use now partition) would be skipped until the next readable location. There is no block on reading and writing except for what is within the given partition on NAND and what is held as 'protected' as with AMSS you may need keys/signed software (as with EUU/RUU).
Now I just hope I make as much sense as you do
Yes. In the beginning of the misc partition there are some values referring to usb and stuff. they are VERY important. Screwing these values will make the device not accepting usb connections anymore (within android, of course. bootloader will still work with usb) and also makes the system not recognizing the external storage. on a locked device without misc backup you are probably doomed then
True? I'm fairly sure this has happened to me is the reason.
The device bootloops before before passing to the kernel UNLESS charging power is supplied to it, then it boots fine.
It understands that it is connected via USB by neither UMS nor ADB will work. Recovery cannot see the sdcard.
I'm fairly sure that it's a USB brick. Would it be possible to flash somebody else's misc.img if they gave me one?
Strong indication for misc brick
Right. Also indicator of misc usb brick
Yes. Depending on which device CID you have. I can only give you the misc.img of HTC_EU Devices.
However, if you are able got get a misc.img according to your country you can fix your misc brick. this is what I've done: http://xdaforums.com/showthread.php?p=23175308&highlight=enableqxdm#post23175308
So, basically all you need is a working misc.img for your phone. if you have it I can tell you how to exactly unbrick. because this is a bit tricky depending on several things
!!Yes please!!. I've been trying to get this thing working for 3 weeks. The only place it can do any good is in my car as a music player. I feel like an iPhone user stuck with tethered jailbreak.
If you gave me your misc.img would I be able to hex edit my CID (or super CID it) before flashing?
Thanks again
EDIT: I also did enableqxdm but not having a valid misc to flash I remained USB bricked
Last edited:
G
GuestK00178
Guest
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.
New posts
-
Trying to hack new Google Play Games Beta for Windows- Latest: anonymous_7218
