201 replies to this topic

[BigBearMDC]

ZeBadger, on Jun 26 2010, 21:46, said:

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?

[ZeBadger]

BigBearMDC, on Jun 26 2010, 20:59, said:

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/an...d/header.hd.txt
and
http://task10.com/an...d/header.hd.txt
and
http://task10.com/an...load/header.txt

[BigBearMDC]

ZeBadger, on Jun 26 2010, 22:03, said:

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/an...d/header.hd.txt
and
http://task10.com/an...d/header.hd.txt
and
http://task10.com/an...load/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

[ZeBadger]

BigBearMDC, on Jun 26 2010, 21:10, said:

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

Yes, I was ignoring 00 01  

[BigBearMDC]

ZeBadger, on Jun 26 2010, 22:12, said:

Yes, I was ignoring 00 01  

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?

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

[Speckles]

ZeBadger, on Jun 26 2010, 20:19, said:

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.

[BigBearMDC]

ZeBadger, on Jun 26 2010, 22:17, said:

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

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

[BigBearMDC]

Speckles, on Jun 26 2010, 22:21, said:

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 by BigBearMDC, 26 June 2010 - 08:33 PM.

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

[BigBearMDC]

McSpoon, on Jun 26 2010, 22:53, said:

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 by BigBearMDC, 26 June 2010 - 08:59 PM.

[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  

[Speckles]

BigBearMDC, on Jun 26 2010, 21:56, said:

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.

[BigBearMDC]

Speckles, on Jun 26 2010, 23:11, said:

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  

[ZeBadger]

McSpoon, on Jun 26 2010, 21:53, said:

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.

[ZeBadger]

Speckles, on Jun 26 2010, 22:11, said:

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.

[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

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

Edited by Speckles, 26 June 2010 - 10:19 PM.

[Speckles]

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

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 by Speckles, 26 June 2010 - 11:05 PM.

[ZeBadger]

ZeBadger, on Jun 26 2010, 22:52, said:

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.