yashsingh1/xdaforums huggingface dataset:
[G2 and Desire Z Android Development] Disconn3ct:
Interesting - it is possible that the writes are being held by linux..

echo 3 > /proc/sys/vm/drop_caches (to drop all clean inode/dentry/pagecache entries) results in all changes to /system disappearing immediately. (Not sure yet of the exact mechanics of this - if it was tmpfs/ramfs/etc the changed pages would be considered dirty and they wouldn't be flushed.)

So it could be that the linux cache is the only cache, and its a side effect - if the emmc (via rmt_storage) is accepting and discarding all writes, you might get this exact behavior: linux sees it's changes until the cache expires/flushes, then stops seeing them..

Also:

# /data/local/tmp/busybox free
/data/local/tmp/busybox free
total used free shared buffers
Mem: 379832 250400 129432 0 17712
Swap: 0 0 0
Total: 379832 250400 129432
# dd if=/dev/zero of=/system/fill
dd if=/dev/zero of=/system/fill
/system/fill: write error: No space left on device
441257+0 records in
441256+0 records out
225923072 bytes transferred in 12.606 secs (17921868 bytes/sec)
# /data/local/tmp/busybox free
/data/local/tmp/busybox free
total used free shared buffers
Mem: 379832 376360 3472 0 17688
Swap: 0 0 0
Total: 379832 376360 3472

(from http://pastebin.com/C4ePzZsH, thanks to bentglasstube)

So we're still not looking for a missing partition taking writes, but as a last resort there is a good chance we can do something convoluted and fun to get persistent writes (for example, livecd-style COW overlay to save new data to the accessible partitions..)
[G2 and Desire Z Android Development] gee one:
So we have to spoof the hash on a bootloader AND a recovery?

We will probably need both of these anyway, regardless of attack vector, so is anyone writing them?
[G2 and Desire Z Android Development] uplinked:
Hi guys, on the train right now, haven't read the last 5 pages, but if it comes down to brute force --

I am a scalable systems programmer w/ expertise in large cloud clusters doing heavy processing. I've never reversed an RSA key before, but if someone here knows a method, I have the server power to run the brute force on. Please pm me if I can be any help.
[G2 and Desire Z Android Development] hah2110:
Maybe I'm crazy here, but on the SD card is PC10IMG.zip... Is that is what is doing the flashing upon reboot?
[G2 and Desire Z Android Development] Disconn3ct:
Yes, you are crazy, because there is no flashing upon reboot. The changes are getting stored in the linux caches, and go away if you flush the cache.. they are never touching the flash at all.
[G2 and Desire Z Android Development] Disconn3ct:
http://pastebin.com/0TLBnsfV

(courtesy bentglasstube again)
[G2 and Desire Z Android Development] ace42588:
where does the cache reside? i thought it was determined that writing to /system didnt increase ram usage or any of the partitions. i might be misunderstanding what you mean by not touching the flash
[G2 and Desire Z Android Development] Disconn3ct:
Take a look at the memory usage on the last page - it looks like it does reside in the kernel, and flushing it results in most/all of the changes disappearing.
[G2 and Desire Z Android Development] androidcues:
you hold down menu and then power.... and it goes into the bootloader. It is really tricked out and colorful, with three skateboarding androids.

it has a LOT more options than the G1 ENG bootloader (the haykuro)

i just took pix with my G1 (of the various stages of HBOOT and FASTBOOT on the G2) but no wifi here, cant upload now, but ill describe ---

when HBOOT is loading I get

in green font...

SD Checking Loading PCI0DIAG.zip

No Image!

LOading PC10DIAG.nbh

No image or wrong image!

Loading PC10IMG.zip

No Image!

Loadfing PC110IMG.nbh

No Image or Wrong Image

(thats all normal I think its same on G1)

Selections in HBOOT

Vol up/down to pick, Power to select

FASTBOOT

RECOVERY

FACTORY RESET

SIMLOCK

IMAGE CRC

Selections in FASTBOOT

BOOTLOADER

REBOOT

REBOOT BOOTLOADER

POWER DOWN

My Fastboot specs

VISION PVTR SHIP S-ON

HBOOT -O.82.0000

MICROP-0425

RADIO - 26.02.01.15_M2

eMMO-boot

Sep 2 2010.17:59:38

apologies if this is all common knowledge, i am trying to be helpful.
[G2 and Desire Z Android Development] thalin:
Isn't this a discrepancy with the specs of the system? That looks an aweful lot like 382 MB of memory that the system sees, when the specs say the device has 512 MB.

From my own G2, I found this in dmesg:

<6>[ 0.000000] Memory: 192MB 189MB = 381MB total
<5>[ 0.000000] Memory: 379136KB available (5120K code, 1515K data, 156K init, 0K highmem)

I propose that that missing ~128-130 MB of memory is what's being used as the write cache for the MMC device. This could I guess be done in hardware or low level device software, but this message appears very early in the kernel boot process so it would probably be below the OS level.

I hope this helps.
[G2 and Desire Z Android Development] ace42588:
mem for video?
[G2 and Desire Z Android Development] Disconn3ct:
Radio firmware owns the rest, same as on the other htc devices. Their radios are insanely huge..
[G2 and Desire Z Android Development] ace42588:
so where does all this leave us as far as an attack vector?
[G2 and Desire Z Android Development] gee one:
Will that pass sig tests and flash in the bootloader/hboot? Can you post it?

We need something flashable so that we can spoof us some hash.
[G2 and Desire Z Android Development] pconwell:
Has spoofing a hash <i>ever</i> worked?
[G2 and Desire Z Android Development] gee one:
I'm not sure if it worked on Android, but I think it has worked in other areas. It's called a collision- two files generate the same hash/signature. It's computationally easier than cracking 2048 bit RSA. Normally, it doesn't work well with text files because the user can see all the garbage that was added to spoof the hash. With computer files, there is probably enough open/useless space that can be modified to get the same hash.

One issue is that I am not clear on how many hashes we would need to spoof. .img files have a few parts to them and we would need to spoof every part that gets signed.
[G2 and Desire Z Android Development] damnoregonian:
you are correct. i verified that last night. people who claim otherwise are simply incorrect. the flash is *not* being written to. there is no shadow partition, there is no on-boot or on-shutdown reflashing.
[G2 and Desire Z Android Development] damnoregonian:
computationally easier yes, but still utterly infeasible. (assuming a weak hash like md5).

the only practiced collision i've seen was computed by a group with a couple dozen ps3s over a couple weeks to generate a collision and spoof a CA cert.

sha1 has theoretical but never exploited weaknesses.

i wouldn't bother looking in that direction. certificate loading and verification is the absolutely most exploited section of the embedded market. it's how i cracked the razr's "undowngradable" bootloader, it's how the bootrom exploit in the iphone works. it's complicated code, all you need is someone with a copy of ida, understanding of arm assembler, and time and a sprinkle of luck.
[G2 and Desire Z Android Development] nolsen311:
Is there an IRC channel or something that could be used for this sort of discussion/think-tanking? Missing a single day results in pages upon pages of responses with no real increase in knowledge. It would be just as easy to thinktank in a chatroom and update pages when knowledge has been increased.

Anyone?
[G2 and Desire Z Android Development] AnneThwacks:
Cache

I have programmed embeded systems, and one of the problems I had was that I wanted to save config data in program memory. The problem was that writing to flash is extremely slow, and required real-time oversight from the CPU. This required interrupts to be disabled and interfered with access to the memory for program execution while flashing.

My solution was that the data was "written" to flash when available - which put it in a shadow RAM, but it was not actually flashed until shutdown when interrupts could be disabled safely, as hardware that required interrupt service to work, could be powered down.

This looks like similar situation. Radios and displays both stand to fail fatally with interupts disabled,

My guess is that a flag needs to be set somewhere to enable "write from cache to flash" inside the flash chip during shutdown. This would activate the software procedure which manages the flash process.

Caveats: I do not work on mobile radios or write code for embedded processors in my present job, and my HTC Desire was bricked while trying to unroot it!
[G2 and Desire Z Android Development] gee one:
I've been out of Linux for a while and all I know about hardware is from a C-64, but I think to root via hash attack, we would need:

1) Something signed and flashable/hbootable/uploadable

2) Modify the file to allow root and spoof the sigs

It's not as easy as it sounds, but it's one vector.
[G2 and Desire Z Android Development] bentglasstube:
#g2root on freenode is where we are hiding.
[G2 and Desire Z Android Development] damnoregonian:
the problem you're describing is common on older NOR systems where the system was actually executing from flash.

on NAND, and even more so with eMMC, the chip has a controller on board and is represented to the micro as a high level interface. those kinds of problems aren't relevant with this kind of hardware and fully functioning high level operating systems.

I am an embedded systems developer by trade, and have done a lot of work on embedded cracking in my time (google scotty2 razr).

if the eMMC chip can have its write protect flags altered after they've been set, this will be an easy root once someone can load a kernel module, if it can't, then that leaves recovery and hboot as the only flashing vectors.

we have dumps of both, so it is only a matter of time.

i spent 500 dollars on this phone, i can guarantee that i will find it if no one else does faster. i don't like locked down hardware.
[G2 and Desire Z Android Development] pconwell:
I know what a collision is, it's just not going to work without A LOT of computer power. The G2 will be obsolete before we get root this way (unless we get REALLY lucky).
[G2 and Desire Z Android Development] alansj:
And, in particular, it is a "preimage" attack:

http://en.wikipedia.org/wiki/Preimage_attack

The PS3-based crack was based on a weakness in MD5, which is almost certainly not used in this case (probably SHA-1 instead):

http://phreedom.org/research/rogue-ca/

What do you mean "certificate loading and verification"? You mean somehow writing to the portion of memory that does cert checking such that it bypasses verification?
[G2 and Desire Z Android Development] damnoregonian:
if by secondary location you mean cache, then you'd be correct. if you think it's going to a different portion of flash, you'd be wrong.

also, hboot is in fact setting the write-protect flags on the eMMC before handing off to the kernel. i have module loading working, and can dump all the symbols and values from within the kernel to dmesg. i suspect it doesn't set the flags when it hands off to recovery.

next step for me is to see if i can play with the CSD, but i don't have any way to know it's address yet at this point.
[G2 and Desire Z Android Development] 80hd:
throwing this out there

about 95% of you seem more knowledgeable with linux than myself but I was wondering about the possibility of this just being a really good software rootkit.

If such a program were hiding it's presence, logging any write activity done to key files it is set to watch and then replacing them on reboot or an unknown time schedule, would that not explain what we are seeing?

I don't have a g2 but I was wondering if it's known if all the files were reset at the same time or if it was over a span of time. This might clue us in to knowing if this is hardware of software protection at work.

This would also explain why there seems to be a discrepancy in the reported size of the 4gb MMC between US and european versions. If the hardware was simply redirecting all writes to a cache, it doesn't make much sense for the phone to need a hidden partition with a complete copy of the image. Whereas a software rootkit could make a list of files it needs to repair and then do it on reboot - which also explains why boot after rooting only adds 5 seconds instead of minutes which a OS-wide checksum would seem to need.

(if this is totally bogus let me know and I'll just go back to observing)
[G2 and Desire Z Android Development] damnoregonian:
ya, i've read about the ps3 attack, and that's why i mentioned feasibility (barely) assuming a weak hash like md5.

sha1 has only theoretical exploitability, meaning current hardware and algorithms aren't there yet.

what i mean by certificate loading and verification, is:

an image is just an image, it is nothing but hashed and/or checksummed until the certificate/signature is processed, thus the easiest attack vector is looking for a buffer overflow or a stack smash on the certificate processing code. the cert/sig is the one area where we can force their code to actually process whatever garbage we want in hopes of exploiting a bug.

if you're a god amongst men, you can analyze the disassembly of the cert loader and see an exploit, i'm not that good. but in the 2 areas where i have experience with such things (moto razr, iphone) i found the exploits by replacing the cert/sig depending on the image format with complete garbage or tagging **** to the end of it until i got the phone to crash when it read it. once it crashes, you dig through the assembly finding out why. sometimes, (more often than not), this leads to finding a way to exploit the crash with unsigned code execution.
[G2 and Desire Z Android Development] damnoregonian:
i can't explain why the kernel is only using 2gb of the eMMC with its partition map. what i can tell is that direct writes to the block device are failing and not being logged or complained about.

while it is possible that there really is a repair mechanism going on, a cache is a much better solution. it's faster, it results in the same effect, and there is no wearing of the eMMC. you can flush the cache for the block device and watch the changes disappear right before your eyes.
[G2 and Desire Z Android Development] AustinAce:
Touchpad button + Power = Fastboot

Volume down + Power = HBOOT

You can also get into recovery and Hboot from here as well.

Factory reset

simlock

and Image CRC

Edit: the 3 finger solute to reboot it is Power + Volume Down + and the middle black button underneath the screen
[G2 and Desire Z Android Development] grivad:
Touchpad button + Power = Fastboot

Volume down + Power = HBOOT (edit: read: Bootloader)

FTFY ; )
[G2 and Desire Z Android Development] xile6:
what is sim lock? does it lock the phone to the simcode(network) that is in the phone or is this something else?

sorry i know its off topic
[G2 and Desire Z Android Development] derek4484:
Mostly right. It does have a rootkit that reflashes back to stock after tampering.

http://www.dslreports.com/shownews/G2-Comes-With-A-Free-Rootkit-110745
[G2 and Desire Z Android Development] Weaseal:
The irc thinktank is #g2root on freenode. It bounces between highly active collaboration and dead idleness throughout the day.
[G2 and Desire Z Android Development] AustinAce:
lmao my bad, I was messing with it on my own thank you though. :)

anyways back on topic
[G2 and Desire Z Android Development] damnoregonian:
citing bad press that indirectly uses this very thread as its proof of a root kit is not helpful to the cause here.

there is absolutely no evidence of there being any root kit, evidence presented indicates rather that we're simply dealing with write protected flash and caching.

http://www.dslreports.com/shownews/G2-Comes-With-A-Free-Rootkit-110745 cites

http://oti.newamerica.net/blogposts...s_unexpected_feature_a_malicious_root_kit-380 which cites

http://xdaforums.com/showthread.php?t=794053

which should look familiar.
[G2 and Desire Z Android Development] krayshunist:
What we're dealing with is more hardware than anything. The SSD does not allow writes to the section that contains the system and what creates trouble for us is that we can't turn off that write protection.

Have you ever used a SanDisk Cruzer USB flash drive? Do you know how when you put it into a Windows box the stupid U3 app installs and manages the stick? When you reformat it, the U3 is still on there and doesn't show up on any partition manager. The only way to uninstall it is through the software, which turns off the write-protection in that section of the chip and deletes the software. The G2 has a similar setup but on a larger scale.

I suspect this wasn't done to prevent rooting but rather to prevent system damage from bad software and crapware by clearing any such changes at boot. A side-effect of this, of course, is that it makes rooting just a tad harder.
[G2 and Desire Z Android Development] digikid:
Hey guys, I just wanted to report that the system seems to be fixing itself on the fly. I temp rooted yesterday, haven't rebooted my phone, and I no longer have root. The phone didn't reboot on it's own either.

Perhaps the cache is emptying every so often on it's own??? o.ô
[G2 and Desire Z Android Development] sino8r:
I think that makes the most sense...

I know someone has meantion that the changes were being written during power down. Has anyone attempted to soft root, remove/replace something in /system, and then pulled the battery? I know that is a REAL shot in the dark but at least we could confirm when its happening...
[G2 and Desire Z Android Development] damnoregonian:
yep :/

i would get partial cache flushes, where files i put on /system would still be there, but flags i had changed (u+s) hours later would magically revert back.

i think we're actually lucky it's as functional as it is.
[G2 and Desire Z Android Development] damnoregonian:
yes, you can pull the battery, boot directly into hboot, and do an image crc.

it *doesn't* happen.

it doesn't ever restore anything. changes are either going directly to cache, or possibly (however unlikely since it would make no sense) to another portion of flash.

but if you write a ton of things to either the filesystem, or directly to the block device, sync, and pull the battery, the image crcs do not change.
[G2 and Desire Z Android Development] sino8r:
On the contrary, it might have the opposite effect. It might draw in hackers looking for a real challenge.;)
[G2 and Desire Z Android Development] damnoregonian:
i will concede that point :)

however - it's still analogous to wikipedia using a citation of a page that is a blogged digest of the wiki page.

it leads someone with less critical thinking skills to take the 'root-kit' theory as proof.
[G2 and Desire Z Android Development] sino8r:
Hahhaha! Well... those drones don't really deserve to have a G2 that might take a few internet articles as Gospel. They belong to apple...
[G2 and Desire Z Android Development] SilentStorm:
U3!

Since the eMMC on the G2 is made by SanDisk and you mentioned U3, why dont you guys take a look at U3Tool? Maybe it can provide some hints to make this nasty eMMC behave? It readily runs on linux and can command latest U3 drives rather well...

If I were a SanDisk engineer, I'd definitely use same commands to control chip properties for efficiency (and yes, I'm a computer engineer by profession).
[G2 and Desire Z Android Development] gee one:
What do the CRCs look like? Are they the same for everyone? I don't have a G2, so I can't see it for myself.
[G2 and Desire Z Android Development] bled82:
Ok so im guessing we can't enable adb in recovery because its write protected is this correct ? I did not see anyone mention enabling it in the previous 60+ pages .
[G2 and Desire Z Android Development] sino8r:
Only offline or while the phone is on...
[G2 and Desire Z Android Development] krayshunist:
If the SSD on the G2 doesn't use the same commands it should be very similar. But the problem is not with the commands, it's with authenticating to the SSD. We don't know how to tell it that we're allowed to make the changes we want.

The recovery and the boot loader should know how to change the write mode on the SSD, I suspect. After all they'll need it to apply any updates T-Mobile pushes to the G2.
[G2 and Desire Z Android Development] sino8r:
I see there is an option in the bootloader for it. I tried it but not sure where it is being written to..
[G2 and Desire Z Android Development] bled82:
Well i was thinking of how the slide was rooted using adb in recovery , is there a way to modify adb so instead of offline being displayed when the device is in recovery it would switch to show recovery so we could push a file like we did with slide ?
[G2 and Desire Z Android Development] mattseg:
I'm certainly not a leet haxor... but. Logically the area that houses the stock row can't be an island itself, as has been pointed it would need to be updated at some point.

Again, logically, it seems that an OTA update will have a key to pandoras box... so, those of us that are dev challenged should be enlisted to pitch a fit if we can find something that will give 'them' cause to issue an update.
[G2 and Desire Z Android Development] russrad:
I apologize as I don't have time to go through this whole thread, but having just seen the news of the OS overwrite on root/reboot issue, I have a suggestion (that has probably already been thought of):

If T-Mobile can update the OS, it seems like this would have to be written to the chunk of memory that is used to re-install the stock OS. Permanently rooting this phone could theoretically be accomplished by determining how they access this memory and then making the rooting modifications directly into it.

Sorry if this is simply repetition...
[G2 and Desire Z Android Development] mattseg:
dude... I said it in the post above yours, and it had been pointed out before.
[G2 and Desire Z Android Development] damnoregonian:
just hboot has to know, technically.

it simply needs to enable writing when booting to recovery, disable when booting regular.
[G2 and Desire Z Android Development] damnoregonian:
t-mobile pushes update ota.

android writes to cache partition, sets reboot flag to boot to recovery on next boot.

next boot hboot sees it's supposed to boot into recovery, removes write protect, boots recovery.

recovery checks cache and sees it has to do an update, verifies keys, and either does or does not update.

the process is well known, the question is whether there are existing unfixed recovery update exploits floating around.
[G2 and Desire Z Android Development] HamNCheese:
1) it exposes a partition with an overlay. That partition happens to be mounted r/o at boot time. Changes go to the overlay, and linux is apparently unaware of this (ie. ext3 errors)

2) maybe

3) no

4) no, the bootloader is the one marking partitions read-only. This "bit" is set there and remains in effect until a hardware reset.

5) absolutely false. It is PKI (RSA, probably 2048 bit), symmetric encryption would be completely retarded of them to use, as it would be trivial to pick the key out of the NAND if connected directly (ie. JTAG)
[G2 and Desire Z Android Development] damnoregonian:
1) sorry, but nope. the fact that we can cause it to revert with a cache flush tells us that isn't the case.

2) maybe is right. the fact is, 2gb are not in linux's partition map. who knows what they're used for, but linux can't touch them as currently compiled.

3) you are correct. the eMMC chip has no jtag. it's simply a bulk memory device. it also has no idea if the micro is talking to it through its own software, or software uploaded through a jtag interface.

4) i suspect you are correct.

5) your conjecture is incorrect. while i agree it probably is asymmetric encryption, symmetrical is perfectly logical. arm chips have had efused symmetric (usually aes) keys in them for half a decade. the iphone uses these.