CuVoodoo

the sorcery of copper

User Tools

Site Tools


printer_cartridge

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
printer_cartridge [2017/09/14 10:51]
kingkevin [identifying cartridge chip] add link
printer_cartridge [2017/09/14 11:47] (current)
kingkevin add implementing cartridge chip
Line 38: Line 38:
 To identify the chip I proceeded the following way: To identify the chip I proceeded the following way:
   - the top marking "33 1004 620B1" didn't yeld any match   - the top marking "33 1004 620B1" didn't yeld any match
-  - the board has only two pads, one for ground and one for power and thusthus it is probable ​they are using the 1-Wire protocol+  - the board has only two pads, one for ground and one for power and dataThus they might use the 1-Wire protocol
   - the package (TSOC-6) and pinout (pin 1: ground, pin 2: power+data) match the one of 1-Wire devices   - the package (TSOC-6) and pinout (pin 1: ground, pin 2: power+data) match the one of 1-Wire devices
-  - the communication between the printer and chip matches the 1-Wire protocol+  - the communication between the printer and chip matches the 1-Wire protocol ​(trace captured using a logic analyser)
   - the family code (last byte of the ROM ID) "​0xb3"​ (decoded from the trace) doesn'​t match [[https://​github.com/​owfs/​owfs-doc/​wiki/​1Wire-Device-List|common lists]] (mTC002 it a for a thermocouple. a different manufacturer might have used the same family code)   - the family code (last byte of the ROM ID) "​0xb3"​ (decoded from the trace) doesn'​t match [[https://​github.com/​owfs/​owfs-doc/​wiki/​1Wire-Device-List|common lists]] (mTC002 it a for a thermocouple. a different manufacturer might have used the same family code)
   - the function commands present in the trace (0x0f, 0xaa, 0xa5) [[http://​owfs.sourceforge.net/​family.html|match]] a couple of devices   - the function commands present in the trace (0x0f, 0xaa, 0xa5) [[http://​owfs.sourceforge.net/​family.html|match]] a couple of devices
   - the [[https://​www.maximintegrated.com/​en/​products/​digital/​memory-products/​DS2432.html|DS2432]] matches the usage: 1-Wire (the protocol used) EEPROM (to store the toner level) with SHA-1 authentication (to prevent counterfeit cartridges). The [[http://​datasheets.maximintegrated.com/​en/​ds/​DS2432.pdf|Maxim datasheet]] is abridged and does not contains family code and function command codes (lame security by obscurity), but the [[http://​pdf.datasheetcatalog.com/​datasheet/​maxim/​DS2432.pdf|Dallas datasheet]] does   - the [[https://​www.maximintegrated.com/​en/​products/​digital/​memory-products/​DS2432.html|DS2432]] matches the usage: 1-Wire (the protocol used) EEPROM (to store the toner level) with SHA-1 authentication (to prevent counterfeit cartridges). The [[http://​datasheets.maximintegrated.com/​en/​ds/​DS2432.pdf|Maxim datasheet]] is abridged and does not contains family code and function command codes (lame security by obscurity), but the [[http://​pdf.datasheetcatalog.com/​datasheet/​maxim/​DS2432.pdf|Dallas datasheet]] does
-  - based on this datasheet I implemented a DS2432 decoder for sigrok, and the capture matches (no bytes missing or exceeded, and the command ​order make sense). Only the family code does not match: 0x33 for DS2432, 0xb3 for our chip +  - based on this datasheet I implemented a DS2432 ​protocol ​decoder for sigrok, and the capture matches (no bytes missing or exceeding, and the commands ​order make sense). Only the family code does not match: 0x33 for DS2432, 0xb3 for our chip 
-  - even the used SHA-1 hash implementation used for authentication matches (I re-implemented and test it with key material I found later)+  - even the used SHA-1 hash implementation used for authentication matches (I re-implemented and tested ​it with key material I found later)
  
 Thus this chip is a DS2432, either re-branded or cloned. Thus this chip is a DS2432, either re-branded or cloned.
 [[https://​electronics.stackexchange.com/​questions/​171329/​help-identifying-this-chip-eeprom|Other printers]] (here a filament cartridge for the Stratasys UPrint SE 3D printer) also use this chip, but in a [[https://​www.3dprintforums.com/​showthread.php/​3153-How2-Refill-the-EEPROM-of-the-HP-DesignJet-3D-aka-uPrint|non-secure]] [[https://​github.com/​bvanheu/​stratasys/​issues/​21|way]]. [[https://​electronics.stackexchange.com/​questions/​171329/​help-identifying-this-chip-eeprom|Other printers]] (here a filament cartridge for the Stratasys UPrint SE 3D printer) also use this chip, but in a [[https://​www.3dprintforums.com/​showthread.php/​3153-How2-Refill-the-EEPROM-of-the-HP-DesignJet-3D-aka-uPrint|non-secure]] [[https://​github.com/​bvanheu/​stratasys/​issues/​21|way]].
 +
 +==== implementing DS2432 ====
 +
 +I re-implemented the DS2432 based on the datasheet using a [[https://​wiki.cuvoodoo.info/​doku.php?​id=stm32f1xx#​core_board|STM32F1 development board]].
 +The source code is available in [[https://​git.cuvoodoo.info/​ds2432/​about/​|git]] (not all features are implemented).
 +
 +The chip usage seems to be secure since it does verify the Message Authentication Code (MAC) and reports errors if it does not match.
 +There are still a couple of possible attacks though (untested):
 +  * use a replay attack based on data from a non-empty cartridge chip. The printer used random challenges (not always) but there a just 3 bytes of challenge, thus you just need to store 2^24 possibilities of 20-bytes MACs = 336 MB of data, for the page containing the toner level, or 1.34 GB for all for memory pages. The DS28E01-100 alternative offers 5 bytes of challenge to counter this attack
 +  * since the printer tries 4 times reading out the authenticated page using the same challenge there is plenty of time to forward the request and use an original chip as oracle
 +  * the print is done before updating the toner level, thus you could completely ignore the corresponding write commands
 +  * even if you use an original chip a oracle, the write success is not authenticated,​ thus you can fake that the write succeeded when you are MitM, if the printer doesn'​t read the authenticated value afterwards to ensure the write took place
 +  * the printer starts by reading memory page 1 without authentication. Maybe there is some field in there allowing to switch to god mode (e.g. developer mode), which does not require authentication
 +
 +{{ :​printer_cartridge:​mini_p1080152.jpg?​300|}}
 +But in the end I decided to try finding the secret stored in the chip.
 +It could not be read out using the 1-Wire read memory command though.
 +
 +I also found a counterfeit chip for this cartridge.
 +They also re-implemented the DS2432, but on a PIF12F683.
 +There too I could not read out using the 1-Wire read memory command.
 +But the PIC had no read protection enabled, allowing me to dump flash and EEPROM using a PICkit 2.
 +The EEPROM contained all the memory otherwise read through 1-Wire, including the secret, but this time in clear.
 +
 +Re-using this key allowed me to pass authentication successfully.
 +I was now able to change the memory content at will, and found a field in page 2 which did not trigger the "toner low" warning.
 +
 +It also turns out that the secret is bound to the ROM ID.
 +Changing the ROM ID causes the authentication to fail.
 +This prevents an attacker to dump the secret from one cartridge and simply copy it into another DS2432.
 +This is also the reasons why the counterfeit chip uses a micro-controller,​ so they can also re-use the ROM ID from the chip they dumped the secret from.
 +But this also means that the main printer CPU has to generate the secret based on the ROM ID.
 +If this algorithm gets reversed (e.g. by dumping the firmware), you could generate the secret for any DS2432.
 +
 +The next step would be to dump the secret from the original cartridge chip.
 +This is doable with a bit of efforts.
 +To be continued ...
printer_cartridge.txt · Last modified: 2017/09/14 11:47 by kingkevin