[sudo-discuss] robot hacking - help crack the code!

[Jake]

it seems to be a checksum.

12:50 <@amatus> all the commands are 0x02 <2 byte little endian length> <bytes> <2 byte checksum>
13:01 <@amatus> it's not a crc, it's a simple checksum
13:01 <@amatus> you seriously couldn't figure this out?
13:02 <@amatus> you sum every byte of the message including the length field (but not the 0x02) and negate it
13:03 <@amatus> and send it as a 2 byte little endian 2's compliment integer
13:04 <@amatus> i mean, it's a really stupid scheme
13:06 <@amatus> but it was easy to figure out when you notice that EOF and NAK have the same checksum
13:06 <@amatus> it's stupid because when you do a simple checksum you make it so you can just sum everything, include the checksum, and end up with 0, which is why they are always negated sums
13:07 <@amatus> but not this one, you do 1-byte summing then compare to a 2-byte checksum
13:09 <@amatus> it's also stupid to include the length field, if there's no other method of framing that's the only way to find the checksum in the message, so you're already depending on it to be correct for framing

On Tue, 23 Sep 2014, Patrik D'haeseleer wrote:

> On Tue, Sep 23, 2014 at 11:43 AM, Jake <jake at spaz.org> wrote:
>
>       disk: \x02\x13\x00LST0001123.JBI     \x00\xfc
>       disk: \x02\x13\x00LST0001124.JBI     \xff\xfb
>
>       yasnac: \x02\x0f\x00FRD123.JBI     \xdc\xfc
>       yasnac: \x02\x0f\x00FRD124.JBI     \xdb\xfc
> 
>  
>       perhaps it's a 16-bit checksum?
> 
> 
> Yeah, looks like some sort of 16-bit checksum, with the first hex code being the lowest byte. If you read them this way, you see they're exactly 1 bit
> different:
> 
> \x00\xfc -> #FC00
> \xff\xfb -> #FBFF
> 
> \xdc\xfc -> #FCDC
> \xdb\xfc -> #FCDB
> 
> I'd say try again with 113 or 133 in the filename, instead of 123 - need a bit more evidence.
> 
> Patrik
> 
> 
>