Close
0%
0%

Ink Tank Encryption

I'm trying to find out how to use the EEPROM chips that might be in CLI-226 ink tanks to share public keys for public-private key encryption

Similar projects worth following

So here's the idea:

What if there were some extremely cheap PCBs you could glue to your business card (or anything else) to share tiny pieces of information, such as PGP public keys?

I think that would be pretty neat.

So I'm trying to reverse-engineer the CLI-226 ink tanks' chipsets.

If I succeed at accessing their EEPROM, I'll try to make some USB device that you can insert the keychips into, then type into. (possibly connecting another keyboard to it for this purpose) The encrypted text would be outputted via keyboard emulation.

Do you think this sounds cool? If so, I'd appreciate if you follow this project—I'll be needing help with analysis, design and other stuff eventually. If you think you could be of help, please apply to join this project.

  • I was wrong.

    alpha_ninja09/04/2015 at 23:47 2 comments

    Hi there! Long time no see!

    Here's what I just found out.

    All cartridges share one bus.

    This makes sense.

    So, I tested inserting one cartridge after the other.

    Magenta is doing the sensing, I'm inserting black, then cyan, then pigment black, then yellow.

    Magenta only

    0xdef800 0x000000 0xdefc00 0x000000 0xdee400 0x000000 0xdef200 0x000000 0xdeec00 0x000000

    Magenta & Black

    0xdef800 0x000000 0xdefc00 0x000000 0xdee400 0x000000 0xdef200 0x000000 0xdeec00 0xdc0000

    0xdf2c64

    Magenta & Black & Cyan

    0xdef800 0x000000 0xdefc00 0x000000 0xdee400 0xbc0000 0xdef200 0x000000 0xdeec00 0xdc0000

    0xdf2432 0xdf2c64

    Magenta & Black & Cyan & Pigment Black

    0xdef800 0x000000 0xdefc00 0xef0000 0xdee400 0xbc0000 0xdef200 0x000000 0xdeec00 0xdc0000

    0xdf3c32 0xdf2432 0xdf2c64

    Magenta & Black & Cyan & Pigment Black & Yellow

    0xdef800 0xcf0000 0xdefc00 0xef0000 0xdee400 0xbc0000 0xdef200 0x000000 0xdeec00 0xdc0000

    0xdf3832 0xdf3c32 0xdf2432 0xdf2c64

    I don't know why I didn't test for this.

    Anyway, these are the conclusions I can make from this:

    1. The read protocol is as follows:

    0xdef800 (Yellow) 0x*****

    0xdefc00 (Pigment Black) 0x*****

    0xdee400 (Cyan) 0x*****

    0xdef200 (Magenta) 0x*****

    0xdeec00 (Black) 0x*****

    2. The write protocol is as follows:

    0xdf2c64 (Black)
    0xdf2432 (Cyan)
    0xdf3c32 (PgBk)
    0xdf3832 (Yellow)
    0xdf3232 (Magenta)


    Edit:

    Turns out the cartridge I used for testing had the traces cut. Oops :P

    I've added the values I got from another test, but won't be retesting the values I measured above :)

  • More protocol analysis

    alpha_ninja08/31/2015 at 15:28 0 comments

    This is old information

    For newer information, see the project log "I was wrong."

    I've found that the following pattern is used:

    (Part 1 of protocol—call/response: 16 - 8 bits.)

    0xdef800:

    Is always sent.

    0xcf0000 or 0x000000:

    Might have different values too, haven't done enough testing

    0xdefc00:

    Is always sent.

    0xef0000:

    Is always sent.

    0xdee400:

    Is always sent.

    0xbc0000 or 0x000000:

    Might have different values too, haven't done enough testing.

    0xdef200:

    Is always sent.

    0x9b0000 or 0x000000:

    Seems to be remaining ink pages or something—this is the same for every cartridge no matter in what slot it is.

    0xdeec200:

    Is always sent.

    Then one of the following:

    0xdeec00

    0xdc0000


    Part 2 of the protocol - 24 bit packages

    Sometimes: 0xdf38 32

    Always: 0xdf3c 32

    Sometimes: 0xdf24 32

    Sometimes: either 0xdf2c 64 or 0xdf32 32


    In conclusion, the first part of xmissions is made up of 16-bit packages that start with 0xde and are replied to with some other 8-bit value (can also be 0). This is probably the read commandI'll have to test this hypothesis.

    The second part of xmissions is made up of 24-bit packages that start with 0xdf and in the next two bytes most likely have the address and value after them. I haven't yet seen values other than 0x32 and 0x64. Thus, this is probably the read commandI'll have to test this hypothesis, too.

  • The PCB

    alpha_ninja08/31/2015 at 06:01 0 comments

    Here's the pin assignment for the PCB:
    1 - Clock
    2 - Ground
    3 - Data
    4 - VCC (?)
    5 - LED (When this is LOW and 4 is HIGH, the LED is on.)

    I'd like to point out that the LED pin might have some other connections since it seems to be pulled high/low without an electrical connection to the printer. However, I haven't been able to confirm this.

  • The Protocol

    alpha_ninja08/31/2015 at 05:50 0 comments

    I'm still working on figuring out the protocol that's used for communication between the printer and the cartridge.

    This is what I know so far:

    There is a clock signal—it runs at 100KHz. It doesn't stop. Ever. It's also falling-edge triggered.

    There is a data signal.

    This is a xmission:

    These xmissions have a delay of about 76ms in between them.

    There's 2 parts. I don't know the significance of this, nor what part pulls data high when for what reason.

    This is the first part of an xmission:

    I'm also not sure what this is. I think it might be the printer reading from the cartridge's EEPROM—sending a 16 byte address and receiving an 8 byte value. Notably, the fourth value seems to be zero.

    This is the second part of an xmission:

    Considering the previous part, the logical conclusion is that this is writing to the EEPROM—the packets sent each have 24 bits, so that's probably the address and then the data.

    I've extracted all this information from csv dumps via Python. You can see it here.

    The xmissions I have recorded, so far, are from when the printer is open. I haven't yet recorded xmissions while printing a page, but this is necessary because that is most likely a time at which the printer will write to the EEPROM. I'll have to do this sometime later.

View all 4 project logs

Enjoy this project?

Share

Discussions

jibz wrote 02/14/2017 at 18:58 point

Hey ! Really interesting !
Did you try to "emulate" a cartridge ?
I mean, put an tiny µC (like ATtiny13 or smthg like it) in a fake cartridge, and "answer", memorise, all the instructions of the printer, ESPECIALY while printing ? In order to get printingpower as long as wished with an empty cartridge ! (My dream).
There is perhaps place enough for a communication way, BT of whatever.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates