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

no.human.being · Apr 21, 2012

I don't understand what "keys" you have found. They probably aren't the keys they use for signing their firmware images. If I understand correctly, you can use them to "authenticate" with the Radio for gaining NAND access, right?

Now the question I have is, since the aARM already has exclusive control over the NAND, what will the Radio do after you pass it those keys? Will it take NAND control from you, remove the "locked" flag from its pages, then give you NAND control back?

If so, what's the benefit of versus passing "unlock" command to the NAND directly from the aARM? Ok, we'll have to modify the kernel for this, but we already have a rough idea where this modification takes place (mtd driver). Compare this to "passing keys". The kernel probably can't do this yet (why should it, it never needs to when operating regularly, it seems to be just for "hacks" so it's probably completely unsupported

), so we'd have to implement the entire mechanism. What protocol do we talk with the Radio? Lots of question you see.

I'm not saying it's not a way that could work and I also don't claim that this is the inferior solution, I would just like to understand exactly what you plan doing and what you know about how it can be realized. I really think it's great that we might have found another possibility of bypassing security. Having more options is always good.

csoulr666 · Apr 21, 2012

Have you ever looked what apple does in such matters ?????

---------- Post added at 06:58 PM ---------- Previous post was at 06:57 PM ----------

This was meant for bad-wolf

sythe179 · Apr 21, 2012

off topic?...
thought we where trying not to post those..
maybe PM him?..

corrsea · Apr 21, 2012

Ive followed this thread for a few months since my friend and me to unlock his wildfire s and I discovered it was not that straightforward

I just wondered if anything in the construction off the clk bootloader for the hd2 would be helpful in building the kernel you need?
http://xdaforums.com/showthread.php?p=14426749
Apologies in advance of this its not useful.

Sent from my HTC HD2 using Tapatalk 2

Antagonist42 · Apr 22, 2012

I don't think aARM has 'Total' control as signature keys and security for NAND access is loaded into IMEM from PBL setup by mARM, there is not seemingly direct access to this as mARM is protecting from Jtag, aARM or outside or non-signed access, can only be done 'indirectly' as I understand it as the following:
aARM requests access to NAND, NAND verifies aARM is authentic, authenticity resides in mARM IMEM and mARM does the same passing a request externally as mARM is protected itself from exposing security in IMEM.... This is where I think partitions or whole sections of NAND are either flashable AND protected, flashing to NAND seems to be done as eg. /root/system/ etc flashed then the NAND is spin locked then the AMSS is flashed, power up/down can be instigated normally from aARM but can also be done from mARM as with FOTA update, the write enable is either 'hard wired' so software had to instruct the PM7540 or NAND MMU to enable write (as I cannot see write being left enabled anymore). This is why I think mapping and writing to areas outsite the accessable sections of the spinlocked area could be lost or blocked if not done as an update and writing may be returned as 'successful' but ignored as NAND still spinlocked.

If this is way off the mark I appologise in advance but you can only go off what is out there and this is what seems to me the Qualcomm docs point to.

ROOTED ACER E320/C6 ;-)

Antagonist42 · Apr 22, 2012

Another reason being now with Near Field Connectivity they will have to make phones even more secure so bank details etc cannot be accessed through hacked phone, they'd never live it down, and I'm guessing that NFC is run through the mARM as with MODEM, BREW, RX/TX SMS BLUETOOTH,etc all the peripheral devices the system uses that would be strongly protected, as in what seems an oob on the NAND the protected spinlock section.

ROOTED ACER E320/C6 ;-)

Antagonist42 · Apr 22, 2012

Have you managed to flash anything from a cold boot? No battery etc then flash, as i've mentioned before flashing 'blindly' produces nothing, no flash etc, flashing from an update though gives a result but how does the phone boot to fastboot/recovery unless either told to in a register in either IMEM (or where it stores it, i'm no Boffin at this lol) that could be where the difference in my malez flash didn't work and almost worked with EUU cold boot nothing as not authentic as in say IMEM register EUU authenticated the running and flashing of NAND and mARM sees this and opens NAND for flash as is Authenticated before and after boot.

ROOTED ACER E320/C6 ;-)

no.human.being · Apr 22, 2012

Ok, so you claim that mARM's IO is connected to the memory bus, not aARM's, so that mARM has control over NAND and aARM needs to ask, e. g. via RPC, firmware running on mARM to access NAND on its behalf, which would put the Radio in a position where it could intervene our NAND access, essentially blocking us from writing to the unmapped (Radio) NAND area, right?

Now that would actually be quite a strong security system. I've just got two points that indicate that this is not how it's done.

First, there has been a (reverse engineering) analysis of the HTC Vision's boot process, which features an MSM7230 processor (quite similar to an MSM7227), and this phone was found to have this "handover" step. So hardware-wise both mARM and aARM can talk to the NAND. Radio boots first and reads from NAND for initializing. Then it comes to a point where it will never need to access the NAND again. Only after it reaches that point, aARM will start booting and will now have, by convention, exclusive control over NAND.

Secondly, the Radio running on mARM will only need NAND access while initializing, while the aARM will need NAND access during regular operation. Always asking another operating system for memory access would result in quite some overhead, potentially harming device performance.

Last but not least, we know how it's done on the MSM8255 chipset, since the GFree exploit that can S-OFF devices with this chipset is open-source and with the MSM8255, there also does not seem to be any security system in place, that would intervene writes to the Radio area from the aARM. It does this strange "needle and haystack"-algorithm, then patches around in partition 7. I think that this "needle and haystack"-algorithm is there for mapping the Radio area while the phone is booted, while we do it by "cold booting" the phone with a custom kernel featuring a custom partition mapping. However, the principle is probably the same. They even use the same partition number for mapping the protected area.

csoulr666 · Apr 22, 2012

Anybody took a look here???

http://unlimited.io/

It might be possible that it could be ported to our WFS

schlund · Apr 22, 2012

csoulr666 said:
Anybody took a look here???

It might be possible that it could be ported to our WFS

this will be the solution

sythe179 · Apr 22, 2012

They use old revolutionary code for a hboot that can write to the nand.

Sent from my HTC Wildfire S A510b using XDA

csoulr666 · Apr 22, 2012

but the point is that there doing it with phones which have their bootloaders unlocked via HTCdev................that's the main point

schlund · Apr 22, 2012

watch the wire trick!

no.human.being · Apr 22, 2012

Very special thanks go to team revolutionary for the ground breaking work they did on custom hboots for HTC devices opening the door to fastboot enabled bootloaders. The hboots supplied by with/by JuopunutBear are based on, and entirely inspired by, their previous original work.

How can they "base something" on Revolutionary? Afaik, apart from the zergRush exploit, Revolutionary have not disclosed anything and their exploit code is heavily obfuscated.

That's the main problem we have. All the Android hackers are b*tching around and not disclosing what they did, so whenever there's a new exploit to be developed by someone else in the scene, they all have to figure it out again and again. Not very productive.

I understand that they want to get credit for their work, but they would still get that if they opened up their stuff. And the thing about "if we disclose the exploit the vulnerability will get fixed" is pure bullsh*t. The firmware is so vulnerable (e. g. the "HTCU" in "misc") and basically we're now at a point where we know how it's done, but we have to build all the kernel-level device driver stuff again. It's a shame!

einstein.frat · Apr 22, 2012

it just needs some scary cake and a wire to s-off.

no.human.being · Apr 22, 2012

Well it needs their software to S-OFF as well. Looks like they're pulling one of the lines of the processor's JTAG interface down to ground (expect the SIM card slot holder to be connected to AGND) for whetever reason.

And well, they also seem to be patching the HBOOT, since it says "JoupunutBear" on the top when booted into HBOOT mode, just like it says "Revolutionary" when S-OFFed via Revolutionary. So basically we're all doing the same, just with slightly different methods.

Antagonist42 · Apr 22, 2012

no.human.being said:
Ok, so you claim that mARM's IO is connected to the memory bus, not aARM's, so that mARM has control over NAND and aARM needs to ask, e. g. via RPC, firmware running on mARM to access NAND on its behalf, which would put the Radio in a position where it could intervene our NAND access, essentially blocking us from writing to the unmapped (Radio) NAND area, right?

Roughly but not quite, don't forget that mARM processes most of the peripherals that are on the LSB (Low Speed Bus or EBI2) aARM is on the FSB (Fast Speed Bus or EBI1) dealing with user space running apps and the NAND'S DDR memory, both systems of ARM have access and relevant control for either EBI1 / 2, as you say aARM has control excusively over NAND (is that in a boot mode or full system running mode? or makes no difference?) this I think is partially true as to access or writing 'Except' which part of the NAND memory is 'Spin-Unlocked' which I think is controlled via either mARM or registers set through mARM to IMEM (verified with the access of Q-Fuses/Signature) to reboot the system with access to write to NAND 'And to spin the lock' {protected memory} to write to AMSS say at which time the 'system' area is protected as the lock is spun.

With the Micron NAND you can 'SET' how the pull-up to write on the NAND is done, either by Soldering a pin (or not - can't remember off the top of my head) and software programming the pull-up or it is only software doing the pull-up so previous systems may only have had NAND chips without this facility and maybe with the advent of NFC being rolled out it is being used now, which protects the NAND RADIO etc from being read whilst the Android system is running or unable to gain access because the spin-lock is not operated so no read/write or false reporting of read/write success.

And you maybe right that Revolutionary etc may have found out how to make the system 'pull-up' the write access but are ignoring the protected NAND areas so NFC may (I think) become vulnerable if there is nothing to stop it like passing a signature/Q-Fuse key.

no.human.being · Apr 22, 2012

Sure that you really mean spinlock? It's a mechanism for thread synchronization.

Antagonist42 · Apr 22, 2012

Not specifically but found several points .bin reading with spinlock to do with NAND, there is also the lock and unlock which the whole thing is 'spun' and also using spinlocks to deliberately 'tie up' ports.... If I'm confusing things then my apologies as it's what I've been reading and come across myself and it could be two acronyms meanings for different things lol (just my luck

)

heavy_metal_man · Apr 22, 2012

Hey guys random thought. Does the enghboot have a kernal built into it? Or flashed with it? The phones have to have a way to write to that partition natively. Is there no way to find and utilize this?

sent from my android powered beast!

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

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Similar threads

Top Liked Posts