Hacking erroneous output of SBF Codec

[Jharmon12]

will SBF-ReCalc fix the checksum errors?

Ive tried to play with sbf reCalc but it will only let me see the checksum and when i click reclaculate it dont do anything. But after what happened with sbf codec I feel better manually changing the checksum so that i can be sure its right.

 

[jlutz555]

w00t!!! Got it to work!
Here is the sbf i used for my wife's phone.

 

[Jharmon12]

w00t!!! Got it to work!
Here is the sbf i used for my wife's phone.

I must be doing something wrong. I could get it to split the files but not much else.

 

[jlutz555]

Sorry, should have elaborated... I tried SBF-ReCalc with the same result shortly after my previous post.

What i "got" was how to properly fix the checksum manually. I wonder if we should write a tut up or leave this thread as-is to let people gain a better understanding.

I might be willing to start pumping out boot logo sbf's now...

 

[Jharmon12]

Sorry, should have elaborated... I tried SBF-ReCalc with the same result shortly after my previous post.

What i "got" was how to properly fix the checksum manually. I wonder if we should write a tut up or leave this thread as-is to let people gain a better understanding.

I might be willing to start pumping out boot logo sbf's now...

Oh ok, im just hung up on this stupid checksum problem. Im sure its just that i dont understand hex fully.

 

[MotoCache1]

Ok I have tried one on my own and i edited the check sum but had a small problem.

14:49:37,  September 09, 2010
Line: 587
ERROR: Flash failure: Interface AP-OS: Error verifying Code Group 42 checksums. [B][SIZE=4][COLOR=Red]File: 0x620F, Phone: 0x62F[/COLOR][/SIZE][/B] (Error Code: 31),
Detailed Error Details: Direction of the Error=No Direction, Command Value=4000000, Code Group Number=42
File: X:\test_dev_usb\flash\code\flashdll\FlashHdlr.cpp
Device ID: 0

As you can see the checksum the phone is expecting is only 3 chars long, Ive tried putting a 0F and a F0 and no go. Im sure its just a hex noob problem on my behalf but alas its a problem.

Edit: Thinking it may have been an error i made a cg42 file both ways, with your script and the tried and true way with the same checksum expectation.

Yeah, if you see 0x62F and you know you're dealing with a 16 bit checksum (which would be 4 hex characters) then you just pad a leading zero in. So 0x62F is 0x062F. Leading zeroes don't change the value any more than 0150 vs. 150 in decimal. Once you pad it, then it is more obvious that the first byte is 06 and the second byte is 2F -- but since we learned that they are stored little-endian in the file, of course you'd put 2F 06.

 

[Jharmon12]

Ok I have tried one on my own and i edited the check sum but had a small problem.

14:49:37,  September 09, 2010
Line: 587
ERROR: Flash failure: Interface AP-OS: Error verifying Code Group 42 checksums. [B][SIZE=4][COLOR=Red]File: 0x620F, Phone: 0x62F[/COLOR][/SIZE][/B] (Error Code: 31),
Detailed Error Details: Direction of the Error=No Direction, Command Value=4000000, Code Group Number=42
File: X:\test_dev_usb\flash\code\flashdll\FlashHdlr.cpp
Device ID: 0

As you can see the checksum the phone is expecting is only 3 chars long, Ive tried putting a 0F and a F0 and no go. Im sure its just a hex noob problem on my behalf but alas its a problem.

Edit: Thinking it may have been an error i made a cg42 file both ways, with your script and the tried and true way with the same checksum expectation.

Yeah, if you see 0x62F and you know you're dealing with a 16 bit checksum (which would be 4 hex characters) then you just pad a leading zero in. So 0x62F is 0x062F. Leading zeroes don't change the value an more than 0150 vs. 150 in decimal. Once you pad it, then it is more obvious that the first byte is 06 and the second byte is 2F -- but since we learned that they are stored little-endian in the file, of course you'd put 2F 06.

Ok i c i put the zero in the wrong place, but atleast i knew a zero went there but yeah after i went in and changed it it flashed perfect. I would like to say thanks for helping us work through this.

 

[Jharmon12]

Wow when i first started working on this problem i thought that it was going to be one of those things that were above my pay grade until i realized that i have no pay grade :i-m_so_happy::yahoo::i-m_so_happy:

 

[Jharmon12]

w00t!!! Got it to work!
Here is the sbf i used for my wife's phone.

How did this come out? I revers engineered your cg 42 and made it a bmp again and your pic looks like its upside down.

 

[jlutz555]

hmm that's odd, looks perfect on her phone. I have no idea...

 

[MotoCache1]

w00t!!! Got it to work!
Here is the sbf i used for my wife's phone.

How did this come out? I revers engineered your cg 42 and made it a bmp again and your pic looks like its upside down.

You will find that to be true of all pics you pull out of a CG42. You know that step where you use Frhed to reverse the bytes? That flips the picture updside down. That's because the BMP file format actually stores the image upside down to begin with. In a BMP, the first line of pixels is at the end of the file, and vice versa. Apparently the phone wants the first line to be first, so that's why you do the reverse. But if you make it a BMP again without reversing it again, it will be upside down. If you really look, you'll probably see it is also mirrored left to right -- for the same reason.

This is a good example of an opportunity to use some hacker curiosity. When you go into Frhed and just follow instructions and reverse the bytes, you should wonder -- why am I doing this? What happens if I don't do this? Oh - the picture is upside down if I don't do this. Interesting. If you're a psycho nut like me you go a step further and make a BMP with a different color in each corner and the rest is white and then go in and edit it and see where the corners lie in the file and how that arrangement changes after you mirror the file or reverse the bytes. Without that kind of inquisition I couldn't write the utility that turns an BMP into a CG42. By the way I will be posting my updated version of that utility (that does everything for you) when I finish testing all the optional switches. It's a Perl script so you can read it and see what it does and learn from it.

 

[MotoCache1]

Naming any SBF's you create

I removed the "MC1_A855_1283756080_BL-Logo-Only-storm.zip" attachment from jlutz555's post and wanted to explain why briefly. You'll notice that any SBF's I release have a fairly structured file name that's pretty long. I keep a registry of the files that I have released and all those parts of the name mean things. Among other things, the "MC1" at the beginning implies that I made it, the A855 says it is for a Motorola Droid 1, the 1283756080 is an encoding of part of the internals of the SBF, and the rest is descriptive of the contents.

While I have only limited ability to enforce this, if you start with one of my SBF's and modify it, please do not name the result MC1something. Also, leaving the 1283756080 part in there is going to be somewhat confusing because it's not going to match the internals of your file. Bad information is worse than no information. I take such structured approach because my SBF's tend to have a fairly wide distribution (almost 4000 people have downloaded the "recovery only" SPRecovery SBF) so I need a way to keep track of what's what.

Thanks for accommodating my preferences about this.

P.S. Obviously I'm not implying that jlutz555 did something to intentionally mislead anybody, or did anything wrong, etc. I've never explained my file naming standard before, so he did a sensible thing -- he changed the end of the filename to reflect the changes he had made and left the rest alone. Now that I've explained what the rest means, hopefully my position makes sense.

 

[MotoCache1]

will SBF-ReCalc fix the checksum errors?

Ive tried to play with sbf reCalc but it will only let me see the checksum and when i click reclaculate it dont do anything. But after what happened with sbf codec I feel better manually changing the checksum so that i can be sure its right.

That is the latest SBF Recalc, but it does not fully know how to handle the CGs for our phone. I suspect it doesn't know how to calculate the checksums and is at least smart enough not to just go ahead and build the file anyway.

 

[MotoCache1]

Wow when i first started working on this problem i thought that it was going to be one of those things that were above my pay grade until i realized that i have no pay grade :i-m_so_happy::yahoo::i-m_so_happy:

You've gained some decent fundamentals here. There's a whole world of this stuff out there waiting for people to take it apart and figure it out.

 

[fish1552]

Ok, this is starting to get frustrating. I made the new sbf file and got this in the RSDLite error log.

22:19:58,  September 09, 2010
Line: 1309
ERROR: Interface AP-OS: Error verifying Code Group 42 checksums. 
File: 0xB340, Phone: 0xF627
File: X:{edited}
Device ID: 0
{cut}
22:19:58,  September 09, 2010
Line: 587
ERROR: Flash failure: Interface AP-OS: Error verifying Code Group 42 checksums. 
File: 0xB340, Phone: 0xF627 (Error Code: 31),
Detailed Error Details: Direction of the Error=No Direction, Command Value=4000000, Code Group Number=42
File: {edited}
Device ID: 0

I get 2 checksum error messages. Are we only worrying about the Flash failure one and not the other or did I f*** something else up?

Edit: Yes, the bytes are the same, but do we need to look at both lines?

Oh, and it gives me a CODE CORRUPT message on the phone.