redfast00

From the datasheet, I see that there is a Bitscrambler peripheral that seems to be very similar in flexibility to the Raspberry Pi Pico's PIO:

Since bitwise operations can be relatively CPU-intensive and DMA is designed specifically to offload such work from the CPU, ESP32-S31 integrates two dedicated peripherals called BitScramblers. These modules are designed to transform data formats during transfers between memory and peripherals. One BitScrambler handles memory-to-peripheral (or memory-to-memory) transfers, while the other is dedicated to peripheral-to-memory transfers. While BitScramblers can handle the bitwise operations mentioned earlier, they are in fact flexible, programmable state machines capable of performing more advanced transformations as well.

Here's hoping that it's as useful as the Pi Pico's PIO

Author here; see also the entire series of posts on https://esp32-open-mac.be/

In my opinion, the author understates how good AES-GCM-SIV is:

The solution they designed is described in that linked paper: AES-GCM-SIV, which is able to tolerate some number of nonce collisions, but under a weaker notion of security that is only really applicable to that use-case (where the data being encrypted is itself random).

AES-GCM breaks catastrophically if you reuse a nonce; but the only thing that happens if you reuse a nonce with AES-GCM-SIV for two messages is that an attacker can see if the messages are equal (since AES-GCM-SIV is a deterministic algorithm, this is pretty much unavoidable). So yes, "weaker notion of security", but still applicable to a lot more than just that use-case. I wonder why AES-GCM-SIV is not used more, since it's so developer-friendly and misuse resistant.

Please contact me via email (at the bottom of the blog post)

As part of the NLNet grant, I will build an affordable Faraday cage; I'll post the BOM, assembly process and a test report in a separate blog post.

Oops, my bad, copy-pasted it incorrectly; fixed now

You first need to find ground. You can do this by visual inspection (a bit less risky), or by using your multimeter in continuity mode across external metal parts (for example the outside of the USB port)/negative pin of the power supply. Then, you can use a logic analyzer to find the serial TX pin. The RX pin is usually pretty close, and might be pulled up through a resistor to VCC.

This is raw memory, so the concept of malloc/free does not really exist: the OS will just overwrite the data.

I think (not entirely sure) that the kernel gets relocated to a more or less fixed address in memory anyway, this won't affect your runtime experience.

Try to identify a serial port on the PCB, connect a serial adaptor to it (careful to get the pins and voltage right!) and take it from there

(Edit: or google the PCB board markings, maybe somebody already did this)

Mainly by looking at what addresses the original bootloader loads them into. The addresses don't matter too much, as long as you load them into valid memory, since for most you pass a reference to them anyway in later steps.

(author here) We use the device instead of a Raspberry Pi, not for anything too serious: we attached it to a screen and have a small server running with an API where you can write single pixels into the framebuffer (a bit like /r/place)

(author here) this is indeed a Salea clone (one of the first results when searching for 'logic analyzer' on Aliexpress), with pulseview/sigrok as software. I try to use cheap tools if possible, so it's more accessible for other people to reproduce.

author here, surprised to see this on HN. If you have any questions, don't hesitate to ask :)

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

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

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.

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, 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.

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 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.

Voltage injection is (IMO) the easiest attack. There's also optical fault injection, where you remove the black encapsulation from the chip and hit the bare die with a laser (that sounds really difficult though).

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

Thanks for the interest :) If you have an RSS feed reader, you can add our RSS feed, so you'll automatically get the next blog posts https://zeus.ugent.be/feed.xml

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 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.

When I recently visited, I saw that the local IKEA uses these tags, so I'd guess these are rather popular.

There is a policy about this: https://wiki.openstreetmap.org/wiki/Disputed_territories

The author uses an FPGA, which is notoriously hard to program for. In the recent years, microcontrollers have become more and more capable: for example the Raspberry Pi Pico costs about 4 USD and can run at 250MHz and up. Thanks to PIO (programmable IO), which is basically a small programmable state machine running on the IO pins, it's possible to use this for voltage glitching attacks.

Related: a multi-program programmable LED strip (in Lua, allows the led strip to be split up into multiple segments) https://zeus.gent/blog/21-22/ledstrip_sandbox/ with the code on https://github.com/ZeusWPI/ledstrip_sandbox

The DKIM idea will not work: some email servers intentionally publish their expired DKIM keys to avoid people leaking mails (https://blog.cryptographyengineering.com/2020/11/16/ok-googl...)

This is really impressive, streaming video + audio on a what is essentially a beefy microcontroller.

I'd really like a PR if you want to contribute

I reverse engineered a bunch of 'element alchemy games' (games where you combine elements into new elements), extracted the recipes and wrote a tool to interact with them. See https://github.com/redfast00/element-alchemy-cheater

I created a solver for it using Z3, see https://news.ycombinator.com/item?id=19093754.