I tried analysing a microcontroller assembler level program before, i've done it because i already programmed the same target in assembler before, so i understand what you mean that it could be not friendly if you are not familiar with the language, i will give a try with strace if i found clear calls to chks calculating libraries maybe i continue, else i will have to emulate the communication.
Quote:
a final checksum that checks it all
no, it still a direct calc of number of bytes :
Quote:
the last is 0x00 0x01 0xFD 0x22 = 130338 which is the real number of bytes contained in the file
The Nuls are end of line markers in the habitual meaning or in strings handling but here its not, its just a 0x00 byte and the binary file is full of em, same in the start of a line. and the NU is a mangled NUL.
But for the "CAN r NUL EOT", this is the 4 bytes repetitive command part of the headers, i dont think if it have different type from other 8bits data as its transfered by the link, so if it is in different type then it should have special treatement of testing the first 8 bits and then concat second ones if for exemple its in 16bits format. those are not outputs, but communication frames.
But the whole line must have a meaning, maybe as you noticed about the languages equivalent in low level.
---------- Post updated at 06:31 PM ---------- Previous update was at 06:27 PM ----------
Oh didnt noticed this rule Corona, i will pay attention next time. thx