Unfortunately, that might be tricky without the private keys in the controller. User manual [0] describes a per site 128 bit AES keys used for the RF comms.
Might be easier to just write fresh firmware for them - there's some code here [1] for driving the display that could be ported to the CC2510. There's SDCC support for at least the CC2511 as used in the Pololu Wixel [2]. It's certainly possible that their cryptosystem is broken but I wouldn't bet on it.
0: https://fcc.report/FCC-ID/2ACQM-EDG2-0590-A/4393106
1: https://github.com/atc1441/E-Paper_Pricetags/tree/main/GxEPD...
AES is symmetric cryptography, so that should be possible to extract from the firmware. The tags also show a QR code when the aren't initialized yet, this is likely the setup key. I also read that even if tags are already initialized, it's still possible to reset them with some kind of PUK (not sure how to get that PUK though)
I couldn't find a datasheet for the e-paper screen, so even if re-implementing communication with stock firmware proves to be infeasible, I'll still need the dumped firmware to figure out how the e-paper screen is controlled.
There's nothing too special in the firmware, just a state machine that's sleeping most of the time to save power, and wakes up the device at regular interval in its own designated time slot to listen to the radio briefly if the base station is trying to address it, then receives the pricetag image via radio and copies it to the flash and updates the screen if needed, then goes back to sleep. IIRC, the time slots are, from 0 to 255, with 256 being the broadcast address, and the last HEX byte in the serial number sticker is also its timeslot number.
The only juicy part in the FW, if you can find it, would be the waveform for the e-ink display, as those are e-ink confidential most of the time for some bizarre reason. It's not like there are no waveforms already on the internet for displays like that, but e-ink likes to keep the really good waveforms for themselves and their best customers.
Thanks for the trip down memory lane. Good times.
For the display, this poster has something similar and talks about a datasheet - there's even a pinout for the flex cable (and it's supposedly SPI) [0]. It's for the 2.6" version not the 2.7 though so might be totally different. A comment on the post (by this person [1]) claims that they have working cleanroom CC2510 code that drives the display but who knows.
Great project anyway - I look forward to part two (and what you find on that flash chip)!
(Edit: sorry if you know this already, but there's a manual for the labels themselves [2] implying the setup page is permanently stored in one of the 4 slots - hopefully in that external flash chip)
0: https://epongenoir.blogspot.com/2017/10/
1: http://andreiprojects.blogspot.com/
2: https://fccid.io/2ACQM-EDG1-0260-A/User-Manual/User-Manual-5...
I love learning this kind of stuff through this site. In the world of reverse engineering or hacking stuff together, it feels like such a fumbly exercise that there just isn’t any discipline to it, but experts definitely learned some tricks and learning from them is such a treat. I’ll have to download that book and give it a read sometime soon.
https://www.bunniestudios.com/blog/
You can grab the download directly from NoStarchPress:
Hopefully for the store's sake, there'd be some sort of public/private key system so that only the holder of the private key can distribute price changes wirelessly. I wouldn't bet money on that though.
(edit) - I see someone else posted the manual and that there's a per-site AES key. That's a good sign I guess.
These days stores essentially just map an item’s UPC to a price in a DB in their point of sales software. The price isn’t encoded on the tag. Which brings me to my question: why the heck are we making an eink price tag with heavy security when the source of truth is the POS anyway? I mean no negativity about reversing one, it’s a super interesting and fun project. Just, “why?” in the first place does this thing exist? Maybe it’s just convenience and saves on labor costs to be able to update the price of all the items in your store at once and not pay a human to go out and relabel them?
The Shopping Reform and Modernization Act, or Scanner Law, requires that most items on store shelves be clearly displayed with the price; by signage, electronic reader, price sticker, or any other method that clearly and reasonably conveys the price to a consumer in the store at the place where the item is located. If an automatic checkout system (scanner) charges you more than the displayed price of an item, and:
the transaction has been completed, and you have a receipt indicating the item purchased and the price charged for it; Then:
You must notify the seller that you were overcharged, within 30 days of the transaction, either in person or in writing. Within two days of receiving your notice, the seller may choose to refund you the difference between the amount charged and the price displayed plus a "bonus" of ten times the difference, with a minimum of $1.00 and a maximum of $5.00. If the seller does not pay you both the refund and the bonus, you may bring a lawsuit to recover your actual damages or $250.00, whichever is greater, plus reasonable attorney fees up to $300.00. You may instead file a complaint in a small claims court without an attorney.
https://www.michigan.gov/ag/consumer-protection/consumer-ale...
In a technical, ideal sense the PoS is the source of truth. But life is messy.
PoS may lose connectivity. PoS may be running an outdated version of the software. PoS is based on some unreliable operating system or low-end PC, and is unreliable. PoS doesn't know about the store manager's last minute special because the distributor sent too much stock. Stores don't have in-house IT guys.
From a legal standpoint, in some states, the price on the shelf label is the source of truth. My grandmother lived in a state where if the price on the shelf was lower than in the PoS you got the item for free.
She was very good at catching those errors and complained bitterly when the law was changed so that the customer only got the lower price.
I bought six packs of Diet Coke from Target at a discounted price for almost 6 months because they left an old tag up at one particular store. :)
At first they refused to honour the price, and fixed their mistake.
I sent an e-mail with photos to their corporate office. I received a phone call from someone who was laughing and thought it was all funny. He told me to go back to the store, and as much as I could carry, they would honour the posted price.
Cost me like less than a dollar for 4 or 5 kilos of coffee!
I find it interesting that in most writeups voltage injection is a popular appraoch to turning on debug mode. The aricle makes mention to other class of fault injection attack such as clock glitching or electromagnetic fault injection, but are there other approaches that I could look into, just out of curiousity?
On some chips, you can drill into the black encapsulation and find testpads that are not connected to pins on the IC. This is sometimes used for smartphone unlocking.
Edit: Thanks for the compliment by the way, it really made my day that I got someone interested in hardware hacking
Best solution would be to have a transition period where for x hours it’s at the lower price in the system.
That would require completely tracing the PCB out to understand the display drive from the uC and other pin assignments, but... I find that much easier. And then the end result is the potential for a completely understood hardware & software configuration.
Reverse engineering the communication protocol is a lot of work, but only once. After that, you can talk to stock devices, without having to modify their hardware or software.
I also didn't find any datasheets for the e-ink display or how to control it, so here also the stock firmware can come in useful.
Aside from practical concerns, I won't lie, I also took this path because it's fun to do and I could practice hardware hacking.
They note it's end to end encrypted, and if they call home to their cloud and not to local area managed software, I bet they are calling a preset list of IP's to auth and DL data. You'd have to both spoof their IP and sign the data with their key somehow.
1. You need a lot of instructions in sequence to succeed, enough that the chance that all succeed is very very small (recall that there's only about a 5% chance we execute an instruction correctly, if for example there are 10 instructions you need to execute, the chance is 0.05*10). If you write to a wrong location because an instruction didn't execute, you lose a byte of the flash.
2. Before writing to flash, you need to stabilize the clock of the chip (this is also done with 8051 instructions). For this, you need to wait until a register value changes. This is feasible, but an additional hurdle.
0.05^10, surely?
I understand wanting to play it self though.
One thing comes to my mind though: each board likely needs slightly different timings.
