[HTC Wildfire S] Antagonist42:
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 :D).

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......

[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 :rolleyes:)

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

[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 ;)