Andrew Zonenberg

Security and open source at the hardware/software interface. Embedded sec @ IOActive. Lead dev of ngscopeclient/libscopehal. GHz probe designer. Open source networking hardware. "So others may live"

Toots searchable on tootfinder.

ngscopeclient: https://www.ngscopeclient.org/
Blog: https://serd.es
Location: Seattle area
GitHub: https://github.com/azonenberg

Public Key

npub1wpgh8qdt8suzxy8f2luspksj4wpdfw53weq4v8dr7llqp3t72tds3rf386

NIP-05 Address

azonenberg_at_ioc.exchange@momostr.pink

Profile Code

nprofile1qqs8q5tnsx4ncwprzr5407gqmgf2hqk5h2ghvs2krk3l0lsqc4l99kcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds306xct

Publishing to

offchain.pub

nos.lol

relay.damus.io

Author Public Key

npub1wpgh8qdt8suzxy8f2luspksj4wpdfw53weq4v8dr7llqp3t72tds3rf386

Show more details

Last Notes

2025-07-10 05:44:11 UTC

Starting to look more seriously into the STM32H750/753.
The 753 is the part I really want to use, the 750 is the same die fused down to disable all but the first 128 kB of flash. But I picked up several of them during the chip shorage and I feel like I should put them to use.
They're mostly comparable to the H735 I use now. Key differences:
* CPU Fmax down from 550 to 480 MHz
* RAM nearly doubled from 564 to 1024 kB
* Flash increased from 1 MB to 2 MB in the 753, but reduced to 128 kB in the 750
* 40 more GPIOs (128 -> 168)
* Package enlarged from 201 ball 0.65mm (10x10 mm) to 265 ball 0.8mm (14x14 mm).
That last bit is what has me the most interested. The 0.65mm H735 package is usable on OSHPark 4L, barely, but you lose a lot of IO and the parallel memory controller etc. aren't practical to use.
While the H75x is available in the same footprint, you can also get it in the 0.8mm package which should be much more friendly to the large via sizes offered on OSHPark. So it could be a winner for prototypes where I care more about ease of access to IO and MCU-FPGA interfacing than about absolute max CPU performance.

2025-06-19 18:51:33 UTC

- reply

so yes, if and when wayland achieves feature parity with X i might switch.
But right now they seem to be explicitly saying "we will not implement these features". There are multiple tools I use that are either going to be impossible to port to wayland or will require major backend rewrites (e.g. getting multiple top level windows with docking working in Dear ImGui) due to lack of absolute positioning information.

2025-05-29 02:05:10 UTC

Thinking about switching my supervisor MCUs to use i2c instead of spi for interfacing to the main CPU.
Rationale: uses two less pins, can be combined with sensors and other system health stuff on 3v3_sb power domain, simpler code with no hard realtime constraints since you can clock stretch if the other side isn't ready, and it doesn't need to be fast at all.

2025-02-26 15:12:31 UTC

- reply

You can completely sidestep DMCA issues if you replace the OEM ECUs entirely rather than messing with their firmware.
I'm talking about physically removing e.g. the BCM and engine controller and replacing them with from-scratch new ones designed to exceed the OEM safety and efficiency standards.

2025-02-26 14:54:21 UTC

- reply

If this happens, I might finally get the open-source backing and funding I need for my dream of having a "car neutering" service available.
Pick a popular recent model vehicle with decent mechanical/structural design and offer a complete revamp with new ECUs and consoles that are drop-in replacements for the OEM ones.
In rough order of priority (factoring both importance to safety/usability and complexity of implementation):
1) Remove every radio transmitter, cell modem, telematics phone-home feature, etc
2) Replace all touch screens with physical knobs and buttons
3) Remove every "self driving" / "driver assistance" feature or, at absolute minimum, add a big red e-stop button that physically powers down all ECUs and sensors providing such antifeatures and reverts to full manual control
4) Replace all ECUs responsible for safety-critical functionality like throttle control and ABS with new ones built with memory-safe firmware, triple modular redundant processors with ECC RAM, and (ideally, although this would be more invasive in terms of required modifications to the vehicle) redundant sensors and actuators so that failure of say a single pedal position sensor won't lead to a loss of control.
I think the implementation I'd trust most for life-safety software, with current technology, is probably an FPGA based platform compiled with open tools and end to end LVS from bitstream to RTL, running three copies of a riscv-formal validated CPU core with a majority voter on the outputs and SEU scrubbing on the configuration memory. The technology to build this either exists today or is close to available, although at the cost of performance vs more mainstream solutions.
Formal verification of the software control loops would be great too. Anybody know what the state of the art in formal correctness tools for Rust code (in terms of algorithmic bugs rather than the safety properties checked by the compiler and runtime) is like?

2025-01-14 15:06:49 UTC

- reply

More details:
Blog post https://ioactive.com/raspberry-pi-2350-hacking-challenge/
Full writeup: https://info.ioactive.com/acton/attachment/34793/f-e5160595-f1ec-4e2f-b650-ba856656db09/1/-/-/-/-/IOActive-RP2350HackingChallenge.pdf
I'm also going to be keynoting the HARRIS 2025 Hardware Reverse Engineering Workup at the Max Planck Institute for Security & Privacy in March
https://harris2025.mpi-sp.org/keynotes/

2024-12-27 21:15:47 UTC

- reply

Fair enough.
I normally work on designs where I spend a month or more of spare time on schematic and layout, put several hundred dollars at *least* of parts on it, then months on firmware.
The board needs to just work, so I'm going to do everything I possibly can to tip the odds in my favor and minimize the chance of needing a respin because of something stupid.

2024-12-23 23:42:16 UTC

Really wishing STM32H7 (and Cortex-M7 in general) had better performance counters.
I would love to be able to see how many cycles the CPU was stalled waiting on an AXI transaction, what percentage of instruction fetches were served by L1$ vs ITCM vs requiring an AXI request, etc.

2024-12-23 22:40:25 UTC

- reply

I have no idea what they did to these DRAMs but this ball is more void than solder.
https://files.ioc.exchange/media_attachments/files/113/704/541/413/270/086/original/6447c75dd55db814.jpeg

2024-12-23 22:35:09 UTC

Dye-and-pry found an actual defect! I have a toddler sitting on my lap so it was tricky to get the focus right, sorry if it's a bit off.
But here's one of the DRAMs on the board I did with the JLCPCB stencil. Big bubble void in the solder ball that reached all the way to the surface of the ball and let dye in.
https://files.ioc.exchange/media_attachments/files/113/704/516/385/556/145/original/889de4e3954cc913.jpeg
https://files.ioc.exchange/media_attachments/files/113/704/517/914/604/892/original/01a477f123ef0aeb.jpeg

2024-12-23 22:29:03 UTC

With some tweaks to I/O timing on the FPGA, I managed to boost the MCU - FPGA bus clock (also used as the APB PCLK on the FPGA) from 137.5 to 150 MHz.
This boosts iperf performance from 528 to 576 Mbps.
Interestingly, /dev/zero performance is down to 23.9 MB/s (this is likely related to cache line alignment or something, I'll investigate more to see what else I can fine tune).
QSPI flash dumping is now running at 75 MHz SCK (150 MHz/2) and getting 12.8 MB/s (102.4 Mbps) of throughput.
Not bad: I've broken the 100 Mbps barrier with *actual application layer data* (so the actual line rate is higher allowing for SSH + TCP + Ethernet protocol overhead) on a chip that isn't even supposed to be able to do 100mbit Ethernet.

2024-12-23 21:20:10 UTC

- reply

Sooo pushing more and more offload to FPGA is certainly a plausible end game. It's just a lot of work and I'm trying to spend my time where it'll have the most impact.

2024-12-23 19:38:05 UTC

Look ma, no DMA!
Realized that the STM32H7 crypto core actually has two blocks worth of FIFO allowing me to pipeline data, reading/writing while the crypto block is also doing its thing.
This boosts /dev/zero SFTP performance to 22.5 MB/s (180 Mbps) and QSPI flash readback to 11.6 MB/s (92.8 Mbps).

2024-12-17 05:17:24 UTC

- reply

I can't find the version I put the text on but:
REVERSE ENGINEERING
We can do this the easy way, or the hard way.
But your protocol is getting documented.
https://files.ioc.exchange/media_attachments/files/113/666/461/678/715/654/original/e85b7d63eb6422dc.jpeg

2024-12-17 05:11:42 UTC

- reply

Any ROM can be dumped. Some are just more work than others, but everybody talks in the end.
If I want your ROM, I'm going to get it (And if you know anything about what I do at work, you'll know this is not an exaggeration)

2024-08-22 19:10:53 UTC

- reply

No, none of my hardware supports it so I've only skimmed documentation.

2024-08-22 18:53:43 UTC

- reply

I'm simplifying a bit :)
And USB3 is PCIe at the physical layer, but not the upper layers. USB4 is the obvious next step in further convergent evolution.

2024-08-22 18:51:50 UTC

Hypothesis: all short to medium range local buses will eventually converge to become PCIe, Ethernet, or both.
* [S]ATA? Being replaced by NVMe over PCIe
* CAN bus in cars? Being replaced by single pair Ethernet
* USB4 is basically Thunderbolt which is basically PCIe
* Lots of industrial RS485 etc field buses are being replaced with Ethernet
I suspect we're not too far from seeing a new PC monitor interface standard that encapsulates video inside Ethernet frames or PCIe TLPs the way this is headed.
The unification of PCIe and Ethernet is probably further off but isn't entirely implausible.

2024-07-20 21:15:14 UTC

- reply

I remember running password crackers on the PS3.
It was tricky even coming from a GPU background, the SPEs were an interesting animal for sure. Easy to make a small screwup and get bad performance.