4 ms·

FTA: > When we try and decrypt the on and off packets we get: > 05 54 55 52 4E 01 00 00 00 00 00 00 00 00 00 00 > 05 54 55 52 4E 00 00 00 00 00 00 00 00 00 0

FTA: > When we try and decrypt the on and off packets we get: > 05 54 55 52 4E 01 00 00 00 00 00 00 00 00 00 00 > 05 54 55 52 4E 00 00 00 00 00 00 00 00 00 00 00 > 05 54 55 52 4E 01 00 00 00 00 00 00 00 00 00 00 > 05 54 55 52 4E 00 00 00 00 00 00 00 00 00 00 00 > 05 54 55 52 4E 01 00 00 00 00 00 00 00 00 00 00 > 05 54 55 52 4E 00 00 00 00 00 00 00 00 00 00 00 > Success! This is a lot more sensible. A fixed header, byte 5 switching between a 1 and a 0 for on and off, and a bunch of zeros. I would guess that’s not a ‘fixed header’, but a length byte (“command is 5 bytes long”), a command (“TURN”) and an argument (zero or one), padded with zeroes to 16 bytes.

willcooke 3y ago
Oooh! Good spot. I will check other commands and see if that length idea works out. I think it could.
- jonhohle 3y ago
  That’s pretty typical of binary formats. That and offsets or addresses. And type tags. Assuming the payload isn’t compressed or encrypted, you can get pretty far assuming you’ll run into one of those eventually. Anecdotally, earlier today I was trying to decipher Encarta data and came across the “Mind Maze” data and it’s mostly that - fixed 32-but header, question size, (answer size, answer, correct flag, something I haven’t figure out yet){4}. Then a separate file with an index value and an offset into the first file as well as a header I haven’t figured out yet.
EvanAnderson 3y ago
That "54 55 52 4E" jumped right out to my eye as the uppercase alphabet. Knowing that numbers start at 0x30, uppercase letters start at 0x41, and lowercase letters start at 0x61 makes alphanumeric patterns in hex dumps easy to spot. That knowledge is good for short strings, but the canonical hexdump format is a the best way to look at packet and memory dumps.
- deleted 3y ago
  [deleted]
- fl7305 3y ago
  > uppercase letters start at 0x41, and lowercase letters start at 0x61 And the reason for the 0x20 difference is that the Shift key on old teletypes turned the 0x20 bit on and off. In the same way the Control key turned the 0x40 bit off. So Ctrl-A = 0x01 = 'A'/0x41 - 0x40.
ww520 3y ago
That's a great catch. 0x54 55 52 4E indeed are T U R N.
- kordlessagain 3y ago
  Turn off the wifi.
bilekas 3y ago
The header is fixed in this case.. By length and start point.
avereveard 3y ago
And it's probably not padding, just a uint
- aaronmdjones 3y ago
  It is padding. It was encrypted with AES, which has a block size of 128 bits. Its input needs to be padded to that amount, unless you use it in some stream modes of operation (e.g. CTR).
  - avereveard 3y ago
    Eugh I hope not the padding should be at block level not at content level if this was the standard zero padding from a crypto lib you'd have 0x80 before the padding bytes (and you'd get the unpadded message when decoding it correctly)
    - aaronmdjones 3y ago
      Well, they're encrypting with a statically-built-in key shared across all of their devices (and even with others). I hardly think they care about properly implementing padding!

willcooke 3y ago

Oooh! Good spot. I will check other commands and see if that length idea works out. I think it could.

jonhohle 3y ago
That’s pretty typical of binary formats. That and offsets or addresses. And type tags. Assuming the payload isn’t compressed or encrypted, you can get pretty far assuming you’ll run into one of those eventually. Anecdotally, earlier today I was trying to decipher Encarta data and came across the “Mind Maze” data and it’s mostly that - fixed 32-but header, question size, (answer size, answer, correct flag, something I haven’t figure out yet){4}. Then a separate file with an index value and an offset into the first file as well as a header I haven’t figured out yet.

EvanAnderson 3y ago

That "54 55 52 4E" jumped right out to my eye as the uppercase alphabet. Knowing that numbers start at 0x30, uppercase letters start at 0x41, and lowercase letters start at 0x61 makes alphanumeric patterns in hex dumps easy to spot. That knowledge is good for short strings, but the canonical hexdump format is a the best way to look at packet and memory dumps.

deleted 3y ago
[deleted]
fl7305 3y ago
> uppercase letters start at 0x41, and lowercase letters start at 0x61 And the reason for the 0x20 difference is that the Shift key on old teletypes turned the 0x20 bit on and off. In the same way the Control key turned the 0x40 bit off. So Ctrl-A = 0x01 = 'A'/0x41 - 0x40.

ww520 3y ago

That's a great catch. 0x54 55 52 4E indeed are T U R N.

kordlessagain 3y ago
Turn off the wifi.

bilekas 3y ago

The header is fixed in this case.. By length and start point.

avereveard 3y ago

And it's probably not padding, just a uint

aaronmdjones 3y ago
It is padding. It was encrypted with AES, which has a block size of 128 bits. Its input needs to be padded to that amount, unless you use it in some stream modes of operation (e.g. CTR).
- avereveard 3y ago
  Eugh I hope not the padding should be at block level not at content level if this was the standard zero padding from a crypto lib you'd have 0x80 before the padding bytes (and you'd get the unpadded message when decoding it correctly)
  - aaronmdjones 3y ago
    Well, they're encrypting with a statically-built-in key shared across all of their devices (and even with others). I hardly think they care about properly implementing padding!