5,593,248 Members 32,706 Now Online
XDA Developers Android and Mobile Development Forum

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

Tip us?
 
Antagonist42
Old
(Last edited by Antagonist42; 18th April 2012 at 03:42 PM.)
#2211  
Antagonist42's Avatar
Senior Member
Thanks Meter 168
Posts: 382
Join Date: Feb 2012
Location: Bolton
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
Wanna get inside what ya got, gotta get out and find it..I found some!
THE END IS NIGH....S-OFF HERE WE COME...
The Latest ACER E320/C6 Rom From Xakep - Very Slick
ACER E320 1.005.00 ROM EUU
 
no.human.being
Old
(Last edited by no.human.being; 18th April 2012 at 06:21 PM.)
#2212  
Senior Member
Thanks Meter 1074
Posts: 979
Join Date: Oct 2011
Quote:
Originally Posted by Antagonist42 View Post
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
Old
#2213  
Wolf Pup's Avatar
Senior Member
Thanks Meter 289
Posts: 3,714
Join Date: Jan 2011
Location: I live in the TARDIS

 
DONATE TO ME
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.
Devices:
 

SGS3 Intl (Current Device)
HTC WFS (Stolen)
HTC TyTn (WM6)

Fun Stuff:
 

I have a TARDIS. All my messages are sent from my TARDIS. I also have a Sonic Screwdriver.
I'm a Doctor Who addict.
I like Minecraft
Quote:
Originally Posted by conantroutman View Post
You people make me sick......

If you wish, please drop me an internet. Thanks.
 
Wolf Pup
Old
#2214  
Wolf Pup's Avatar
Senior Member
Thanks Meter 289
Posts: 3,714
Join Date: Jan 2011
Location: I live in the TARDIS

 
DONATE TO ME
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.
Devices:
 

SGS3 Intl (Current Device)
HTC WFS (Stolen)
HTC TyTn (WM6)

Fun Stuff:
 

I have a TARDIS. All my messages are sent from my TARDIS. I also have a Sonic Screwdriver.
I'm a Doctor Who addict.
I like Minecraft
Quote:
Originally Posted by conantroutman View Post
You people make me sick......

If you wish, please drop me an internet. Thanks.
 
Caspertje19
Old
(Last edited by Caspertje19; 18th April 2012 at 09:14 PM.)
#2215  
Senior Member
Thanks Meter 23
Posts: 250
Join Date: Apr 2007
Location: Purmerend
Deleted

never mind
 
MrTaco505
Old
#2216  
MrTaco505's Avatar
Senior Member
Thanks Meter 102
Posts: 409
Join Date: Jan 2012
Location: Dallas
So basically we need a kernel dev
 
Antagonist42
Old
(Last edited by Antagonist42; 19th April 2012 at 01:49 AM.)
#2217  
Antagonist42's Avatar
Senior Member
Thanks Meter 168
Posts: 382
Join Date: Feb 2012
Location: Bolton
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.pre.img........1kb
AMSS.part1.img.....1kb
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...
Code:
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 :
Code:
;[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
Wanna get inside what ya got, gotta get out and find it..I found some!
THE END IS NIGH....S-OFF HERE WE COME...
The Latest ACER E320/C6 Rom From Xakep - Very Slick
ACER E320 1.005.00 ROM EUU
The Following User Says Thank You to Antagonist42 For This Useful Post: [ Click to Expand ]
 
csoulr666
Old
#2218  
csoulr666's Avatar
Senior Member
Thanks Meter 361
Posts: 1,278
Join Date: Jun 2011
Location: Aligarh
So basically you are thinking of finding HTC's Encryption keys????
Would'nt that be copyright infringment??
If thou art commit a sin,thy reaper will punish thee!!!


My Phone:HTC Wildfire S
Current Rom:AceOne V2.2 by djolivier
Username Pronounciation:"See-soul-are-triple-six"

You are not the only living person with a problem!!Search a bit before posting
 
Antagonist42
Old
(Last edited by Antagonist42; 19th April 2012 at 03:04 PM.)
#2219  
Antagonist42's Avatar
Senior Member
Thanks Meter 168
Posts: 382
Join Date: Feb 2012
Location: Bolton
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**
Wanna get inside what ya got, gotta get out and find it..I found some!
THE END IS NIGH....S-OFF HERE WE COME...
The Latest ACER E320/C6 Rom From Xakep - Very Slick
ACER E320 1.005.00 ROM EUU
 
no.human.being
Old
(Last edited by no.human.being; 19th April 2012 at 04:22 PM.)
#2220  
Senior Member
Thanks Meter 1074
Posts: 979
Join Date: Oct 2011
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: [ Click to Expand ]
Tags
bootloader, campaign, dev, exploit, hboot, htc, kernel, radio, s-off, secu-flag, wildfire s
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes