User:Coda/Hexdump
From Cricut Hacking Wiki
New hex dump. The following is the transcript of making the Cricut Cutting Standard cut.
(--snip-- useless dump, full of noise)
- The timestamps show that this is VERY slow. I suspect timing issues due to the debug logging because previous tests took only a couple seconds. The cut DID happen properly though, eventually. Annoyingly this may mean that there's extra data being passed around to deal with the noisy transfer. In particular some of the commands appear to be failing because the reads are coming back with exactly duplicate data. I'm going to try reducing the excess logging from the driver and see what we come up with.
Coda 04:12, 10 January 2012 (UTC)
More dumps, with a cleaned-up debug driver to reduce timing problems.
This exchange happened when I tried to cut the Cricut Cutting Standard with no mat in the machine:
[00:57:49] Write: 0460000000 .`... [00:57:49] Read: 086A00000000000000 .j....... [00:57:49] Write: 0484010000 ..... [00:57:49] Read: 0400000000 ..... [00:57:49] Write: 0460000000 .`... [00:57:49] Read: 086A00000000000000 .j....... [00:57:49] Write: 0484010000 ..... [00:57:49] Read: 0400000000 .....
This one is particularly curious because it isn't polling the device, and when I loaded the mat it didn't do anything. I'm not sure what I did to get the protocol out of sync. I record it here because the commands look simple and unencrypted.
This command appears to be used to poll the Cricut for status updates when waiting for the user to load a mat:
10E6CC2B2D2852893BD53BC022E166EA3C
There's no discernable pattern to the response, but occasionally the Cricut will generate extra replies, which could cause trouble for an application not expecting it.
Cutting the Cricut Cutting Standard, this time without excess timing noise:
[01:06:02] Write: 1076D5DC4536E9E5D6B9E5664C619BFB .v..E6.....fLa..
[01:06:02] Write: 56 V
[01:06:02] Read: 10B1C15955AC45650AA71A9A204AA83E09 ...YU.Ee.... J.>.
[01:06:02] Write: 1001B8D205086D81B0F831D0337CB24B73 ......m...1.3|.Ks
[01:06:02] Read: 104445DAACA5D82A3FC7178E3C7E12C4A3 .DE....*?...<~...
[01:06:02] Write: 1045C2BE0E9E41FEE02815CAE482410255 .E....A..(....A.U
[01:06:02] Read: 104445DAACA5D82A3FC7178E3C7E12C4A3 .DE....*?...<~...
[01:06:02] Write: 10E233E8B232DEE651DC8F82E82EC7CA ..3..2..Q.......
[01:06:02] Write: 62 b
[01:06:02] Read: 107DC999A5174C7CCA4384EA23E892BB71 .}....L|.C..#...q
[01:06:02] Write: 10FD66371B20D1CD4CDD53B77868004819 ..f7. ..L.S.xh.H.
[01:06:02] Read: 109B4792B3501A31AA204D5355AB23DE66 ..G..P.1. MSU.#.f
[01:06:02] Write: 10DCD6D1E23B06EB33E3C1FEB06AE67B4D .....;..3....j.{M
[01:06:02] Read: 101E88B6ACC0B511E3916CF92846CDF06B ..........l.(F..k
[01:06:02] Write: 1033E7589901D782943D3C598A6276D192 .3.X.....=<Y.bv..
[01:06:02] Read: 1002355EDFDAE68FD7733924B6017B29EF ..5^.....s9$..{).
[01:06:02] Write: 10A2B41C465098C327B991A0B603036B33 ....FP..'......k3
[01:06:02] Read: 104448BF624FAFA6ED8F6C9AC896BA38AB .DH.bO....l....8.
[01:06:02] Write: 1063FE98822174C7745F468F45637B6784 .c...!t.t_F.Ec{g.
[01:06:02] Read: 100554CE94E7F7DCE00E1CD85FAAE2FBA9 ..T........._....
[01:06:02] Write: 10482D466AE28F4556F0E4E15EF18B9D71 .H-Fj..EV...^...q
[01:06:02] Read: 10A62AA10E58A2872CCA27DEC913E57B1B ..*..X..,.'....{.
[01:06:02] Write: 10DCD6D1E23B06EB33E3C1FEB06AE67B .....;..3....j.{
[01:06:02] Write: 4D M
[01:06:02] Read: 1052149E1AB82D883CC539516B55D389E7 .R....-.<.9QkU...
[01:06:03] Write: 10D90F8ED1951DD9356237A0B164860C ........5b7..d..
[01:06:03] Write: 60 `
[01:06:03] Read: 10DEA2FB0D4D229B2FC722768446039A6A .....M"./."v.F..j
[01:06:03] Write: 104DBFE1EF37A1E798C235CC3F080AB4 .M...7....5.?...
[01:06:03] Write: F9 .
[01:06:03] Read: 10DEA2FB0D4D229B2FC722768446039A6A .....M"./."v.F..j
It would appear that sometimes CraftRoom delays for a brief instant to send the last byte of a command. Here we see a variety of unrecognizable 16-byte commands. I'm going to speculate that the Mini parses 16-byte messages as encrypted commands, similar to how the old protocol parsed the data of 0x40 as an encrypted command.
- It's interesting to observe 104445DAACA5D82A3FC7178E3C7E12C4A3 appears twice. Perhaps the reply came back damaged or negative and it re-transmitted.
Coda 07:14, 10 January 2012 (UTC)
- Re-reading the dump here it turns out that duplicate message was a reply, not a command. And it's known that the Cricut Mini (I don't know about other devices) will repeat its previous reply if an invalid command is read. This implies that 1045C2BE0E9E41FEE02815CAE482410255 is possibly invalid. Coda 16:00, 10 January 2012 (UTC)
I'm sorry I didn't understand the formatting you were using. Since you appear comfortable recompiling drivers can I safely assume you are a programmer?
- I think you are right that 0x10 appears to be a command code.
- Are the short lines the responses from the Cricut? If so they might be how long the Cricut expects that action to take so the computer knows when to send another command. If this is true, the success zeros (NULL's) are truncated.
You originally said this was a rectangle, could you be very specific. I'm thinking if we create a Standard Cut Pattern we will know what Parameter values we are looking for.
The square has equal sides, so the command should have 2 parameters of the square values of 400-404. The other two parameters should be based on the Mat Bounds Command xmin=316, ymin=50, so the location coordinates should be 716-720 and 450-454. Using these known values it may be possible to brute force, the Keys.
- That would be a very safe assumption! Yeah, I am.
- No, based on the existing known protocol I think the 0x10 is a length byte implying an 17-byte packet.
- That's all one-way, writes only. The short lines are either packets that got cut off due to a null terminator or they REALLY WERE that short. (I forgot to log the length parameter to write() to know!) I wasn't able to log the read()s possibly because of the null terminator issue.
- Actually the Mini's bounds start at (0,0). And I don't think brute-forcing the keys is likely to be feasible; they're 128-bit keys for a cipher that isn't vulnerable to known-plaintext attacks. It has a vulnerability for a chosen-plaintext attack but on the assumption the underlying data works the same way the noise parameter we wouldn't be able to employ it... unless maybe the communication between CraftRoom and the bridge process is unencrypted? That might be a good avenue of exploration, and potentially an easy one to approach. (And one that won't panic my kernel if I screw up!)
The new dump data is great! I am positive it's encrypted. I think if you want to catch unencrypted data the choices are Debug the Craftroom App or electrically find the pins on the internal side of the PIC. I've been thinking and one of the command parameters mentioned for 0x40 is 'noise', so that the same command can be sent multiple times and the Cricut knows it's not a duplicate. (This may of changed for the Mini, but I'm not sure yet.) I think the Real Time Clock would be a great source for the 'noise/random' value. In addition to the cut test can you describe the mechanical actions of the Cricut? The would allow us to narrow down which command is which.
Example
- Move cutter to x=1.0, y=1.0.
- Drop cutter,
- Cut to x=1.0, y=2.0,
- Cut to x=2.0, y=2.0,
- Cut to x=1.0, y=1.0.
- Lift Cutter.
Any other actions or behaviors?
I don't see the start and end transaction commands in this list, did you exclude them or are they just not used?
I'm sure the encryption is the reason for choosing a MicroController to handle the USB communication.Fraser 20:10, 10 January 2012 (UTC)
- I didn't exclude anything. If there are start and end transaction commands involved, they're encrypted too. 0x21 and 0x22 don't work.
- The mechanical action goes like this:
- Move to x=1 y=~1.6
- Lower cutter
- Cut to x=1 y=1
- Cut to x=2 y=1
- Cut to x=2 y=2
- Cut to x=1 y=2
- Cut to x=1 y=~1.4
- Lift cutter
- Explanation: The official Cricut patterns try to avoid having a cut start or end on a corner and always try to overcut the beginning of the shape a little bit to ensure clean removal.
- I'm tempted to see what happens if I just replay the commands verbatim. It might be, at least, INTERESTING.
- Debugging the app is going to be challenging. The user interface is an Adobe AIR application so any OS-level debugger isn't going to be able to see anything useful, and the bridge is painfully difficult to mess with -- CraftRoom shuts down if anything unusual is detected. I also don't know how the two processes communicate; I suspect shared memory (I see CraftRoom allocating shm in the kernel logs), and that's not likely to be snoopable.
- Coda 16:48, 10 January 2012 (UTC)
I'm really stuck on the Real Time Clock, it has to be related. Reading the datasheet on the PIC, there is also a CRC generator built into it. Maybe there is a CRC appended on the command. If that is true, is it appended before or after encryption? I used an online CRC calculator [[1]] with the write command (01B8D205086D81B0F831D0337CB24B73) and removed characters from the end and didn't get any matches on the removed characters. So I'm thinking Encryption happens first. Is this a reasonable assumption?
I encourage you to try the Replay of the data you've collected. Also are the commands the same performed even a few minutes later? When Craftroom is restarted? I'm wondering if the clock changes the new commands, maybe restarting the app changes a seed value.
(Thinking out loud) Each Parameter is going to be 0x0000 to 0xFFFF for Mat or Shape Dimensions. 16 bytes could contain 8 values (+/- if some are command codes or CRC).
- 2-byte Command (Maybe 1 byte)
- 2-byte Parameter
- 2-byte Parameter
- 2-byte Noise
- 6-byte ?Unknown?
- 2-byte CRC
FYI: I changed up the Main Page to add a Cricut Mini Hardware page. Fraser 20:10, 10 January 2012 (UTC)
- I don't think a CRC after encryption is likely. I would expect even the simple commands to include a CRC if that were true, and they don't.
- A CRC *before* encryption, on the other hand, may be sensible. If the Mini does the same thing as the older models and determines the command by trying out multiple keys until one succeeds, the CRC would be a perfect way to tell if you've succeeded without just guessing on range checks: you CRC the first 14 bytes and check the result against the last 2 (or 12 and 4 if it's CRC32), and if they match, you know the decryption is done.
- Another possibility is that the data is more packed. Previously a single curve required four commands, but four commands times four bytes would fit comfortably in a 16-byte payload with no noise.
- Or you could split the difference -- 4 bytes for value 1, 4 bytes for value 2, 4 bytes noise, 4 bytes CRC32.
- Or it could be the same as it was before (2 noise, 2 x, 2 y) padded to a length of 16 to allow encryption of a full block if they decided to change the cipher. This would make life difficult.
- It might be possible that the RTC is used to generate a rotating key. Again, this would make life difficult. Some of the commands done during initialization might read the current seed value.
- It might be a day or two before I can do any further digging. I'll keep you posted.
- Coda 22:04, 10 January 2012 (UTC)
If it helps, the CRC engine in the PIC does support 32bit. Maybe a Circle is another standard shape to cut, to confirm or deny if multiple commands are required for them. I believe that most 'drawing' API's have 4 values: X, Y, Height, Width.
I like the theory of validating the CRC after decrypting, it also removes the need for noise. This would put a lot of the hard "number crunching" work into the PIC, leaving the other processor, to handle the motor controls and Cartridge interaction.
PIC performs the following functions:
- USB Interface (as a Serial Port)
- XXTEA (most likely) decryption
- CRC Check of the decrypted results
- Pass results to other MicroController
I think I have to back down on my clock theories. One of the requirements [[2]] for using the Real Time Clock is an External Crystal. Looking back at your photos #7, there isn't anything that looks like a crystal near the correct pins and crystals are supposed to be as close as possible (usually less than 2") of the required pins. Looking back at the Microchip selector, this chip appears to be the only 16-bit chip (most are 8 or 32-bit) with USB and 28 pins (and a CRC engine). Most of of the Chips (9 of 14) especially the less expensive ones with 28 pins and USB include the Clock.
When you have time I'm interested in the run of the standard shape twice and restarting Craftroom and re-run the standard shape. This will confirm the commands don't change based on time or a seed value. I doubt this more now that I know about the clock.
I performed some starting "Brute Force" on one of the command strings above. The steps performed are decrypt the string, run CRC8, CRC16, CRC32 and compare them to the last 1,2 and 4 bytes of the command then increment key. The result is CRC has a really high collision rate, so that is not enough information to confirm or deny a key. If we could confirm CRC32 we have a better chance because there were fewer collisions.
I made a starter link on the Main Page to add a Mini specific page. Would you like to move the factual content from our discussion there?
Fraser 18:43, 11 January 2012 (UTC)
- Hey, really interesting dump, Coda! Is there strong evidence that they are still using XXTEA for the encryption? The fact that all the commands are 16 bytes could indicate that they've switched to using a block cipher, like triple-DES. Anyone know if the HW1 XXTEA keys brute-forced, or extracted from the software? If they are still using XXTEA and one were hypothetically trying to brute force the key (2^128=3e38 possible keys!), you could probably just look for lots of zeros. They'll be using mostly low numbers and probably padding commands out to 16 bytes too.
- --Q 23:09, 23 October 2012 (UTC)
- Honestly I don't have a clue. I agree that it looks like it may have switched to a block cipher. That said, if the protocol after decryption is anything like the old protocol (and I expect it to be) then there won't be all that many zeroes because it's a set of 16-bit fields. I wasn't on the scene when those keys were found; I suspect they were reverse-engineered out of older Cricut software but they've stepped up the security on the newer revisions. Coda 07:42, 24 October 2012 (UTC)
- I was thinking of the old move command, where the coordinates were 32-bit little-endian words, but were restricted to values <10000. That guarantees at least 18 bits of zeros. --Q 22:52, 24 October 2012 (UTC)
- Good point. That's possible. Part of me wonders if it might be more productive to dump the interactions between Craft Room and something first-gen so we know exactly what coordinates are being transmitted; then we could have a partial known plaintext. Unfortunately that sounds harder to do since the FTDI drivers aren't open-source like the ACM ones. Coda 23:13, 24 October 2012 (UTC)
- Serial ports are treated pretty much like reading and writing to a normal file, right? I wonder if it would be possible to write a transparent wrapper that would pass I/O to a serial port after logging it. Then you could tell craft room to use the wrapper port and get logging regardless of the underlying driver. Does that sound possible, or am I just showing my lack of experience with low-level hardware interfaces? --Q 19:12, 29 October 2012 (UTC)
- Good point. That's possible. Part of me wonders if it might be more productive to dump the interactions between Craft Room and something first-gen so we know exactly what coordinates are being transmitted; then we could have a partial known plaintext. Unfortunately that sounds harder to do since the FTDI drivers aren't open-source like the ACM ones. Coda 23:13, 24 October 2012 (UTC)
- I was thinking of the old move command, where the coordinates were 32-bit little-endian words, but were restricted to values <10000. That guarantees at least 18 bits of zeros. --Q 22:52, 24 October 2012 (UTC)
- Honestly I don't have a clue. I agree that it looks like it may have switched to a block cipher. That said, if the protocol after decryption is anything like the old protocol (and I expect it to be) then there won't be all that many zeroes because it's a set of 16-bit fields. I wasn't on the scene when those keys were found; I suspect they were reverse-engineered out of older Cricut software but they've stepped up the security on the newer revisions. Coda 07:42, 24 October 2012 (UTC)
