What's new
DroidForums.net | Android Forum & News

This is a sample guest message. Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!

Hacking erroneous output of SBF Codec

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: Oh, and it gives me a CODE CORRUPT message on the phone.
I'm confused. That is exactly what you would expect to happen (including the code corrupt) and what you pasted in the box there is the information you use to solve your problem.
 
I'm confused. That is exactly what you would expect to happen (including the code corrupt) and what you pasted in the box there is the information you use to solve your problem.

I may just need to put this darn thing away for a few days. I swear I think my brain is in overload after the past 24 hours. LOL

Code:
File: 0xB340, Phone: 0xF627

When I posted that, I could swear the numbers were different for each one, but looking at it for the edit, I saw they were the same. Maybe I need to go watch my Man Show inspired boot animation for a bit. ;)
 
Ok, Moto I want to thank you for all your help the past 2 days.
:yr1:
This thing was kicking my butt today, and I was gonna give it up for a while, but I have this little thing about something getting the best of me. :)

I finally got it and worked like a charm!
:yeahbaby01:

Thank you!
 
Ok, Moto I want to thank you for all your help the past 2 days.

This thing was kicking my butt today, and I was gonna give it up for a while, but I have this little thing about something getting the best of me.

I finally got it and worked like a charm!

Thank you!
Next thing you know you'll be staying up until 6:30 in the morning hacking on something you just can't give up on, then sleep for 1.5 hours, then work a full day, then be posting here at 1:10am. Wait, that's me. :)
 
I really like the script that don't mirror the image because when I work with an image I work with it in a png format and then I open it in paint, mirror it and save it to my scripts folder where your cg42 scrip eagerly awaits, I just redone all of my old sbfs to make them logo only and perfected the process :P

Sent from my Moto Droid using Tapatalk
 
I really like the script that don't mirror the image because when I work with an image I work with it in a png format and then I open it in paint, mirror it and save it to my scripts folder where your cg42 scrip eagerly awaits, I just redone all of my old sbfs to make them logo only and perfected the process :P


The new script will either do everything for you, or you can selectively turn off each step that it performs:

/noclip = don't strip the first 54 bytes it's already done
/nomirror = don't mirror the image it's already done (or I am OK with it being reversed)
/noflip = don't flip the image it's already done (or I am OK with it being upside down)
/nopad = don't pad the 64 bytes of 0xFF at the end it's already done

I need to add a little code so that if the file you provide, in combination with the setting you specified, doesn't result in a legal file it will warn you. I'll probably provide a "/force" switch or something like that to force the script to make the file even if it would be a bad file.
 
OK, there are several outstanding questions that I've not seen any posts on.

If I were you guys the following things would be burning a hole in my brain, begging for an answer. Maybe I have that backwards. If you guys were me, and at your present level of discovery, the following things would be burning a hole in your brains:

  1. Is there a way to generate the checksum other than having RSD Lite flash the CG into my phone and fail (and then grabbing it out of the error log)?
  2. There were 10 mismatched bytes originally. We've "explained" 6 of them. What do the other 4 do?
Anybody work on these at all?
 
OK, there are several outstanding questions that I've not seen any posts on.

If I were you guys the following things would be burning a hole in my brain, begging for an answer. Maybe I have that backwards. If you guys were me, and at your present level of discovery, the following things would be burning a hole in your brains:

  1. Is there a way to generate the checksum other than having RSD Lite flash the CG into my phone and fail (and then grabbing it out of the error log)?
  2. There were 10 mismatched bytes originally. We've "explained" 6 of them. What do the other 4 do?
Anybody work on these at all?

Another question I would like to know as well, why does it work when u flash the whole sbf file with all the CG's in it? does the phone only check the first CG then let everything else go?
 
OK, there are several outstanding questions that I've not seen any posts on.

If I were you guys the following things would be burning a hole in my brain, begging for an answer. Maybe I have that backwards. If you guys were me, and at your present level of discovery, the following things would be burning a hole in your brains:

  1. Is there a way to generate the checksum other than having RSD Lite flash the CG into my phone and fail (and then grabbing it out of the error log)?
  2. There were 10 mismatched bytes originally. We've "explained" 6 of them. What do the other 4 do?
Anybody work on these at all?

Another question I would like to know as well, why does it work when u flash the whole sbf file with all the CG's in it? does the phone only check the first CG then let everything else go?
Yeah - I want to know that too. Now that you know where the checksum bytes live you should be able to look at your modified full-flash SBF and see if SBF Codec correctly recalculates the checksum when CG42 isn't the only CG in the file. My theory is that perhaps SBF Codec just has an issue where it accidentally (or intentionally) doesn't recalculate the checksum of the first CG in the file. It's a good hacker project for someone who needs the experience to go find out.
 
OK, there are several outstanding questions that I've not seen any posts on.

If I were you guys the following things would be burning a hole in my brain, begging for an answer. Maybe I have that backwards. If you guys were me, and at your present level of discovery, the following things would be burning a hole in your brains:

  1. Is there a way to generate the checksum other than having RSD Lite flash the CG into my phone and fail (and then grabbing it out of the error log)?
  2. There were 10 mismatched bytes originally. We've "explained" 6 of them. What do the other 4 do?
Anybody work on these at all?

Another question I would like to know as well, why does it work when u flash the whole sbf file with all the CG's in it? does the phone only check the first CG then let everything else go?
Yeah - I want to know that too. Now that you know where the checksum bytes live you should be able to look at your modified full-flash SBF and see if SBF Codec correctly recalculates the checksum when CG42 isn't the only CG in the file. My theory is that perhaps SBF Codec just has an issue where it accidentally (or intentionally) doesn't recalculate the checksum of the first CG in the file. It's a good hacker project for someone who needs the experience to go find out.

I have made a coulpe from the base ones you made, and switched up the order in the way I make them and save them from the orginal instructions. So when i look at them i am now getting the same check sum you got with yours (which we know are good to flash). no matter what picture i put in there as long as I build from your base i get the same check sum just scared to flash since a few days ago got that corrupt message. need to know about the last 4 bytes?????
 
Next thing you know you'll be staying up until 6:30 in the morning hacking on something you just can't give up on, then sleep for 1.5 hours, then work a full day, then be posting here at 1:10am. Wait, that's me. :)

Well, I head to bed around 2:30am, then get up at 5:30 to work 48 hours. So I'm close.
But if I could figure out the s**t you could, I would consider it worth it. :)
 
ok just looked @ the entire SBF file ESD56 and the first CG is CG3 and for checksum in the real cs16 column it has N/A ???? this is the only CG in the whole file that has a N/A under the column
first of all what does CG3 do?? and could we include it in the flash as the first CG with CG42 and see if sbf codec handles the check sum differently.

MC1 we need your guidance
 
Ok i flashe both mine and your monster logo and looked at the error log and they were both the same. Yours
Code:
19:36:34,  September 10, 2010
Line: 517
ERROR: AP Die ID: 07f0010c41720304000000000400

19:36:34,  September 10, 2010
Line: 524
ERROR: BP Die ID: 0000000000000000000000000000

19:36:34,  September 10, 2010
Line: 531
ERROR: AP Public ID: ffffffffffffffffffffffffffffffffffffffff

19:36:34,  September 10, 2010
Line: 538
ERROR: BP Public ID: 0000000000000000000000000000000000000000
and mine
Code:
19:35:33,  September 10, 2010
Line: 517
ERROR: AP Die ID: 07f0010c41720304000000000400

19:35:33,  September 10, 2010
Line: 524
ERROR: BP Die ID: 0000000000000000000000000000

19:35:33,  September 10, 2010
Line: 531
ERROR: AP Public ID: ffffffffffffffffffffffffffffffffffffffff

19:35:33,  September 10, 2010
Line: 538
ERROR: BP Public ID: 0000000000000000000000000000000000000000

I watched both my phone and RSD Lite and they both acted the same :wacko:
 
Ok i flashe both mine and your monster logo and looked at the error log and they were both the same. Yours
Code:
19:36:34,  September 10, 2010
Line: 517
ERROR: AP Die ID: 07f0010c41720304000000000400
 
19:36:34,  September 10, 2010
Line: 524
ERROR: BP Die ID: 0000000000000000000000000000
 
19:36:34,  September 10, 2010
Line: 531
ERROR: AP Public ID: ffffffffffffffffffffffffffffffffffffffff
 
19:36:34,  September 10, 2010
Line: 538
ERROR: BP Public ID: 0000000000000000000000000000000000000000
and mine
Code:
19:35:33,  September 10, 2010
Line: 517
ERROR: AP Die ID: 07f0010c41720304000000000400
 
19:35:33,  September 10, 2010
Line: 524
ERROR: BP Die ID: 0000000000000000000000000000
 
19:35:33,  September 10, 2010
Line: 531
ERROR: AP Public ID: ffffffffffffffffffffffffffffffffffffffff
 
19:35:33,  September 10, 2010
Line: 538
ERROR: BP Public ID: 0000000000000000000000000000000000000000

I watched both my phone and RSD Lite and they both acted the same :wacko:

so they did flash successfully but still got these errors because of the last 4 bytes?:icon_ banana:
 
The four bytes are different in both files, but the error log is the same. So that tells me that the byte difference isnt causing the errors unless RSD Lite is looking for something completely different than what either files has.

EDIT: I wonder what the error log looks like if someone makes a full SBF from CG 42's in each of the files, LOL I dont wanna wipe out my phone to find out.
 
Back
Top