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

[Guest ZeBadger]

Did you check the log file in the dload folder with different values (Correct/incorrect) for Something2 ? Maybe it'll say whats wrong and we can decide on its purpose from the error message?

Nope, never seen any meaningful messages in there... but I'll check it out... just about to try using the Hungarian ROM's 2 bytes for Something2 copied directly into the December ROM. I'm hoping it'll fail, at least that'll prove it's a header thing. I've also downloaded loads of other roms from the huawei website, so I'm going to try copying one of the non t-mobile images in.

Edit: That ROM worked no problems. Weird weird weird.

Edit2: Now trying copying just the "Something2" from the swedish rom (which is an image of the Huawei symbol) over the Something2 in the December Update... which worked. The only thing I'm thinking now is that I've somehow messed up the splashscreen in my customised version, so I'm going to take the huawei screen and put it in the DecemberRom and see what happens.

Edited June 23, 2010 by ZeBadger

[Guest Josh04]

You should rename this thread, there's some really interesting stuff going on in it which isn't reflected in the title.

[Guest ZeBadger]

You should rename this thread, there's some really interesting stuff going on in it which isn't reflected in the title.

Yeah probably! I've not had much time to do anything this week.

[Guest BigBearMDC]

Yeah probably! I've not had much time to do anything this week.

I'd really like to take the windows part of the repacking app (once we know how).

I already wrote many apps that process files bit by bit :lol:

If I got some time left, I'll have a look at the UPDATA file also :D

You did a very great job!

Best regards,

BigBear

[Guest ZeBadger]

These are the things that I have tried so far and the results :

December ROM : Header left alone except for CRC recalculated for... New splash file inserted with ZeBadger logo - Failed during writing phase with "Failure: CRC verify failure" See Appendix 1 for full error message.

December ROM : Something2 copied from Hungarian ROM (0E 39 changed to D2 B7) - Worked

December ROM : Whole header copied for splash screen from Hungarian ROM - Worked

December ROM : Whole header copied for splash screen from Hungarian ROM, modified File Date part in header to 2009.11.08 (my birthday last year :lol:) - Worked

December ROM : Whole header copied for splash screen from Hungarian ROM, modified File Date part in header to 2009.11.08, modified Something2 (D2 B7 changed to D2 B6) - Failed during unpacking phase with "dload_sd_chk_file_data->dload_sd_chk_ram_data failed"

Puzzling things...

I ran my ZeBadger UPDATA.APP through the new splitter and it CRC checked okay... but of course I worked the CRC out with the same code I'm checking it with. I could do with someone sanity checking that it is this is actually working correctly.

So what does dload_sd_chk_file_data->dload_sd_chk_ram_data failed mean? I've tried loads of crc checking combinations of the bytes from the header... but I don't understand why the Something2 would be different for the exact same file if it's a CRC.

If you "strings file05.mbn|vim -" on linux then you can see the errors message from the unpacker/writer, and it might give a few clues as to what's going on.

Appendix 1

**** SD download log ****

notes:(dld_file_ptr != -1) !

Failure: CRC 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_file_data_proc-(dld_retry >= DLOAD_RETRY) failed!

Edited June 25, 2010 by ZeBadger

[Guest Speckles]

So UPDATA.APP can replace the updater and bootloader? Scary. I would have thought those would be hidden away and non-writable.

It does mean though that we can disassemble the updater and figure out how it works :lol:

UPDATE: Ok, I've now got file05.mbn, passed your crc check. I'll take a look at it later today.

Edited June 26, 2010 by Speckles

[Guest Speckles]

ZeBadger: I see multiple (different) CRC16 routines in the code! That could be why it's not working for you. I'm going to rip the tables out of the file and try to build a crc checker (crc table is different depending on what it is checking)

I also see some other strange values, which according to Google and Wikipedia, belong to MD5 and CRC-30.

This is turning out to be a fun little project :lol:

Now it's getting rather hot in here (~86F, ~30C) so I need to leave it a bit.

Edited June 26, 2010 by Speckles

[Guest ZeBadger]

ZeBadger: I see multiple (different) CRC16 routines in the code! That could be why it's not working for you. I'm going to rip the tables out of the file and try to build a crc checker (crc table is different depending on what it is checking)

I also see some other strange values, which according to Google and Wikipedia, belong to MD5 and CRC-30.

My c CRC function is here

Compile with "cc -o crc crc.c"

The Something2 is only 2 bytes so probably wont be md5 or crc-32

Edited June 26, 2010 by ZeBadger

[Guest Speckles]

Thanks for that, my crc algo so far is nothing like yours, but yours is obviously closer as it matches the checksums in the file :lol:

The MD5/CRC-30 is probably extra security for OTA updates.

Edited June 26, 2010 by Speckles

[Guest Speckles]

So what does dload_sd_chk_file_data->dload_sd_chk_ram_data failed mean? I've tried loads of crc checking combinations of the bytes from the header... but I don't understand why the Something2 would be different for the exact same file if it's a CRC.

I've tracked the above message down in the updater app. It's caused by this routine returning zero:

ROM:00019738 var_20		  = -0x20

ROM:00019738

ROM:00019738				 STMFD   SP!, {R3-R9,LR}

ROM:0001973C				 MOV	 R7, R0

ROM:00019740				 MOV	 R0, #0

ROM:00019744				 LDR	 R8, =(loc_FFFC+3)

ROM:00019748				 MOV	 R6, R2

ROM:0001974C				 MOV	 R4, R1

ROM:00019750				 STR	 R0, [SP,#0x20+var_20]

ROM:00019754				 B	   loc_1979C

ROM:00019758; ---------------------------------------------------------------------------

ROM:00019758

ROM:00019758 loc_19758							  ; CODE XREF: sub_19738+68j

ROM:00019758				 LDRB	R0, [R6]

ROM:0001975C				 CMP	 R4, #0x1000; 4096

ROM:00019760				 MOVLS   R5, R4

ROM:00019764				 STRB	R0, [SP,#0x20+var_20]

ROM:00019768				 LDRB	R0, [R6,#1]

ROM:0001976C				 MOVHI   R5, #0x1000; 4096

ROM:00019770				 AND	 R1, R8, R5,LSL#3

ROM:00019774				 STRB	R0, [SP,#0x20+var_20+1]

ROM:00019778				 MOV	 R0, R7

ROM:0001977C				 BL	  sub_184AC

ROM:00019780				 LDRH	R1, [SP,#0x20+var_20]

ROM:00019784				 SUB	 R4, R4, R5

ROM:00019788				 ADD	 R7, R7, R5

ROM:0001978C				 CMP	 R1, R0

ROM:00019790				 MOVNE   R0, #0; If compare fail, set return status to zero (failure)

ROM:00019794				 ADD	 R6, R6, #2

ROM:00019798				 BNE	 locret_197A8; and abort

ROM:0001979C

ROM:0001979C loc_1979C							  ; CODE XREF: sub_19738+1Cj

ROM:0001979C				 CMP	 R4, #0; else go and have another loop if we have more bytes to check

ROM:000197A0				 BNE	 loc_19758

ROM:000197A4				 MOV	 R0, #1; success return code! 

ROM:000197A8

ROM:000197A8 locret_197A8						   ; CODE XREF: sub_19738+60j

ROM:000197A8				 LDMFD   SP!, {R3-R9,PC}

ROM:000197A8; End of function sub_19738

Does that look familiar to you? I thought it might :lol: The "184AC" routine is like the following:

ROM:000184AC sub_184AC							  ; CODE XREF: sub_19738+44p

ROM:000184AC										; sub_2C2F4+98p ...

ROM:000184AC				 LDR	 R2, =(loc_FFFC+3)

ROM:000184B0				 LDR	 R12, =0x9495E4

ROM:000184B4

ROM:000184B4 loc_184B4							  ; CODE XREF: sub_184AC+34j

ROM:000184B4				 CMP	 R1, #8

ROM:000184B8				 BCC	 loc_184E4

ROM:000184BC				 LDRB	R3, [R0],#1

ROM:000184C0				 SUB	 R1, R1, #8

ROM:000184C4				 MOV	 R1, R1,LSL#16

ROM:000184C8				 EOR	 R3, R3, R2

ROM:000184CC				 AND	 R3, R3, #0xFF

ROM:000184D0				 ADD	 R3, R12, R3,LSL#1

ROM:000184D4				 LDRH	R3, [R3]

ROM:000184D8				 MOV	 R1, R1,LSR#16

ROM:000184DC				 EOR	 R2, R3, R2,LSR#8

ROM:000184E0				 B	   loc_184B4

ROM:000184E4; ---------------------------------------------------------------------------

ROM:000184E4

ROM:000184E4 loc_184E4							  ; CODE XREF: sub_184AC+Cj

ROM:000184E4				 CMP	 R1, #0

ROM:000184E8				 BEQ	 loc_18524

ROM:000184EC				 LDRB	R0, [R0]

ROM:000184F0				 MOV	 R0, R0,LSL#8

ROM:000184F4				 B	   loc_18510

ROM:000184F8; ---------------------------------------------------------------------------

ROM:000184F8

ROM:000184F8 loc_184F8							  ; CODE XREF: sub_184AC+74j

ROM:000184F8				 EOR	 R3, R2, R0

ROM:000184FC				 TST	 R3, #1

ROM:00018500				 MOV	 R2, R2,LSR#1

ROM:00018504				 EORNE   R2, R2, #0x8400

ROM:00018508				 EORNE   R2, R2, #8

ROM:0001850C				 MOV	 R0, R0,LSR#1

ROM:00018510

ROM:00018510 loc_18510							  ; CODE XREF: sub_184AC+48j

ROM:00018510				 MOVS	R3, R1

ROM:00018514				 SUB	 R1, R1, #1

ROM:00018518				 MOV	 R1, R1,LSL#16

ROM:0001851C				 MOV	 R1, R1,LSR#16

ROM:00018520				 BNE	 loc_184F8

ROM:00018524

ROM:00018524 loc_18524							  ; CODE XREF: sub_184AC+3Cj

ROM:00018524				 MVN	 R0, R2

ROM:00018528				 MOV	 R0, R0,LSL#16

ROM:0001852C				 MOV	 R0, R0,LSR#16

ROM:00018530				 BX	  LR

ROM:00018530; End of function sub_184AC

I don't know about you, but that smells of a crc check to me.

[Guest BigBearMDC]

I've tracked the above message down in the updater app. It's caused by this routine returning zero:

code

Does that look familiar to you? I thought it might :lol: The "184AC" routine is like the following:

some more code  :blink:

I don't know about you, but that smells of a crc check to me.

What the H... is this ARM ASM?

[Guest BigBearMDC]

Wow, if we (or better you guys :lol:) ever fully decode this file, we could do everything!

I already learned ASM for µCs in school. but I'll have a look at CRC checks and ARM ASM code, not only because I'm intersted in it, but to be maybe able to help you :D

[Guest ZeBadger]

I don't know about you, but that smells of a crc check to me.

Can you tell which part of the file it is looking at when it calculates it? And how are you dumping the code?

Edited June 26, 2010 by ZeBadger

[Guest BigBearMDC]

What if something2 isn't a checksum, but a signature or something similar?

Maybe they jsut generate a 2 byte long value using an algorithm, without actually checking the file itself.

That wouldn't make much sense I think, but if exchanging everything but something2 works, then it might be something2 itself causing the problems.

[Guest ZeBadger]

What if something2 isn't a checksum, but a signature or something similar?

Maybe they jsut generate a 2 byte long value using an algorithm, without actually checking the file itself.

That wouldn't make much sense I think, but if exchanging everything but something2 works, then it might be something2 itself causing the problems.

Yeah those same thoughts have been going through my mind... but as you say, it doesn't make much sense.

I also don't understand why my checksum for my screen doesn't work... coz all the other checksums match perfectly.

Whoops... just noticed that my c code is the wrong one... it's the one to calculate the 4096 null bytes. I'll need to reboot into linux to get the real code... Fixed. Just crc.c is needed now.

Edited June 26, 2010 by ZeBadger

[Guest BigBearMDC]

Yeah those same thoughts have been going through my mind... but as you say, it doesn't make much sense.

I also don't understand why my checksum for my screen doesn't work... coz all the other checksums match perfectly.

Whoops... just noticed that my c code is the wrong one... it's the one to calculate the 4096 null bytes. I'll need to reboot into linux to get the real code... will modify.

So the checksum of each file is saved in the header, followed by the file, until the beginning of the next header?

[Guest ZeBadger]

So the checksum of each file is saved in the header, followed by the file, until the beginning of the next header?

Yes... although the files always finish on a 4 byte boundary. So there is occasional x00 padding.

I've got the full headers dumped here :

http://task10.com/android/DecemberUpdate/dload/header.hd.txt

and

http://task10.com/android/Hungarian/dload/header.hd.txt

and

http://task10.com/android/Timemachine/dload/header.txt

[Guest BigBearMDC]

Yes... although the files always finish on a 4 byte boundary. So there is occasional x00 padding.

I've got the full headers dumped here :

http://task10.com/android/DecemberUpdate/dload/header.hd.txt

and

http://task10.com/android/Hungarian/dload/header.hd.txt

and

http://task10.com/android/Timemachine/dload/header.txt

Something 2 always ends with 0x00 0x10, but you already mentioned it is 2 bytes large, so this might be nothing new for you :lol:

[Guest ZeBadger]

Something 2 always ends with 0x00 0x10, but you already mentioned it is 2 bytes large, so this might be nothing new for you :D

Yes, I was ignoring 00 01 :lol:

[Guest BigBearMDC]

Yes, I was ignoring 00 01 :lol:

You said exchanging the something2 value between the UPDATAs worked.

What happens if you place it into another file's header?

Does it still work then?

[Guest ZeBadger]

Not tried that. Not got time to try that tonight, but I wouldn't do it on any files that aren't towards the end of the file else you might brick the phone.

[Guest Speckles]

Can you tell which part of the file it is looking at when it calculates it? And how are you dumping the code?

Not as of yet. It's difficult to try and figure out what the code does when you can't run it. If only these phones had jtag!

Yes, it's ARM ASM. I do reverse engineering at work so I have a copy of IDA Pro installed on my laptop. Once you can teach it whats code and whats data (you have to have a certain amount of knowledge of guessing what is code and data), it can disassemble the file for you into neat chunks like this.

You can download IDA Pro as an evaluation version, but its very limited - I don't think it'll disassemble raw files like the ones we have.

[Guest BigBearMDC]

Not tried that. Not got time to try that tonight, but I wouldn't do it on any files that aren't towards the end of the file else you might brick the phone.

You could try it on the system.img once you got time.

Shouldn't break anything else than Android in the worst case :lol:

[Guest Speckles]

If they wrote the updater properly, it'll check everything is sane before attempting to even erase. But of course you can't assume that.

[Guest BigBearMDC]

If they wrote the updater properly, it'll check everything is sane before attempting to even erase. But of course you can't assume that.

I guess it shouldn't flash or erase anything until the integrity of the file got verified.

Everything else would just be stupid...

Although I can't really imagine they check the whole system image before flashing it... =/

Edited June 26, 2010 by BigBearMDC