Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reverse engineering an e-ink display

zeus.ugent.be

Post reply on HN
Print view View original

41–50 of 56 posts

Re: Reverse engineering an e-ink display

#41

Post by redfast00 »

GianFabien wrote: post #39

I might be missing something. I've seen other reverse engineering projects where they simply unsoldered the flash memory and read out the contents. Wasn't that an option?

This might not have been clear in the blogpost, thanks for asking. There are two storage locations on the PCB: the external flash chip, and the internal flash on the microcontroller. I recall that someone else tried to read out the external flash chip, but nothing interesting was found, only the image data on the screen. In this blog post, I read out the code that handles the RF communication and talks to the screen.

Re: Reverse engineering an e-ink display

#43

Post by redfast00 »

dutch_scrambler wrote: post #30
redfast00 wrote: post #11

Earlier quoted context omitted.

The idea is indeed to communicate with the tags with their stock firmware (not necessarily using another CC2510, since these aren't made anymore, but that's a possibility). 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 p…

Ah, I vaguely remember those old price tags as it's been such a long time. To sniff their RF traffic best use another CC2510 and TI's own packet sniffer app. Their RF protocol is an extension of the default one from TI's application notes for the CC2510 so it's pretty easy to read out. The AES key extraction would be useless, as it's using CBC and a unique per-device IV and NONCE is used, that's random, so if you cra…

Thanks for the information! I think I know who you are, and I understand why you chose to comment with a throwaway handle ;)

Re: Reverse engineering an e-ink display

#44

Post by dcow »

dave78 wrote: post #19
rhd wrote: post #15

Earlier quoted context omitted.

Here's an example in Michigan's law: 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 th…

I think that page backs up what I thought, at least for Michigan. The law views the price displayed on the shelf as being the correct price, and if the POS system doesn't match then the law says the POS system is wrong. Also there's another interesting FAQ there which further reinforces it. Now, if an e-ink display is changed by a hacker, that's obviously fraud and presumably the store wouldn't have to pay up, but I…

So the nuance is:

1) you’re only entitled to damages if the store actually completed the sale and the item rang up higher than listed on the shelf

and

2) the store is not required to honor labeling mistakes and can’t be compelled into a sale in that situation

This is consistent with my experience. So I guess if you’re trying to cheat, you don't tell them and ask them to adjust the price, instead you complete the sale then notify them of the error afterward. My experience has mostly been with notifying the employee beforehand which causes them to correct the labeling mistake if one was made.

Re: Reverse engineering an e-ink display

#45

Post by mk_stjames »

redfast00 wrote: post #40
mk_stjames wrote: post #37

I wonder what the motivation is the attempt to use the stock firmware and reverse engineer whatever communication and potential key signing the device has from the factory, versus just wiping the flash / desoldering and replacing with completely new firmware from scratch. 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 ea…

The person who brought the tags has a lot of them, more than the 3 they donated to Zeus. If we replace the firmware, we have to do this for every device, which would be a lot of manual work (opening case, adding probes, flashing firmware, ...). This is even more work per device if you have to desolder the uC from the PCB and solder something else to it. Reverse engineering the communication protocol is a lot of work,…

Makes sense. I got more interested after finishing reading your whole post and went looking at the manufacturer's website... it would be too easy for them to just provide their software direct for people to download, huh? It looks like a total software-hardware-cloud service lock in... I can't seem to tell but it seems like all tags might have to call back to their cloud to get their displayed info that is managed by their "VUSION Manager". Talk about a nightmare.

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.

Re: Reverse engineering an e-ink display

#46

Post by ezconnect »

layer8 wrote: post #7

It still somehow breaks my intuition that it’s cost-effective to have thousands of these deployed in each supermarket. I mean, I do understand it rationally, but it’s still weird.

Because this devices are sold as savings over a period of time compared to a paper tag system.

Re: Reverse engineering an e-ink display

#47

Post by Our_Benefactors »

soco wrote: post #22
layer8 wrote: post #7

It still somehow breaks my intuition that it’s cost-effective to have thousands of these deployed in each supermarket. I mean, I do understand it rationally, but it’s still weird.

What happens if you see a product with price X and by the time you checkout it has price Y? Can you claim somehow the previous price?

I imagine most stores would not change prices during business hours. For 24-hr stores, just do it at like 3am or something, those handful of customers won’t mind.

Re: Reverse engineering an e-ink display

#48

Post by stavros »

redfast00 wrote: post #35
MayeulC wrote: post #31

How about glitching a write instruction to overwrite the copy protection register instead?

I had also thought about this, but this is much harder to pull off, since 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…

> if for example there are 10 instructions you need to execute, the chance is 0.05*10

0.05^10, surely?

Re: Reverse engineering an e-ink display

#49

Post by redfast00 »

stavros wrote: post #48
redfast00 wrote: post #35

Earlier quoted context omitted.

I had also thought about this, but this is much harder to pull off, since 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…

> if for example there are 10 instructions you need to execute, the chance is 0.05*10 0.05^10, surely?

There should be a double * there, but I think HN removed it

Re: Reverse engineering an e-ink display

#50

Post by smegger001 »

reaperducer wrote: post #16
layer8 wrote: post #7

It still somehow breaks my intuition that it’s cost-effective to have thousands of these deployed in each supermarket. I mean, I do understand it rationally, but it’s still weird.

Supermarkets already have inventory robots (look for the high-contrast markers around the store), and shelf-stocking robots are on the way. It makes sense that the next step is to eliminate another human job and give it to the robots you already have running around the store.

I know walmart trialed inventory robot but killed the program as being impractical, and many stores quit using the automation of their floor cleaners as they would get stuck in random place when cleaning the floors at night because pallets where in their way and they didn't know how to navigate around, they also needed the floor plan updated anytime a new floor display was put in. don't count the humans out yet.
Post reply on HN