Reverse Engineering combined CRC/Command Byte - hash

Question

I have an unknown hash/CRC byte which is 4 bits random/crc/unknown and 4 bits control flags. Each time the command byte is seen it can have a total of 16 distinct byte forms. And there are going to be 16 different groups. There is no colliding and each byte is only ever seen once. I'm reverse engineering a Moshiboard/MS10105 laser control board. So some of the code flags are able to be guessed. As I can logically assume the differences between turning on the laser and off the laser should be a bit-flip.
It seems like a solid puzzle but I can't really figure it out. There's a lot of information to go by, but also a lot of unknowns. Some of the control groups never show up and consequently I don't have them.
1. 0A 0E 1A 1E 4A 4E 51 53 59 5A 5B 5E 71 74 79 7B
2. 00 01 03 04 09 0C 10 14 21 23 29 2B 40 44 50 54
3. 55 57 5D 5F 75 77 7D 7F 8A 8E 9A 9E CA CE DA DE
4. 05 07 0D 0F 25 27 2D 2F 80 84 90 94 C0 C4 D0 D4
5. AA AE BA BE D5 D7 DD DF EA EE F5 F7 FA FD FE FF
6. 15 17 1D 1F 35 37 3D 3F 88 8C 98 9C C8 CC D8 DC
7. 45 47 4D 4F 65 67 6D 6F 82 86 92 96 C2 C6 D2 D6
8. A2 A6 B2 B6 C5 C7 CD CF E2 E5 E6 E7 ED EF F2 F6
Note: These are sorted numerically, since their actual order is unknown.
There is a partial versions of another command code range
08 0C 13 19 1B 1C 31 3B 48 58 5C ?? ?? ?? ?? ?? which I could figure out with a higher sample size. Though likely I could also figure it out just by the patterns.
1. Command header control byte. Followed by 1 int16_le. (Speed, Unk)
2. Position byte. Followed by 3 int16_le
3. Laser Off, X value, Y value. Followed by 2 int16_le
4. Termination byte. 0 int16_le
5. Laser On, X value, Y value. Followed by 2 int16_le
6. Laser Off, Y value. Followed by 1 int16_le
7. Laser Off, X value. Followed by 1 int16_le
8: Laser On, X value. Followed by 1 int16_le.
Now reasonably I can assume that 3 and 5 differ by a bit. And 7 and 8 differ by a bit. And there's a bunch of patterns in the byte codes. And 4 of those bits are randomish. They might be CRC or actually just purely random, the bytes are evenly distributed within the group. So the 4 non-control bytes are likely something evenly distributed.
Given that I do not know the hash, or even where any of these bytes are located. Is this solvable? I think the position would be solvable if there a very easy method to do the hash. I don't know anything about the randomish bits. And I can only take some educated guesses about the other bits. But, things like patterns 3, 4, 6 and 7 are highly similar I can clearly say if you add 0x50 to the first 8 bytes of 3 and subtract 0x0A from the second 8 bytes these patterns are the same. Or that 4 and 6 are the same if you add 0x10 for the first 8 bytes and subtract 0x08 from the second 8 bytes.
I can't however solve it. And the parts I'd think should be 1 bit flip apart because of their contextual meaning (3,5 and 7,8), seem less similar. I mean parts of #5 are clearly 2x parts of #3. Some seem off by a bitshift, others seem static amount in the higher nibble and lower nibble.
There's a lot of pattern here, and it's a 2013 series laserboard so it's not going to do something highly processor intensive.
Additional seemingly not highly relevant information available: https://github.com/meerk40t/moshi for the project, and the wiki there as well.
All numbers are in Hex.
What are these lines of hex?
These are all different forms of the same command as interpreted by the laser cutter control board.
Are they pulled from network packets?
These were intercepted using wireshark, running over a USB channel. The messages were then sent to a CH341 serial chip.
What are the "x" and "y" values you used to generate this traffic?
The X and Y values are positions for the laser cutter to go to. These are given by a 16 bit little endian value. The command issued has some kind of flag as to what type of value is being sent. Either x or y or both and y. These are different commands but there are 16 forms of each command.
What do you mean by "followed by 1 int16_le"
I mean in the command structure that particular command in one of those 16 forms is followed by a single 16 bit integer in little endian form.
The problem is I would expect these values to be the same value, typically flagged with certain bytes on or off to explain from the laser cutting software what this command wants the laser cutting board to do. But, rather than 1 command that means 1 thing, I have 16 commands that mean 1 (I think) thing. Which seems weird. There's a bunch of patterning, but I can't really figure out what that pattern is.

Answer 1

def swizzle(b, p7, p6, p5, p4, p3, p2, p1, p0):
return ((b >> 0) & 1) << p0 | ((b >> 1) & 1) << p1 | \
((b >> 2) & 1) << p2 | ((b >> 3) & 1) << p3 | \
((b >> 4) & 1) << p4 | ((b >> 5) & 1) << p5 | \
((b >> 6) & 1) << p6 | ((b >> 7) & 1) << p7
def convert(q):
if q & 1:
return swizzle(q, 7, 6, 2, 4, 3, 5, 1, 0)
else:
return swizzle(q, 5, 1, 7, 2, 4, 3, 6, 0)
Applies to turn the code lines into:
['50', '51', '52', '53', '54', '55', '56', '58', '59', '5a', '5b', '5c', '5d', '5e', '5f', '8e']
['00', '01', '02', '03', '04', '05', '06', '07', '08', '09', '0a', '0c', '0d', '0e', '0f', '18']
['70', '71', '72', '73', '74', '75', '76', '77', '78', '79', '7a', '7b', '7c', '7d', '7e', '7f']
['20', '21', '22', '23', '24', '25', '26', '27', '28', '29', '2a', '2b', '2c', '2d', '2e', '2f']
['f0', 'f1', 'f2', 'f3', 'f4', 'f5', 'f6', 'f7', 'f8', 'f9', 'fa', 'fb', 'fc', 'fd', 'fe', 'ff']
['30', '31', '32', '33', '34', '35', '36', '37', '38', '39', '3a', '3b', '3c', '3d', '3e', '3f']
['60', '61', '62', '63', '64', '65', '66', '67', '68', '69', '6a', '6b', '6c', '6d', '6e', '6f']
['e0', 'e1', 'e2', 'e3', 'e4', 'e5', 'e6', 'e7', 'e8', 'e9', 'ea', 'eb', 'ec', 'ed', 'ee', 'ef']
The patterns used differ slightly based on the bit parity. There's an errant number in the first and second rows that does not fit the pattern. In both cases this number is increased by 1 from the number one would predict. This is at least usable. There might be a different algorithm causing the swizzling with a carry error causing rounding down for 0x0C not being 0x0B and 0x74 not being 0x73.
This also predicts the other unseen patterns are:
['00', '01', '40', '03', '10', '21', '50', '23', '04', '09', '44', '0b', '14', '29', '54', '2b']
['08', '11', '48', '13', '18', '31', '58', '33', '0c', '19', '4c', '1b', '1c', '39', '5c', '3b']
['80', '05', 'c0', '07', '90', '25', 'd0', '27', '84', '0d', 'c4', '0f', '94', '2d', 'd4', '2f']
['88', '15', 'c8', '17', '98', '35', 'd8', '37', '8c', '1d', 'cc', '1f', '9c', '3d', 'dc', '3f']
['02', '41', '42', '43', '12', '61', '52', '63', '06', '49', '46', '4b', '16', '69', '56', '6b']
['0a', '51', '4a', '53', '1a', '71', '5a', '73', '0e', '59', '4e', '5b', '1e', '79', '5e', '7b']
['82', '45', 'c2', '47', '92', '65', 'd2', '67', '86', '4d', 'c6', '4f', '96', '6d', 'd6', '6f']
['8a', '55', 'ca', '57', '9a', '75', 'da', '77', '8e', '5d', 'ce', '5f', '9e', '7d', 'de', '7f']
['20', '81', '60', '83', '30', 'a1', '70', 'a3', '24', '89', '64', '8b', '34', 'a9', '74', 'ab']
['28', '91', '68', '93', '38', 'b1', '78', 'b3', '2c', '99', '6c', '9b', '3c', 'b9', '7c', 'bb']
['a0', '85', 'e0', '87', 'b0', 'a5', 'f0', 'a7', 'a4', '8d', 'e4', '8f', 'b4', 'ad', 'f4', 'af']
['a8', '95', 'e8', '97', 'b8', 'b5', 'f8', 'b7', 'ac', '9d', 'ec', '9f', 'bc', 'bd', 'fc', 'bf']
['22', 'c1', '62', 'c3', '32', 'e1', '72', 'e3', '26', 'c9', '66', 'cb', '36', 'e9', '76', 'eb']
['2a', 'd1', '6a', 'd3', '3a', 'f1', '7a', 'f3', '2e', 'd9', '6e', 'db', '3e', 'f9', '7e', 'fb']
['a2', 'c5', 'e2', 'c7', 'b2', 'e5', 'f2', 'e7', 'a6', 'cd', 'e6', 'cf', 'b6', 'ed', 'f6', 'ef']
['aa', 'd5', 'ea', 'd7', 'ba', 'f5', 'fa', 'f7', 'ae', 'dd', 'ee', 'df', 'be', 'fd', 'fe', 'ff']
Given in byte order rather than sorted.