• Announcements

    • PaulOBrien

      Reminder - MoDaCo position on illegal content   07/30/15

      ILLEGAL CONTENT I'd like to just reaffirm MoDaCo's position regarding piracy and illegal content in the light of some recent questions / postings. Posts will be censored by myself or my moderation team if the contain or link to: Illegal / pirated / cracked software or sites that host such software Nintendo emulators / ROMs or sites hosting them (in light of Nintendo's legal stance) CUSTOM ROMS You may discuss and post links to custom device ROMs on MoDaCo, provided the following rules are adhered to: ROMs must not contain any illegal 3rd party software (this includes trial versions included without permission) ROMs must give full credit to the original author ISSUES If you have any issues with this policy, please contact PaulOBrien directly via PM.
    • PaulOBrien

      Reminder: Selling items on the forum directly is not allowed   07/30/15

      Please note that selling items on the forum directly is not allowed by the forum rules. There is a forum for eBay auctions whereby you can list the items on eBay and link to them there. This is the ONLY forum for this type of activity. You may also advertise links to the eBay forum in your signature. Please note that selling directly in contravention of these rules will result in a warning / suspension / ban.
ZeBadger

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

203 posts in this topic

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:

0

Share this post


Link to post
Share on other sites
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!

0

Share this post


Link to post
Share on other sites

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 )

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites
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:

0

Share this post


Link to post
Share on other sites
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.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites
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).

0

Share this post


Link to post
Share on other sites

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?

0

Share this post


Link to post
Share on other sites
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.

0

Share this post


Link to post
Share on other sites
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.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites
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.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites
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 by ZeBadger
0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

Any news about packing updata.app?..

0

Share this post


Link to post
Share on other sites
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.

0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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 by Speckles
0

Share this post


Link to post
Share on other sites
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.

0

Share this post


Link to post
Share on other sites
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 by ZeBadger
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

MoDaCo is part of the MoDaCo.network, © Paul O'Brien 2002-2016. MoDaCo uses IntelliTxt technology.