Tazzi wrote:What Yoda posted doesnt quite add up.. since I know the byte after the cvn does not be used in the checksum.. changing it does not seem to affect the checksums what so ever. They look like a starting point though!
I cant reproduce that. If I change the byte after the CVN (in this case, was 8B B8) from 00 to 01, then it looks like it actually disables the checksum for the segment and changes the checksum and thus cvn!!
In the pic here, both red boxes would read 8B B8 if this byte was not part of the sum.
antus wrote:
Its guesswork at this stage, but it seems likely. We still need a direction (forward or backwards)... probably forwards now we've layed it out more clearly... and an algo. Im hoping CRC16 or CRC16-CCITT. Once we can match the CS, we can use tazzi's algo above to calculate a CVN for it.
yeah Im trying to steer clear of focusing on one algo.. since I dont want to spend days on something thats completely off! Thats why Im running through all the possibilities at once.
Im betting on CRC16-CCITT as this is significantly affected by 00's and as found in testing, moving the bytes from 00 locations affect the overall result which occurs in the CRC16-CCITT algos (all of them I think).
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
antus wrote:I cant reproduce that. If I change the byte after the CVN (in this case, was 8B B8) from 00 to 01, then it looks like it actually disables the checksum for the segment and changes the checksum and thus cvn!!
In the pic here, both red boxes would read 8B B8 if this byte was not part of the sum.
Disabled?.. I wonder if that applies to the actual bin? Or if the"disable" is actually an error, detected bad byte to process?
Doesnt work on these bins here, modifying the byte after makes nothing change
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
antus wrote:It looks like applies to the segment, and is different to a checksum failure.
Alright, well Iv actually gone with the assumptions we have made so far anways.. since technically thinking about it.. we cant add in the cvn into our calcs.. since it needs th checksum for it as seen from my calc. So im currently just processing the sections outlined earlier
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Forward iteration failed. Backwards is still on its way!
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
antus wrote:Yep my process completed too. Checksum ID fail.
Im still running it backwards.
To add to the complexity.. I looked at a few different bins from a few other E38's.. looks like they move the calibrations around and checksum locations
Id hope each dont have their own separate checksum calcs either!
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Yeah, you have to load the addresses from the index. That part of my code above works - it can locate the sums correctly in differing bins. I doubt the sums would be different to each other.
antus wrote:Yeah, you have to load the addresses from the index. That part of my code above works - it can locate the sums correctly in differing bins. I doubt the sums would be different to each other.
Index? So the checksums are just "shifted" up/down in the bins?
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
