Repacking UPDATA.APP (was New version of split_updata.pl)

[Guest Speckles]

Ok, I've looked for the typical MD5 constants (such as 0x98badcfe, 0x10325476, etc) in the disassembled Updater and found them. I've then calculated the offsets for these and look for cross-references to where in the code they might be used - that pointed me to what looks like MD5 calculation code. I've xref'd calls to this code and found a call with a conditional jump after it setting register R0 to 0x13. Doing the same with "Failure: MD5_RSA verify failure" takes me to what looks like a jump table. Xref that and you find it's number 19 in that jump table. As you know, 0x13 == 19, so hopefully I found the code that does the checking :lol:

What it does I don't know yet. I'll look at that tomorrow.

[Guest ZeBadger]

Ok, I've looked for the typical MD5 constants (such as 0x98badcfe, 0x10325476, etc) in the disassembled Updater and found them. I've then calculated the offsets for these and look for cross-references to where in the code they might be used - that pointed me to what looks like MD5 calculation code. I've xref'd calls to this code and found a call with a conditional jump after it setting register R0 to 0x13. Doing the same with "Failure: MD5_RSA verify failure" takes me to what looks like a jump table. Xref that and you find it's number 19 in that jump table. As you know, 0x13 == 19, so hopefully I found the code that does the checking :lol:

What it does I don't know yet. I'll look at that tomorrow.

My friend was telling me about something he has been looking at recently... they gzip'ed and XORd the whole file with A5. So rather than encryption, it could be something as simple as this kind of obfuscation.

[Guest Speckles]

I've seen those kind of tricks on the Gizmondo - they XOR'd the entire update file with 0xFF. It was kinda obvious though to be honest, as if you viewed the file with a hex editor, there was a LOT of 0xFF's in the file, so it was the first thing I tried :lol:

[Guest Tom G]

I haven't been following this thread much recently, so sorry if this has already been suggested.

Do we know what it is that applies the UPDATA.APP on the phone. If it is a part of the bootloader then we know that at least the fastboot part of the bootloader was upgraded in the eclair update and it is probably safe to assume the whole bootloader was upgraded, so the compiled code to apply the UPDATA may be somewhere in the eclair update. If you can identify the compiled code and run it through a disassembler (something like IDA Pro) you might be able to get an idea of what it is doing when the update is applied.

I know assembly code isn't much fun to read, but it may be a different way to approach the problem.

[Guest Speckles]

Yes, we figured that out back at post #30 or so - that's where I ripped the crc algo and tables from to make sure they were not different than standard :lol:

[Guest ZeBadger]

The only files with checksums not in the file02.mbn file are file01.mbn and file02.mbn.

Everything else is in there and there are no spare bytes. So it's only checksums in there.

Edited July 1, 2010 by ZeBadger

[Guest Speckles]

So, is the file01.mbn use the entire 128 bytes for a single MD5, or is there multiple MD5's in there?

The updater code looks very messy, and doesn't look like a single pass, so I guess there's only really one way of finding out. Change the last byte of the MD5, recalculate the crc and apply. See if it throws up an error on "preparing", "Unpacking" or "Installing", if any. Keep changing bytes until something different happens :lol:

We might find the first 16 bytes contains the MD5 of the CRC file.

[Guest ZeBadger]

I've written some c code to chop up files based on start and end position.

I've also written a shell script to process the UPDATA.APP file from byte 320 (start of file02 header) and byte 442 (start of file02 file) to n, n+1, n+2 etc... up to the filesize of UPDATA.APP. If it finds a match for the md5's we should know by morning... unless my pc melts!

[Guest DanWilson]

Is the Pulse the only phone that uses UPDATA.APPs? Cos if other phones use it like HTC, surely XDA would have it sussed by now?

[Guest Speckles]

Nice one, ZeBadget. The only thing that concerns me is the 128 bytes, which is the typical size of a signed MD5 digest, but I don't see any RSA-stuff in the code.

[Guest ZeBadger]

Nice one, ZeBadget. The only thing that concerns me is the 128 bytes, which is the typical size of a signed MD5 digest, but I don't see any RSA-stuff in the code.

Isn't that 128 bits (16 bytes)?

[Guest ZeBadger]

I've written some c code to chop up files based on start and end position.

I've also written a shell script to process the UPDATA.APP file from byte 320 (start of file02 header) and byte 442 (start of file02 file) to n, n+1, n+2 etc... up to the filesize of UPDATA.APP. If it finds a match for the md5's we should know by morning... unless my pc melts!

Hmm, only 16MB through the file so far... will have to suspend until tonight (so the missus can use the pc today)... and I just spotted a bug which means it was looking for the MD5 with " -" at the end.... fail. Will have to restart tonight. Looks like it will take a while!

Edited July 2, 2010 by ZeBadger

[Guest Speckles]

Isn't that 128 bits (16 bytes)?

An MD5 digest is 128 bits (16 bytes). A Signed (using a private key) MD5 digest is typically 1024 bits (128 bytes).

[Guest ZeBadger]

An MD5 digest is 128 bits (16 bytes). A Signed (using a private key) MD5 digest is typically 1024 bits (128 bytes).

I see, I think you are right. That will extend this project a little.

There's some good reading about these things here

Edited July 2, 2010 by ZeBadger

[Guest ZeBadger]

Is the Pulse the only phone that uses UPDATA.APPs? Cos if other phones use it like HTC, surely XDA would have it sussed by now?

I've just searched their forums and "UPDATA.APP" matches no posts, without quotes it matched Update app... which aint what we're looking for.

[Guest Speckles]

At the moment, I would be happy to just verify the signature. We can work out how to cause an appropriate md5 collision later (Ie. Don't attempt to generate a new signature, just modify the data as such to cause the existing signature to work as it'll generate the same MD5 hash)

I've checked the code and noticed that any MD5 greater than 128 bytes gets thrown out as "MD5 is overflow".

[Guest ZeBadger]

At the moment, I would be happy to just verify the signature. We can work out how to cause an appropriate md5 collision later (Ie. Don't attempt to generate a new signature, just modify the data as such to cause the existing signature to work as it'll generate the same MD5 hash)

I've checked the code and noticed that any MD5 greater than 128 bytes gets thrown out as "MD5 is overflow".

Can you find out what the public key is by reverse engineering the update binary? I have a friend who is heavily into crypto ... and I bet I can at least get some pointers from him.

I was thinking of trying to crack the private key using a distributed bruteforce attack... users of the forum could help us, but we need to work out how long this would realistically take to crack... if it's 2 years for 100 PCs dedicated to this then there's no point in even starting!

I'm guessing that the MD5 is only of the contents of file02.mbn file. I'll be able to confirm this with a few tests.

Edited July 2, 2010 by ZeBadger

[Guest Speckles]

I'm guessing that the MD5 is only of the contents of file02.mbn file. I'll be able to confirm this with a few tests.

That would be my understanding too, but how are you going to confirm it? If you don't edit file02.mbn you'll get a crc error first, and if you don't, MD5 error.

I wonder if I can trace the location in memory that file02 is stored and search for this location to see where else it is used?

Damn, this would be so much easier if we could actually run the updater and step through it.

[Guest DanWilson]

Is there no way to emulate a Pulse on the Android SDK? It's hopeful but then you wouldn't need to copy the file to the Pulse, and maybe even be able to see exactly what it does...

[Guest Speckles]

The Updater runs way before Android OS starts up, heck even before the Linux Kernel. The SDK doesn't emulate any hardware so it can't emulate the Updater.

[Guest DanWilson]

The Updater runs way before Android OS starts up, heck even before the Linux Kernel. The SDK doesn't emulate any hardware so it can't emulate the Updater.

DAMN YOU HUAWEI!!!

(Can't we ask them how they sign it? It's worth a shot surely?)

Edited July 2, 2010 by DanWilson

[Guest Speckles]

Considering they won't even give us the "should be public" Kernel source code, I very much doubt they are going to tell us how to sign update binaries, and even if they did, we'd still need there private key which is even less likely.

There might still be a way around it however, given time.

[Guest TheBrownBottle]

Considering they won't even give us the "should be public" Kernel source code, I very much doubt they are going to tell us how to sign update binaries, and even if they did, we'd still need there private key which is even less likely.

There might still be a way around it however, given time.

Is the November 2009 download in the link not the kernal source code? I downloaded it once and that was the impression I got. I may be wrong though. :lol:

http://support.t-mobile.co.uk/help-and-sup...FTWAREDOWNLOADS

[Guest ZeBadger]

Is the November 2009 download in the link not the kernal source code? I downloaded it once and that was the impression I got. I may be wrong though. :lol:

http://support.t-mobile.co.uk/help-and-sup...FTWAREDOWNLOADS

I think the stuff they offer is just their modifications that they have made to the android OS. Unfortunately this wont be of any use for re-assembling the UPDATA.APP

[Guest TheBrownBottle]

I think the stuff they offer is just their modifications that they have made to the android OS. Unfortunately this wont be of any use for re-assembling the UPDATA.APP

Shame! Good luck with this. It'll be a massive achievement if you crack it.