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

[Guest McSpoon]

That is the trouble with hacking the UPDATA.APP files. You could brick your phone if anything is wrong.

Maybe Something2 is the location for writing the file to and sending it to the wrong region of the phone might cause some permanent damage. But it's only 2 bytes, so it's unlikely to be that. We just don't know.

[Guest BigBearMDC]

That is the trouble with hacking the UPDATA.APP files. You could brick your phone if anything is wrong.

Maybe Something2 is the location for writing the file to and sending it to the wrong region of the phone might cause some permanent damage. But it's only 2 bytes, so it's unlikely to be that. We just don't know.

Yeah but I think thats a good point.

The location where this file has to be copied to must be noticed somewhere also.

But this could be stored seperatly too.

But for me it looks like the UPDATA itself is a executable application, as it even has CRC checking etc. in it.

So it might be possible to boot the UPDATA even if everything else is screwed - maybe even fastboot.

Edited June 26, 2010 by BigBearMDC

[Guest Speckles]

Ok, now I'm confused. As I suspected, thats a CRC algorithm. After rebasing the code, I see the table. At position 128 in that table is 8408. This is our poly.

8421842184218421 - 8408

1000010000001000

1248124812481248 - 1201

Bog Standard CCITT CRC 16, which ZeBadger is already using. Damn.

Now for the extra weird thing: There are other routines using this exact table, but with slightly altered code :lol:

[Guest Speckles]

But for me it looks like the UPDATA itself is a executable application, as it even has CRC checking etc. in it.

So it might be possible to boot the UPDATA even if everything else is screwed - maybe even fastboot.

No, the file I'm disassembling is file05.mbn within UPDATA. It seems to contain everything to reflash the phone. It has all the code to parse this UPDATA file. Therefore, I'd say this is the updater application itself. It seems UPDATA can reflash the entire phone, including fastboot, the updater itself, etc.

[Guest BigBearMDC]

No, the file I'm disassembling is file05.mbn within UPDATA. It seems to contain everything to reflash the phone. It has all the code to parse this UPDATA file. Therefore, I'd say this is the updater application itself. It seems UPDATA can reflash the entire phone, including fastboot, the updater itself, etc.

Ah okay, so there must be some additional software on the phone.

But there might still be the chance that this software is stored on a real ROM, thus being not re-flashable.

There would be only one way to find this out I guess - knowingly screwing up the device.

But that's insane :lol:

[Guest ZeBadger]

Maybe Something2 is the location for writing the file to and sending it to the wrong region of the phone might cause some permanent damage. But it's only 2 bytes, so it's unlikely to be that.

It's also a little too random.

[Guest ZeBadger]

No, the file I'm disassembling is file05.mbn within UPDATA. It seems to contain everything to reflash the phone. It has all the code to parse this UPDATA file. Therefore, I'd say this is the updater application itself. It seems UPDATA can reflash the entire phone, including fastboot, the updater itself, etc.

I suspect that file05.mbn is the new flasher... and the old one is used for the current flashing.

[Guest Speckles]

Yes, I would hope there was two versions of the flasher - one stored in ROM and one stored in Flash. If the CRC of the flash version is correct, it would run that one, else it would run the rom version.

One way to find out: Buy a PAYG pulse, flash it until its bricked, and then take it back and say you don't want it because it doesn't work :lol:

EDIT: Hmmm, I have a cunning plan...

Edited June 26, 2010 by Speckles

[Guest Speckles]

Ok, I've run that crc code I posted earlier :lol:

Strange result: For a one byte file (0x00) I get the result: 0x0804 (or 0x0408 depending on how you want to interpret it) which I don't get with ZeBadger's crc routine (I get 78F0 instead). Any ideas?

Here's a screenshot: Pic 1

Now, I need to sleep.

Edited June 26, 2010 by Speckles

[Guest ZeBadger]

I suspect that file05.mbn is the new flasher... and the old one is used for the current flashing.

We can prove this by modifying the error text slightly in the new rom and re-flashing.

[Guest ZeBadger]

Ok, I've run that crc code I posted earlier :D

Strange result: For a one byte file (0x00) I get the result: 0x0804 (or 0x0408 depending on how you want to interpret it) which I don't get with ZeBadger's crc routine (I get 78F0 instead). Any ideas?

Here's a screenshot: Pic 1

Now, I need to sleep.

Strange that 0x0804 is exactly the same as my result for 4096 bytes of 0x00. :lol:

EasyHash shows a single null byte to be 0xF078 for CRC16 (X25). Can't see an algorithm in that which produces 4096 bytes for a single null byte.

Edited June 27, 2010 by ZeBadger

[Guest Speckles]

We can prove this by modifying the error text slightly in the new rom and re-flashing.

Which it will probably ignore for either checksum or Something2 reasons? But yes, once we work these out, it would be a nice test. Edited June 27, 2010 by Speckles

[Guest BigBearMDC]

Which it will probably ignore for either checksum or Something2 reasons? But yes, once we work these out, it would be a nice test.

If we got the ASM code of the CRC checking routine, why don't we just edit it to always return true?

Thus we could also check if it gets flashed everytime or only when it has to be updated.

[Guest Speckles]

We can do that, but if the checksum is incorrect in the UPDATA, it's unlikely to replace that code, thus we need to figure out the checksum to be able to patch the code to bypass the checksum :-)

[Guest Speckles]

ZeBadger: Can you send me a file you have created that passes your crc checker but doesn't flash?

[Guest ZeBadger]

ZeBadger: Can you send me a file you have created that passes your crc checker but doesn't flash?

Sure, it's here or bz2'd here.

Edited June 27, 2010 by ZeBadger

[Guest Speckles]

Ok.... I've just created my first UPDATA.APP, and it failed. Guess what on...

**** SD download log ****

Failure: MD5_RSA verify failure.

Failure: operation did not succeed.

Failure: operation did not succeed.

Failure: operation did not succeed.

Failure: operation did not succeed.

Failure: operation did not succeed.

dload_sd_ram_data_proc->(retry >= DLOAD_RETRY) failed!

WTF? I thought these files didn't have MD5 checksums?

[Guest ZeBadger]

Ok.... I've just created my first UPDATA.APP, and it failed. Guess what on...

**** SD download log ****

Failure: MD5_RSA verify failure.

Failure: operation did not succeed.

Failure: operation did not succeed.

Failure: operation did not succeed.

Failure: operation did not succeed.

Failure: operation did not succeed.

dload_sd_ram_data_proc->(retry >= DLOAD_RETRY) failed!

WTF? I thought these files didn't have MD5 checksums?

Which file did you update in there? Coz I got a CRC error and you got a MD5 error.

Edited June 28, 2010 by ZeBadger

[Guest Speckles]

I didn't update, I created my own from scratch :lol:

The only difference is that I didn't include any of those 40 byte files.

I'm wondering if those 40-byte files are the MD5_RSA hashes.

[Guest ZeBadger]

I'm wondering if those 40-byte files are the MD5_RSA hashes.

I looked in those files and they don't look very md5-y. Some of them have the same bytes repeated inside them, looking similar to the CRC checksum, but seeing the number of nulls in there makes me think not. Quite a few of the files (in the December ROM) are exactly the same.

[Guest Speckles]

then I wonder what the error message means?

I tried just using the first file (128 bytes) and it flashes successfully, then creates oemsbl_updated file. oemsbl is radio settings? I've not tried to change the contents of the file. I'm assuming that could be bad.

Try to reflash splash screen - get same error as above (md5_rsa failure).

[Guest ZeBadger]

then I wonder what the error message means?

I've been taking a look at the "time machine" rom... as there's hardly any files in there and it's a valid rom.

I can't see any of the md5sums of the extracted files within the UPDATA.APP for any of the extracted files

There's also no magic numbers for gzip or CPIO like there are in the December/Hungarian roms.

Try to reflash splash screen - get same error as above (md5_rsa failure).

Did you try just the splash screen in the UPDATA.APP? You're a braver man than me if you did!

Edited June 29, 2010 by ZeBadger

[Guest Speckles]

Yes, I tried just the splash screen on it's own, and the splash screen with the 128 byte free at the begining that always seems to be there.

Tonight, I copied the T-Mobile 2.1 update almost identically (I didn't change any of the data, but I did remove all files whose size was > 300K). I got a CRC error (Failure: CRC verify failure.) :) But I didn't change any of the files!

So the files I had excluded were:

Seq: 20, 30, 40, 60, C0, D0, E0.

Giving the following output on my integrity checker:

HSize:100 FSeq:F3000000 FLength:128 Date:2010.04.19 Time:14.50.50 Unknown:92a7

HSize:104 FSeq:F4000000 FLength:8560 Date:2010.04.19 Time:14.50.50 Unknown:dc36

HSize:102 FSeq:F6000000 FLength:5495 Date:2010.04.19 Time:14.50.50 Unknown:646a

HSize:100 FSeq:F0000000 FLength:40 Date:2010.04.19 Time:14.50.50 Unknown:1b92

HSize:102 FSeq:F7000000 FLength:4685 Date:2010.04.19 Time:14.50.51 Unknown:140a

HSize:100 FSeq:F1000000 FLength:40 Date:2010.04.19 Time:14.50.51 Unknown:6023

HSize:134 FSeq:F8000000 FLength:71616 Date:2010.04.19 Time:14.50.53 Unknown:9901

HSize:100 FSeq:F9000000 FLength:20 Date:2010.04.19 Time:14.50.53 Unknown:bce2

HSize:100 FSeq:FB000000 FLength:40 Date:2010.04.19 Time:14.50.53 Unknown:6702

HSize:120 FSeq:10000000 FLength:41200 Date:2010.04.19 Time:14.50.53 Unknown:510f

HSize:100 FSeq:F5000000 FLength:40 Date:2010.04.19 Time:14.50.53 Unknown:9174

HSize:100 FSeq:FD000000 FLength:40 Date:2010.04.19 Time:14.50.53 Unknown:6137

HSize:100 FSeq:FE000000 FLength:40 Date:2010.04.19 Time:14.51.08 Unknown:3cca

HSize:126 FSeq:50000000 FLength:54912 Date:2010.04.19 Time:14.51.09 Unknown:62ac

HSize:100 FSeq:FA000000 FLength:40 Date:2010.04.19 Time:14.51.09 Unknown:c65c

HSize:100 FSeq:FF000000 FLength:40 Date:2010.04.19 Time:14.51.09 Unknown:477b

HSize:100 FSeq:FC000000 FLength:40 Date:2010.04.19 Time:14.51.09 Unknown:c069

HSize:248 FSeq:F2000000 FLength:307200 Date:2010.04.19 Time:14.50.50 Unknown:b7d2

End of file - All checks passed! All checksums good!

:lol: :D :D

[Guest ZeBadger]

Yes, I tried just the splash screen on it's own, and the splash screen with the 128 byte free at the begining that always seems to be there.

Tonight, I copied the T-Mobile 2.1 update almost identically (I didn't change any of the data, but I did remove all files whose size was > 300K). I got a CRC error (Failure: CRC verify failure.) :) But I didn't change any of the files!

So the files I had excluded were:

Seq: 20, 30, 40, 60, C0, D0, E0.

Giving the following output on my integrity checker:

HSize:100 FSeq:F3000000 FLength:128 Date:2010.04.19 Time:14.50.50 Unknown:92a7

HSize:104 FSeq:F4000000 FLength:8560 Date:2010.04.19 Time:14.50.50 Unknown:dc36

HSize:102 FSeq:F6000000 FLength:5495 Date:2010.04.19 Time:14.50.50 Unknown:646a

HSize:100 FSeq:F0000000 FLength:40 Date:2010.04.19 Time:14.50.50 Unknown:1b92

HSize:102 FSeq:F7000000 FLength:4685 Date:2010.04.19 Time:14.50.51 Unknown:140a

HSize:100 FSeq:F1000000 FLength:40 Date:2010.04.19 Time:14.50.51 Unknown:6023

HSize:134 FSeq:F8000000 FLength:71616 Date:2010.04.19 Time:14.50.53 Unknown:9901

HSize:100 FSeq:F9000000 FLength:20 Date:2010.04.19 Time:14.50.53 Unknown:bce2

HSize:100 FSeq:FB000000 FLength:40 Date:2010.04.19 Time:14.50.53 Unknown:6702

HSize:120 FSeq:10000000 FLength:41200 Date:2010.04.19 Time:14.50.53 Unknown:510f

HSize:100 FSeq:F5000000 FLength:40 Date:2010.04.19 Time:14.50.53 Unknown:9174

HSize:100 FSeq:FD000000 FLength:40 Date:2010.04.19 Time:14.50.53 Unknown:6137

HSize:100 FSeq:FE000000 FLength:40 Date:2010.04.19 Time:14.51.08 Unknown:3cca

HSize:126 FSeq:50000000 FLength:54912 Date:2010.04.19 Time:14.51.09 Unknown:62ac

HSize:100 FSeq:FA000000 FLength:40 Date:2010.04.19 Time:14.51.09 Unknown:c65c

HSize:100 FSeq:FF000000 FLength:40 Date:2010.04.19 Time:14.51.09 Unknown:477b

HSize:100 FSeq:FC000000 FLength:40 Date:2010.04.19 Time:14.51.09 Unknown:c069

HSize:248 FSeq:F2000000 FLength:307200 Date:2010.04.19 Time:14.50.50 Unknown:b7d2

End of file - All checks passed! All checksums good!

:lol: :D :D

There must be a check once all the files are extracted. I'm trying to hunt where that data is stored.

I'm just in the process of comparing the file05.mbn from the Hungarian 2.1 rom with the "Time Machine" rom.

I'm thinking that the time machine rom is probably the simplest to play with... with it only having a few files!

[Guest Speckles]

I'd go along with that suggestion, but the updater never shows the "Step 1: Unpacking" stage, and just goes immediately from "Preparing" to "Update failed!", but if I just include the 128 byte file and nothing else, I get the full sequence "Preparing", "Unpacking", "Installing", "Complete!", even when I set "Something2" to 0x0000 rather than the proper value.

I'm thinking whether some files depend on others.