Cricut PCap

[Richard Allen]

Hey

I've recorded a firmware upload for the Cricut.

PCap files are available at http://rsaxvc.net/Projects/Cricut, I just used VirtualBox + WireShark.

Apparently, the trial software, which I've installed in VirtualBox on the Workstation, can only cut with the original card that came with the machine. In this case, we need a 'George'. If anyone has one I could borrow for a week or so, that would be awesome.

Richard

[Craig Berscheidt]

I thought I dropped that back off at the space... It's still in my
backpack most likely. I'll be sure to drop it off next time I'm at
the space. In the mean time you can just short 3 pins to get the
original cartridge to be recognized:
http://www.built-to-spec.com/blog/2010/02/27/cricut-personal-dissection/

I'm wiring a serial pass through setup to mine to see if I can get a
capture of the serial data directly. I should have all the stuff to
set this up by this weekend if my Adafruit order comes in.

-Craig

> --
> You received this message because you are subscribed to the Google Groups
> "CCCKC" group.
> To post to this group, send email to cc...@googlegroups.com.
> To unsubscribe from this group, send email to
> ccckc+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/ccckc?hl=en.
>

[Richard Allen]

Well, that sounds way easier than an FTDI Decoder script. I've got a TTL serial->USB cable down at the space right now.

[Craig Berscheidt]

If anybody's interested in the Cricut I'm made some more progress
today. I've found out why the host applications (Design Studio, SCAL,
Make-the-cut) don't use the virtual serial port FTDI interface and
therefore can't be logged with serial sniffer software. Turns out the
serial communication looks like standard 8N1 but the baud rate
approximately 200kbps. This is a non-standard baud rate and requires
you to use the FTDI D2xx direct drivers to configure the FT232BM chip
in the Cricut. I've modded my Cricut personal a bit and can sniff the
data using a couple TTL-232R cables that can also be accessed through
the same D2xx library using a Python script and pyUSB.

Unfortunately, I've been unable to create a pass through script
successfully (I can't sever the connection between the micro and
USB->RS232 chip and pass all data through the TTL-232R cables). It
doesn't look like any hardware flow control signals are being used
between the micro and the FTDI chip but I'm going to double check the
next time I take a look at it. There may be some timing issues that I
haven't hashed out yet. The PC seems to send 1 character (1 byte) at
a time with a character spacing of approximately 1ms. I haven't been
able to reproduce this timing exactly in Python and may not be able
to.

If you're interested in working on this as well, email me and I can
send you my Python scripts and logged data and some scope captures of
the TX/RX signals.

-Craig

[ax0n]

I don't have any advice, but this is some inspiring reveng work, Craig!

[Rob Giseburt]

I can't look right now, but I recall on your blog mentioning that the
main chip us an avr. Do you see a 6 or 10 pin header around? We could
possibly (as long as they left the firmware upgradable) pull the flash
off of the avr. Better, we could then safely reflash it and write our
own control program. (G-code, anyone?)

I'd love to help if I could.

-Rob

On Mar 21, 2010, at 6:10 PM, Craig Berscheidt <craig.be...@gmail.com

[Craig Berscheidt]

I didn't see an ICSP header but one could be added with a little bit
of work. I'd prefer to create a driver program that would work
without flashing custom firmware. Reading the firmware off of the
device might be more trouble than it's worth at this point in the
game. It might be worth trying just to see if they're utilizing any
of the built in Atmel security features (I need to read up on these a
bit, but I'm assuming they are at this point).

It would be cool later on if we could RE the bootloader on the thing
so we could run custom firmware without opening the thing up and
soldering on an ICSP connector.

-Craig