The answer is yes, no, and maybe -- all at once. If you went no further than where we are at now, you would have to do exactly what you just said. Let SBF Codec build your SBF with the bad checksums (it's just keeping the checksum for the prior contents by the way -- I checked), then flash it onto your phone - then get the error log from RSD Lite to find out what the checksum should be, and fix your file. Honestly, this is what lots of people do. It is reliable (obviously RSD Lite knows how to calculate the checksum), and trashing CG42 shouldn't pose any risk of bricking your phone though it is a bit disconcerting to see that code corrupt error. Another option would be to see if you can figure out how to calculate the checksum yourself. This might be a pretty tall order.
But this raises the question, with every sbf that is made do we have to flash it first and then see what the phone expects it to be and then hex edit the proper checksum in like we did with this one, and if thats it what were the other bytes that didnt match up with the good file?
Anyway, good work guys. I hope you feel a little (or big) sense of accomplishment. And with that, now I
OK, so out of 10 mismatched bytes, 4 were the datestamp which didn't matter, and 2 were the CG42 checksum (which did matter). That leaves 4 more that were different, but don't seem to be a barrier to flashing. What do they do? Good question. I can tell you that one or more of them causes a difference you will see on the screen in RSD Lite. That's a pretty big hint. Put your hacking caps back on and let me know what you find.