Anybody took a look here???

http://unlimited.io/

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

Originally Posted by csoulr666

Anybody took a look here???

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

this will be the solution

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

Sent from my HTC Wildfire S A510b using XDA

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

watch the wire trick!

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!

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

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.

Originally Posted by no.human.being

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.

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