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

[Guest ZeBadger]

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

Having looked at the numbers, this isn't likely to happen without writing a virus to infect millions of PCs to do the number crunching for us... which I'm not going to do. So until a weakness in the algo is found then I think we are at a non-starter :lol:

[Guest ZeBadger]

Having looked at the numbers, this isn't likely to happen without writing a virus to infect millions of PCs to do the number crunching for us... which I'm not going to do. So until a weakness in the algo is found then I think we are at a non-starter :lol:

Although that wont stop me from continuing looking into it. And if Speckles can work out how to do this injection thing then that would be a good start!

[Guest Speckles]

I'm still interested in how this thing works, so I'm still going :lol:

(I'm not really that interested in having a working updata.app, I'm just interested in how it all glues together, kinda like most things I pulled apart since I was about 6 :D )

[Guest Speckles]

Here's an interesting snippet for you:

LDRH	R1, [R4,#0x5E] ; (94) unknown, always 1

LDR	 R0, [R4,#0x18] ; (24) file length

ADD	 R0, R0, R1	 ; add them together and subtract one. wtf?

SUB	 R0, R0, #1

Yup, it takes the file length from header, adds the "always 1" field (the two bytes after the Something2) and then subtracts one. Why? I don't know.

[Guest DanWilson]

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.

Ahem *Bobo* Ahem. Or a spy. Does anyone know any spies? We need some spies. :lol:

[Guest Tom G]

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

I was thinking about that yesterday. The emulator won't do it as it is designed to load a linux kernel (in the format used by android), but maybe a more generic emulator like qemu (which is what the SDK emulator actually runs on) could be used. If it could run in an emulator it should then be possible to run a debugger on it.

The SDK doesn't emulate any hardware so it can't emulate the Updater.

The SDK emulates all of the hardware, how else do we get a full arm system running on a pc.

[Guest Speckles]

The SDK emulates drivers, not hardware. So Android applications can use all the typical modules on Android devices such as touchscreen.

The updater app, since it runs before the linux kernel, talks to the hardware directly. The SDK can't emulate this style of access.

[Guest McSpoon]

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 think the UPDATA.APP format is only used by Huawei. However it does share some similarities with the .DZ format used by LG, and presumably others. In this thread on XDA they're dissecting a .DZ file for the LG KS20 (Windows Mobile) and a lot of the structure is remarkably similar. That format uses MD5 hash strings for checksums but it's interesting how both file formats share a similar structure (albeit it still doesn't help).

[Guest Speckles]

Just a quick update on this: There seems to be some data (I'm assuming encryption keys) stored in the phones memory. We need this data to create our own updata.app, else it'll never be authenticated as OK by the phone. I'm currently trying to find out where this data is and how to access it. I'm assuming every phone will be the same, as everyone would need different update files.

It searches magical constants like 0xFE569FAC, 0xCD7F127A, 0x55EE73AA & 0xE35EBDDB. The last two I recognise (they are to do with partitions), I've no idea about the first two. Anyone?

[Guest ZeBadger]

Just a quick update on this: There seems to be some data (I'm assuming encryption keys) stored in the phones memory. We need this data to create our own updata.app, else it'll never be authenticated as OK by the phone. I'm currently trying to find out where this data is and how to access it. I'm assuming every phone will be the same, as everyone would need different update files.

It searches magical constants like 0xFE569FAC, 0xCD7F127A, 0x55EE73AA & 0xE35EBDDB. The last two I recognise (they are to do with partitions), I've no idea about the first two. Anyone?

We need 216 bytes for a public key.

[Guest gusthy]

Here's an interesting snippet for you:

LDRH	R1, [R4,#0x5E]; (94) unknown, always 1

LDR	 R0, [R4,#0x18]; (24) file length

ADD	 R0, R0, R1	; add them together and subtract one. wtf?

SUB	 R0, R0, #1

Yup, it takes the file length from header, adds the "always 1" field (the two bytes after the Something2) and then subtracts one. Why? I don't know.

If you are absolutely sure that R1 always loads literal 1, then ignore the problem, and assume it is the file length.

[Guest Speckles]

216 bytes? It doesn't seem to use that value anywhere. It seem uses values such as 0x80 (expected, its the length of the md5 section), 32 (which happens to be 128/4, and I just happen to see it loading the data into words, so it makes sense), and 0x800 (no idea what that is yet, but this table is accessed a LOT during the md5 section parsing) - I can only guess it's part of the OEM info structure at the moment.

[Guest ZeBadger]

216 bytes?

I used this link to work out how to create a 1024-bit private and public key. I then used file02.mbn to create my own digest so that I could see how this all works.

Private Key : 812 bytes

Public key : 216 bytes

Digest : 128 bytes

I also tried a 512-bit key... sizes were much smaller (pr : 424, pub: 128, dig: 64)

Please bear in mind this is the first I've ever looked at md5 signing... I could be doing something wrong.

[Guest Speckles]

Or it might not even use private & public keys. It could be using something else.

I only guessed at private/public keys as it's a common thing used to sign an md5 digest.

We should know in time.

[Guest ZeBadger]

Or it might not even use private & public keys. It could be using something else.

I only guessed at private/public keys as it's a common thing used to sign an md5 digest.

We should know in time.

I was thinking that we could truss/profile the execution of verifying the digest with public key using the openssl command and then see if the behaviour looks similar to what you've disassembled from the file05.mbn. ltrace seems to be the program to use.

I've attached the output using my own keys

ltrace openssl dgst -verify mykey.pub -signature digest.txt ../DecemberUpdate/dload/output/file02.mbn 2> ltrace.out

ltrace.txt

Edited July 7, 2010 by ZeBadger

[Guest Speckles]

Ok, this is how I think it works:

A function is called (functionA), passed with 128 bytes of data (I'm not sure where this data comes from - I'm assuming the MD5 section) and another buffer which I'm going to call "Buffer B".

Another function is called, passed an unknown amount of data. It's second parameters is a buffer I'm going to call "Buffer C". This function uses constants known to be used by the MD5 digest algorithm.

A third function is called, passed with Buffer B and Buffer C. It returns 0 if the buffers match and 1 if they don't. The size of the compare is 16-bytes (standard MD5 digest size)

FunctionA does a LOT of work, calling many functions, including searching nand for text strings such as "OEM_INFO" and magic constants like I've pasted in a previous post.

I'd LOVE to know what FunctionA returns, but I can't run it in it's native environment, and it accesses hardware on the phone directly (doesn't use drivers).

[Guest anegin]

Any news about packing updata.app?..

[Guest ZeBadger]

Any news about packing updata.app?..

Not really looked into it since I got stuck with this md5 certificate thing. Decompiling the updating app is where to go, but I don't think I would be able to get that sorted... although as said above it seems to be referencing the private key from the phone not from the update app. So the only possible way of getting over that would be to open the phone up and physically read the data bus while the update process is in progress, similar to how some consoles were hacked, but that is a little over the top.

[Guest McSpoon]

I found some instructions on how the updata.app is packaged. It lists the commands they use for generating the CRCs but unfortunately we don't have their software so it isn't much help. I posted the commands in another thread but I figure it's worth mentioning them here just for the sake of keeping all of the CRC references together.

The seccode looks intriguing but I've no idea what it is.

I'm guessing their crc.mbn is our file02.mbn

The 'addr0x**000000' parameters must be the file sequence identifier (the fileHash array in our Perl script).

...Trying to unravel this makes my head hurt.

1. Eliminate old upgrade package

@if exist dload\updata.app del /f /a dload\updata.app

2. Calculate CRC of all files

..\tools\CRCgen -ibin BINs\header\boothd.img BINs\boot.img BINs\header\systemhd.img BINs\system.img BINs\header\userdatahd.img BINs\userdata.img BINs\header\recoveryhd.img BINs\recovery.img -o crc.mbn

3. Making CRC files into a package module

..\tools\bin2app -F -iBin crc.mbn addr0xF4000000 seccode0x48575538323230FF descinput -o crc_v.bin descHUAWEI_U8220_CRC_BEIJING

4. Making boothd.img into a package module

..\tools\bin2app -F -iBin BINs\header\boothd.img addr0xF5000000 seccode0x48575538323230FF descinput -o boothd_v.bin descHUAWEI_U8220_CRC_BEIJING

5. Making boot.img into a module

..\tools\bin2app -F -iBin BINs\boot.img addr0x30000000 seccode0x48575538323230FF descinput -o boot_v.bin descHUAWEI_U8220_CRC_BEIJING

6. Making CRC module and boothd.img module into a package together,creating a temporary file temp13.bin

..\tools\bin2app -F -iAPP crc_v.bin boothd_v.bin -o temp13.bin descHUAWEI_U8220_BEIJING

7. Making temporary files temp14.bin and boot.img together,creating temporary file temp14.bin

..\tools\bin2app -F -iAPP temp13.bin boot_v.bin -o temp14.bin descHUAWEI_U8220_BEIJING

8. Repeat the same operation as step 4 to 7,making system,userdata and recovery together, finally creating dload\UPDATA.APP.

..\tools\bin2app -F -iAPP temp19.bin recovery_v.bin dload/updata.app descHUAWEI_U8220_BEIJING

[Guest Speckles]

We could probably do it by reflashing the portion of nand which contains the update executable from recovery, but if you get it wrong - bricked phone. If you get it right, it'll work until the next update reflashes the updater again.

It would also be confusing for people, as they would have to ensure they have the special updater before trying to flash a user-created updata.app.

Or we could build another recovery app that can parse updata.app's and doesn't care about the signature. However, we could only flash the sections we understand, in which case, you might as well just use fastboot.

[Guest Speckles]

McSpoon: Very interesting, can you post that PDF?

seccode is just "HWU8220" in hex.

I'm thinking the file sequence id was misnamed - it is actually a flash address 0xF5000000 etc

Edited September 7, 2010 by Speckles

[Guest McSpoon]

McSpoon: Very interesting, can you post that PDF?

Sure. PDF attached.

S7_V100R001C01_Upgrade_User_Guide.pdf

[Guest ZeBadger]

I'm thinking the file sequence id was misnamed - it is actually a flash address 0xF5000000 etc

Possible... I made up the file sequence id name as they were unique per file.

[Guest ZeBadger]

8. Repeat the same operation as step 4 to 7,making system,userdata and recovery together, finally creating dload\UPDATA.APP.

..\tools\bin2app -F -iAPP temp19.bin recovery_v.bin dload/updata.app descHUAWEI_U8220_BEIJING

This might just do exactly what we want. We could much more easily reverse engineer bin2app (if we even need to!)

Edited September 7, 2010 by ZeBadger

[Guest Speckles]

Possible... I made up the file sequence id name as they were unique per file.

I'm not knocking your idea, it's still the best way to decide what each file in the archive is.