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