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

I have no idea what a framebuffer is, but I understood the rest. True. Any news, NHB?
Can sum1 sum up what we're trying to do and all that. I need the information so I can get us some fresh blood.

*se-nsei. said:

I have a bad feeling that development has come to a halt. :/

Click to expand...

Click to collapse

We're all waiting for some genius to appear, who is able to modify a kernel in such a way that the mtd driver does not check the out-of-band area of blocks before passing "erase" commands to them and can subsequently build this kernel for our device. As long as you know what you're doing, I do not expect it to be exactly a "big thing". However, kernel devs seem to be at a premium.

Now that you explained that, Im going to look at the C coding for the sense kernel... Maybe i can erase all precautions

simonsimons34 said:

Now that you explained that, Im going to look at the C coding for the sense kernel... Maybe i can erase all precautions

Click to expand...

Click to collapse

Sense kernel? We're currently running off a CWM image. I expect it to be based on the Alquez/Drowningchild kernel. It's good because it's self-contained and seems quite "unrestricted". It lets us map the Radio area via the mtd driver. This is a requirement for our exploit to function and I'm not sure whether an arbitrary kernel will let us do this.

Well the recovery alquez has uses the sense kernel

Sent from my HTC_A510c using Tapatalk

showp-1984 is a good kernel dev, I was trying sleep2wake to wildfire s kernel, if I have time I'll redo it.

einstein.frat said:

showp-1984 is a good kernel dev, I was trying sleep2wake to wildfire s kernel, if I have time I'll redo it.

Click to expand...

Click to collapse

Oh, it's you.

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

Antagonist42 said:

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

Click to expand...

Click to collapse

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.

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.

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.

Deleted

never mind

So basically we need a kernel dev

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

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 :



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

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

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

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.

csoulr666 said:

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

Click to expand...

Click to collapse

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

Sent from my HTC Wildfire S A510e using XDA

Good work people! 2222nd post!

Sent from my HTC Wildfire S A510e using XDA