Guest McSpoon Posted June 26, 2010 Report Share Posted June 26, 2010 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. Link to comment Share on other sites More sharing options...
Guest BigBearMDC Posted June 26, 2010 Report Share Posted June 26, 2010 (edited) 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 Link to comment Share on other sites More sharing options...
Guest Speckles Posted June 26, 2010 Report Share Posted June 26, 2010 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: Link to comment Share on other sites More sharing options...
Guest Speckles Posted June 26, 2010 Report Share Posted June 26, 2010 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. Link to comment Share on other sites More sharing options...
Guest BigBearMDC Posted June 26, 2010 Report Share Posted June 26, 2010 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: Link to comment Share on other sites More sharing options...
Guest ZeBadger Posted June 26, 2010 Report Share Posted June 26, 2010 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. Link to comment Share on other sites More sharing options...
Guest ZeBadger Posted June 26, 2010 Report Share Posted June 26, 2010 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. Link to comment Share on other sites More sharing options...
Guest Speckles Posted June 26, 2010 Report Share Posted June 26, 2010 (edited) 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 Link to comment Share on other sites More sharing options...
Guest Speckles Posted June 26, 2010 Report Share Posted June 26, 2010 (edited) 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 Link to comment Share on other sites More sharing options...
Guest ZeBadger Posted June 27, 2010 Report Share Posted June 27, 2010 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. Link to comment Share on other sites More sharing options...
Guest ZeBadger Posted June 27, 2010 Report Share Posted June 27, 2010 (edited) 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 Link to comment Share on other sites More sharing options...
Guest Speckles Posted June 27, 2010 Report Share Posted June 27, 2010 (edited) 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 Link to comment Share on other sites More sharing options...
Guest BigBearMDC Posted June 27, 2010 Report Share Posted June 27, 2010 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. Link to comment Share on other sites More sharing options...
Guest Speckles Posted June 27, 2010 Report Share Posted June 27, 2010 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 :-) Link to comment Share on other sites More sharing options...
Guest Speckles Posted June 27, 2010 Report Share Posted June 27, 2010 ZeBadger: Can you send me a file you have created that passes your crc checker but doesn't flash? Link to comment Share on other sites More sharing options...
Guest ZeBadger Posted June 27, 2010 Report Share Posted June 27, 2010 (edited) 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 Link to comment Share on other sites More sharing options...
Guest Speckles Posted June 28, 2010 Report Share Posted June 28, 2010 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? Link to comment Share on other sites More sharing options...
Guest ZeBadger Posted June 28, 2010 Report Share Posted June 28, 2010 (edited) 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 Link to comment Share on other sites More sharing options...
Guest Speckles Posted June 28, 2010 Report Share Posted June 28, 2010 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. Link to comment Share on other sites More sharing options...
Guest ZeBadger Posted June 29, 2010 Report Share Posted June 29, 2010 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. Link to comment Share on other sites More sharing options...
Guest Speckles Posted June 29, 2010 Report Share Posted June 29, 2010 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). Link to comment Share on other sites More sharing options...
Guest ZeBadger Posted June 29, 2010 Report Share Posted June 29, 2010 (edited) 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 Link to comment Share on other sites More sharing options...
Guest Speckles Posted June 29, 2010 Report Share Posted June 29, 2010 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 Link to comment Share on other sites More sharing options...
Guest ZeBadger Posted June 29, 2010 Report Share Posted June 29, 2010 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! Link to comment Share on other sites More sharing options...
Guest Speckles Posted June 29, 2010 Report Share Posted June 29, 2010 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. Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now