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
Next revision
Previous revision
Last revision Both sides next revision
printer_cartridge [2017/09/14 10:51]
kingkevin [identifying cartridge chip] add link
printer_cartridge [2019/04/15 08:17]
kingkevin [identifying cartridge chip] update link
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/​ibutton/​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/​forum/stratasys/​how2-refill-eeprom-hp-designjet-3d-aka-uprint-3153/​|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: 2019/04/15 08:32 by kingkevin