For the first part - It’ll likely help in reversing, but if anything my first goal would be to target the locking mechanism rather than the detection method.If someone could pop the back off a unit and take a photo of any leds/sensors in the reagent path, and any markings on them, the sensor type could be determined.
From that information a patch to the firmware that removes the test should not be all that difficult.
Or it could simply be a matter of replacing the sensor with components that send psuedo sensor data back to the MCU to make it think the reagent is within spec.
edit:
The second is probably the easiest, as it is super easy to interrogate the data between a sensor and the MCU no matter what type of device it is.
They may change things in a future update in ways I wouldn’t describe here to still recognize it, and that would require further work to mask the differences in other ways - but I think that software wise it’ll be the easier path going forward.
As for a hardware patch - that’s actually a really good idea, and could be something as easy as adding the right resistor to mask the differences.
The question is wether the change is that obvious and not some sort of a long term sampling to detect small variations that could otherwise be interpreted as an acceptable noise.
Another point I would like to add is that from further looking at the firmware, it seems update files do not necessarily have to contain all parts of the firmware, and it may actually reserve some memory to exchange payloads on the fly or load them separately from another source, some of which looks to be stored on the SD card - so it’ll be helpful to have a full image of the SD card as well.
Edit: Also, if anyone of the owners is able to solder 2 wires to the board and has an FTDI on hand - a serial access to the device would be a gold mine in terms of useful information we can extract from it for reversing purposes.
Last edited: