Remove All Ads from XDA

[DEV][THE S-OFF CAMPAIGN] We need electrical engineers & experts in JTAG, OpenOCD!

936 posts
Thanks Meter: 499
By *se-nsei., Senior Member on 3rd December 2011, 11:19 PM
Post Reply Email Thread
17th April 2012, 11:37 PM |#2211  
Antagonist42's Avatar
Senior Member
Flag Bolton
Thanks Meter: 253
Question I need to know...
Right (after a few days file trashing and pc repair after blue screening with all i've been doing ) I need to know which RUU/EUU/ROM/UPDATE you guys are using?

In my digging I've come across something rather odd - obvious - and makes too much sense! It takes stripping files down and running/unpacking then stripping out and reforming but I think I've found the 32 keys for the NAND (or at least for my ACER C6) so if I can check with a ROM/UPDATE you guys are using I'll strip it down and have a peek

If they are the keys then I think I know what they generate them with (roughly) and it's so simple it's TOOOOOO obvious!

It may also mean that the phones are not exactly 'secured' but put in a secure state to remove human error or you have to 'know what you're doing' to alter the system

----XX EDIT XX----
could still do with getting hold of your rom in use (must include all 7 mtd's or all .hex files) keys I found may be something else but want to start checking them as I found 3 more although they could be updated with subsequent updates as it may be tied to specific files/times/dates
18th April 2012, 07:07 PM |#2212  
Senior Member
Thanks Meter: 1,075
Originally Posted by Antagonist42

could still do with getting hold of your rom in use (must include all 7 mtd's or all .hex files) keys I found may be something else but want to start checking them as I found 3 more although they could be updated with subsequent updates as it may be tied to specific files/times/dates

Why would you need all 7 mtds? Some of them may contain sensitive data. You certainly won't need what's on the "userdata" and "cache" partitions.

And for the "locked/unlocked state in misc instead of radio partition". The reason for this is probably quite simple. The Radio firmware is not developed by or for HTC. It's been developed by University Karlsruhe, Germany, with customizations by NICTA (Australia) and Qualcomm to adapt it to their chipsets, licensed from NICTA by Google to ship with Android, with Android in turn licensed from Google by HTC. It's a completely foreign firmware component that HTC just "deploys" as part of Google's Android distribution. I expect HTC's engineers to be unable (due to lack of knowledge about internals or simply due to licensing restrictions) to customize this firmware component, so they probably had to put it elsewhere.
Wolf Pup
18th April 2012, 07:47 PM |#2213  
Thanks Meter: 0
I understood most of what you said, but if finding the keys were too simple, then it's probably already been found. These guys said themselves that they've tried every simple and obvious approach. But, we all know these guys take it TOO far (technical) so they might have missed the obvious. So you might be onto something. You know what they say. The answer is right under your nose.
Wolf Pup
18th April 2012, 08:52 PM |#2214  
Thanks Meter: 0
Can someone give me an update of what's going on and stuff. I need to go and try to get some new soldiers on the job (armed with a PP90M1 and an AK-57/FMG Akimbo, all capable of getting a MOAB; Call of Duty Modern Warfare 3 talk).

My 500th post. Awesome. Never thought I'd make it to 500. LOL.
18th April 2012, 09:41 PM |#2215  
Senior Member
Flag Purmerend
Thanks Meter: 32

never mind
19th April 2012, 01:27 AM |#2216  
MrTaco505's Avatar
Senior Member
Flag Dallas
Thanks Meter: 105
So basically we need a kernel dev
19th April 2012, 02:04 AM |#2217  
Antagonist42's Avatar
Senior Member
Flag Bolton
Thanks Meter: 253
it's not 'YOUR' rom I need just any update that either includes mtd's OR .hex files

Reason is i've stripped down my own .hex files from ACER EUU update which contained the .hex files, from these extracted the .img files as follows:

AMSS .hex file extracted ->
AMSS.part2...........12kb....(you get the idea )
AMSS.part7.bin.......17,972kb - as you'd expect as it is the AMSS*

neither aARM or mARM directly communicate as this would open up mARM for system attack as this holds all the security keys/locks (call it what you will) even NAND has to get past mARM to unlock to write to NAND essentially mARM (as ignorant and acting DUMB as it is) gives the system permission!

found a list of partitions on the phone through wxHexEditor which gave me this...
File pos   Mem pos      ID   Text
========   =======      ==   ====

00000010   00000010      0   0:MIBIB
0000002C   0000002C      0   0:QCSBL
00000048   00000048      0   0:eek:EMSBL1
00000064   00000064      0   0:eek:EMSBL2
00000080   00000080      0   0:FTM
0000009C   0000009C      0   0:SIM_SECURE
000000B8   000000B8      0   0:AMSS
000000D4   000000D4      0   0:EFS2
000000F0   000000F0      0   0:RSV
0000010C   0000010C      0   0:MODEM_LOG
00000128   00000128      0   0:ANDROID_LOG
00000144   00000144      0   0:FOTA
00000160   00000160      0   0:APPSBL
0000017C   0000017C      0   0:BOOT
00000198   00000198      0   0:SYSTEM
000001B4   000001B4      0   0:FLEX
000001D0   000001D0      0   0:RECOVERY
000001EC   000001EC      0   0:USERDATA
00000208   00000208      0   0:CACHE
00000224   00000224      0   0:MISC
as I kept noticing different phones give slightly different layout/naming for partitions etc.

Now as I can understand it the 'part1-7' .img files they relate to the mtd partitions am I right? (if you're never sure you don't have to directly ask and let them know you're a bit dim ) If this is the case I'm wondering why i found ELF file/sys with test screen possibly mARM booting sequencing in the 'MISC' and what seems like a test file or files between " Unable to read BD_ADDR from NV, using default "
and the following " smsm.c.Assertion info->num_hosts <= SMSM_HOSTS_MAX failed.Assertion owner == info->this_hostfailed.smsm_state_get: smsm not initialized.spinlock.c.Invalid argument to spin_lock.Invalid argument to spin_unlock.smem_log_read internal error: read_count (%d) > smem_num_entries (%d) " is a nice little sequence of tags, tag no. and tags, 32 in all (as with NAND fuses although the Qualcomm docs say 11 are sufficient) and each set has a date with it.

A bit like this :
;[General] ;Signature = windows ;FormatVersion = 1.0 ;TimeStamp = Friday August 14, 2009   11:35:24 AM ;
;[Tag] ;Num = 37 ;
;[Tag0] ;TagNum = 2 ;TagLength = 6 ;TagValue = E2 1B 0A ED 1C 5A  ;
;[Tag1] ;TagNum = 6 ;TagLength = 8 ;TagValue = FB FE 0F FE 9B FF 59 83  ; 
;[Tag2] ;TagNum = 17 ;TagLength = 7 ;TagValue = 0A 01 00 00 00 00 00  ; 
;[Tag3] ;TagNum = 27 ;TagLength = 1 ;TagValue = 01  ;
;[Tag4] ;TagNum = 28 ;TagLength = 15 ;TagValue = 00 10 00 00 2C 01 01 00 00 F0 00 00 FF FF 00  ;
;[Tag5] ;TagNum = 32 ;TagLength = 2 ;TagValue = 0C 07  ; 
;[Tag6] ;TagNum = 36 ;TagLength = 35 ;TagValue = 09 09 07 04 09 00 01 02 03 04 05 06 07 07 07 00 00 00 00 00 00 00 01 01 02 00 01 02 03 04 05 06 07 08 09  ; 
;[Tag7] ;TagNum = 37 ;TagLength =22 ;TagValue = 00 00 02 01 01 12 1D 00 00 12 1D 00 00 00 00 00 34 32 30 00 00 00  ;
;[Tag8] ;TagNum = 39 ;TagLength = 4 ;TagValue = 17 03 00 00  ;
;[Tag9] ;TagNum = 40 ;TagLength = 18 ;TagValue = 32 05 07 0D E2 11 43 13 1C 0C 17 10 59 13 8D 04 3D 08  ;
;[Tag10] ;TagNum = 41;TagLength = 38 ;TagValue = 11 00 00 00 42 33 A5 31 B1 07 C1 70 1C FA 1D 04 1E 1F 20 6C 3D E
F 3E C9 A7 F5 AA 42 AB 94 AC 8F A6 BF A8 36 CF 58  ; 
;[Tag11] ;TagNum = 42 ;TagLength = 10 ; TagValue = 87 04 38 0E BD 2D C5 01 38 82  ; 
;[Tag12] ;TagNum = 78 ;TagLength = 2 ;TagValue = 04 04  ;
;[Tag13] ;TagNum = 95 ;TagLength = 11 ;TagValue = 00 03 01 0D 00 00 00 02 00 02 02;
;[Tag14] ;TagNum = 99 ;TagLength = 1 ;TagValue = 07  ;
;[Tag15] ;TagNum = 100 ;TagLength= 135 ;TagValue = 10 22 03 70 00 00 00 00 84 08 7C 00 4F 38 47 09 00 00 00 13 48 14 49 40 69 88 42 18 D1 A0 68 40 07 15 D5 11 49 08 6B 00 28 11 D1 04 20 A0 60 03 20 08 63 12 4F 78 78 3F 78 38 43 11 4F 3F 78 38 43 01 27 38 43 A4 31 08 60 48 20 28 62 07 E0 A0 68 C0 07 02 D0 09 4E 07 4F 38 47 04 4F 38 47 04 4F 38 47 64 08 00 00 80 BD 03 70 C0 F0 0F B0 91 22 03 70 0B 2                                                                                                     2 03 70 19 22 03 70 00 10 00 B0 40 12 00 00 42 02 00 00  ;

What I'm thinking is you have your 'Private Key', send out the updates with 'Public Keys' but you need a cypher, all over the place is the files with Qualcomm, Taipei, CCI with 2 long numbers with the details, think of the NAND as a two way lock, you never open the whole thing you spin lock it, locking the unlocked and vice-versa, misc would be written at the other end of the NAND area (what we may be seeing as oob and garbage), the thing is why would my phone if it was only made in the last 12 months or so have a dated file another 12 months before that in an update only 2 to 5 months old and around 2 months after the phone came out? like August 14th 2009

Don't forget they have to update it without human contact, without a pc, no adb, and no Jtag so it's gotta be a numbers thing
The Following User Says Thank You to Antagonist42 For This Useful Post: [ View ] Gift Antagonist42 Ad-Free
19th April 2012, 05:00 AM |#2218  
csoulr666's Avatar
Senior Member
Flag Aligarh
Thanks Meter: 441
So basically you are thinking of finding HTC's Encryption keys????
Would'nt that be copyright infringment??
19th April 2012, 03:42 PM |#2219  
Antagonist42's Avatar
Senior Member
Flag Bolton
Thanks Meter: 253
Depends how you look at it really....

If these phones are ours and if the android system running on it falls under the GNU/GLP etc, etc, shouldn't you be able to alter aspects of the system as you do with your system say on your pc at home?

Not really interested in encryption but having access to NAND and be able to flash whatever we wanted without initially altering the phone, this is essentially in Qualcomm's domain and not HTC, as we will never know if Qualcomm or HTC set the Q-Fuses but this then restricts your usage of your phone.

Do we want to alter the modem/radio/amss part of the sytem? No
But you can access your pc's BIOS and alter it to suit so why is there no access here as that's even lower-level than what we wish to alter, there is nothing stopping you wiping your system at home and installing afresh without there being 'a key' or as we have for NAND 'Q-FUSES', these are permanent and essentially act as a serial number which 'WE' are not given

So if you manage to work out what is used for the Q-FUSE key and subsequently manage to access your NAND are you breaking copyright or adhering to it by not 'breaking in' but 'using the key' as the last thing we wish to do is break the phone

**this is why I'd never have an iphone or windows phone, you 'HAVE' to break them to make them work the way they should lol**
19th April 2012, 05:03 PM |#2220  
Senior Member
Thanks Meter: 1,075
I think you're on the wrong path. We do not need any "keys". We do not need to "break" any more security measures. We just have to implement the full protocol for talking to the NAND chip.

By convention, the aARM (ARM11) has exclusive control over the NAND, while the mARM (ARM9) does not access the NAND at all after the Radio firmware has been loaded into volatile (RAM) memory. When the Radio wants to write to NAND, it needs to ask the Android kernel running on the aARM via an RPC mechanism to do so. So there is nothing in the Radio we need to "crack". The Radio is completely "dumb". It can't even access the NAND on its own. It relies on Android running alongside to access the NAND for it on request. All we have to do is pass the "unlock" command to the NAND and we have to do this from the aARM. A "stock" Linux kernel can't do it, since the mtd driver has no facilities for this ("flash_unlock" returns "Operation not supported"), so we will have to modify the mtd driver to build in support for this.

Of course, the NAND lock itself is a "security measure". However, it doesn't have "teeth". It merely prevents "accidental writes". It can be disabled at will by the aARM (remember HBOOT is also running on aARM) using a simple "unlock" command to the NAND chip. All we have to do is make the kernel set off this command. We will not need to authenticate with the Radio for doing this, as the locks are completely under aARM's control.

The NAND starts out completely locked and then the aARM must "unlock" pages that it wants to have write access to. All pages start out locked. This is the way the NAND chip operates. The Radio has nothing to do with this. It will never unlock any pages, since it never has to write to NAND. In fact, after initializing, in which it treats the NAND in a "read-only" fashion in order to load software into RAM, the Radio won't access the NAND anymore. What unlocks the NAND is HBOOT, which is running on the aARM, which is also where our kernel runs. HBOOT passes "unlock" commands to the NAND for all the pages that make up the "visible mtd partitions" (so mtd0 - mtd6) so that the Android kernel can write to them, since Android's (and Linux's) mtd subsystem does not have the facilities to unlock the NAND itself. Then the kernel is loaded into RAM and booted and it finds its partitions unlocked.

Now what I would do is build a custom kernel with a modified mtd subsystem, which can pass "unlock" commands to the NAND, just like HBOOT can. Remember that HBOOT will unlock the "visible" NAND area, then boot our kernel. The aARM (where the HBOOT and our kernel run) can always "unlock" more pages at a later point in time. So after our kernel has booted up, we will request our custom mtd subsystem to "unlock" the Radio area (or perhaps just the pages that are occupied by HBOOT). After this has happened, we will be able to pass an "erase" command for erasing these pages. After erasure, we will be able to write our modified HBOOT image back to NAND. We may then opt to pass a "lock" command to the NAND again to re-"lock" the pages we modified, just in case the Radio checks the pages' flags while booting. In no case will we have to authenticate with the Radio or even talk to it. We just need to have a custom kernel, which implements the entire protocol that the NAND chip talks, for unlocking the pages that HBOOT left locked.
The Following 5 Users Say Thank You to no.human.being For This Useful Post: [ View ] Gift no.human.being Ad-Free
Wolf Pup
21st April 2012, 11:37 AM |#2221  
Thanks Meter: 0
Originally Posted by csoulr666

So basically you are thinking of finding HTC's Encryption keys????
Would'nt that be copyright infringment??

I honestly don't care. They could be so useful.

Sent from my HTC Wildfire S A510e using XDA
Post Reply Subscribe to Thread

bootloader, campaign, dev, exploit, hboot, htc, kernel, radio, s-off, secu-flag, wildfire s

Guest Quick Reply (no urls or BBcode)
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes