Be Wary Of Flash-less ESP32-C3 Super Mini Boards

Everyone loves tiny microcontroller boards, and the ESP32-C3 Super Mini boards are no exception. Unfortunately if you just casually stroll over to your nearest online purveyor of such goods to purchase a bunch of them, you’re likely to be disappointed. The reason for this is, as explained in a video by [Hacker University] that these boards are equipped with any of the variants of the ESP32-C3. The worst offender here is probably the version with the ESP32-C3 without further markings, as this one has no built-in Flash for program storage.

Beyond that basic MCU version we can see the other versions clearly listed in the Espressif ESP32-C3 datasheet. Of these, the FN4 is already listed as EOL, the FH4AZ as NRND, leaving only the FH4 and FH4X with the latter as ‘recommended’ as the newest chip revision. Here the F stands for  built-in Flash with the next character for its temperature rating, e.g. H for ‘High’. Next is the amount of Flash in MB, so always 4 MB for all but the Flash-less variant.

Identifying this information from some online listing is anything but easy unless the seller is especially forthcoming. The chip markings show this information on the third row, as can be seen in the top image, but relying solely on a listing’s photos is rather sketchy. If you do end up with a Flash-less variant, you can still wire up an external Flash chip yourself, but obviously this is probably not the intended use case.

As always, caveat emptor.

Continue reading “Be Wary Of Flash-less ESP32-C3 Super Mini Boards”

The Nokia N900 Updated For 2025

Can a long-obsolete Linux phone from 2009 be of use in 2025? [Yaky] has a Nokia N900, and is giving it a go.

Back in the 2000s, Nokia owned the mobile phone space. They had a smartphone OS, even if they didn’t understand app distribution, they had the best cameras, screens, antennas, the lot. They threw it all away with inept management that made late-stage Commodore look competent. Apple and Android came along, and now a Nokia is a rarity. Out of this mess came one good thing, though: the N900 was a Linux-based smartphone that became the go-to hacker mobile for a few years.

First up with this N900 is the long-dead battery. He makes a fake battery with a set of supercapacitors and resistors to simulate the temperature sensor, and is then able to power it from an external PSU. This is refined to a better fake battery using the connector from the original. The device also receives a USB-C port, though due to space constraints, not the PD identifiers, making it (almost) modern.

Because it was a popular hacker device, it’s possible to upgrade the software on an N900. He’s given it U-Boot, and now it boots Linux from an SD card and functions as an online radio device.

That’s impressive hackability and longevity for a phone, if only we could have more like it.

Libxml2 Narrowly Avoids Becoming Unmaintained

In an excellent example of one of the most overused XKCD images, the libxml2 library has for a little while lost its only maintainer, with [Nick Wellnhofer] making good on his plan to step down by the end of the year.

XKCD's dependency model
Modern-day infrastructure, as visualized by XKCD. (Credit: Randall Munroe)

While this might not sound like a big deal, the real scope of this problem is rather profound. Not only is libxml2 part of GNOME, it’s also used as dependency by a huge number of projects, including web browsers and just about anything that processes XML or XSLT. Not having a maintainer in the event that a fresh, high-risk CVE pops up would obviously be less than desirable.

As for why [Nick] stepped down, it’s a long story. It starts in the early 2000s when the original author [Daniel Veillard] decided he no longer had time for the project and left [Nick] in charge. It should be said here that both of them worked as volunteers on the project, for no financial compensation. This when large companies began to use projects like libxml2 in their software, and were happy to send bug reports. Beyond a single Google donation it was effectively unpaid work that required a lot of time spent on researching and processing potential security flaws sent in.

Of note is that when such a security report comes in, the expectation is that you as a volunteer software developer drop everything you’re working on and figure out the cause, fix and patched-by-date alongside filing a CVE. This rather than you getting sent a merge request or similar with an accompanying test case. Obviously these kind of cases seems to have played a major role in making [Nick] burn out on maintaining both libxml2 and libxslt.

Fortunately for the project two new developers have stepped up to take over as maintainers, but it should be obvious that such churn is not a good sign. It also highlights the central problem with the conflicting expectations of open source software being both totally free in a monetary fashion and unburdened with critical bugs. This is unfortunately an issue that doesn’t seem to have an easy solution, with e.g. software bounties resulting in mostly a headache.

Hackaday Links Column Banner

Hackaday Links: December 21, 2025

It’s amazing how fragile our digital lives can be, and how quickly they can fall to pieces. Case in point: the digital dilemma that Paris Buttfield-Addison found himself in last week, which denied him access to 20 years of photographs, messages, documents, and general access to the Apple ecosystem. According to Paris, the whole thing started when he tried to redeem a $500 Apple gift card in exchange for 6 TB of iCloud storage. The gift card purchase didn’t go through, and shortly thereafter, the account was locked, effectively bricking his $30,000 collection of iGadgets and rendering his massive trove of iCloud data inaccessible. Decades of loyalty to the Apple ecosystem, gone in a heartbeat.

Continue reading “Hackaday Links: December 21, 2025”

A browser window is shown, in which a web page is displaying a green trace of a square wave.

A Compact, Browser-Based ESP32 Oscilloscope

An oscilloscope is usually the most sensitive, and arguably most versatile, tool on a hacker’s workbench, often taking billions of samples per second to produce an accurate and informative representation of a signal. This vast processing power, however, often goes well beyond the needs of the signals in question, at which point it makes sense to use a less powerful and expensive device, such as [MatAtBread]’s ESP32 oscilloscope.

Continue reading “A Compact, Browser-Based ESP32 Oscilloscope”

Testing 8 Solder Flux Pastes After Flux Killed A GeForce2 GTS

Riesba NC-559-ASM flux being applied. (Credit: Bits und Bolts, YouTube)
Riesba NC-559-ASM flux being applied. (Credit: Bits und Bolts, YouTube)

Flux is one of those things that you cannot really use too much of during soldering, as it is essential for cleaning the surface and keeping oxygen out, but as [Bits und Bolts] recently found, not all flux is made the same. After ordering the same fake Amtech flux from the same AliExpress store, he found that the latest batch didn’t work quite the same, resulting in a Geforce 2 GTS chip getting cooked while trying to reball the chip with uncooperative flux.

Although it’s easy to put this down to a ‘skill issue’, the subsequent test of eight different flux pastes ordered from both AliExpress and Amazon, including — presumably genuine — Mechanic flux pastes with reballing a section of a BGA chip, showed quite different flux characteristics, as you can see in the video below. Although all of these are fairly tacky flux pastes, with some, the solder balls snapped easily into place and gained a nice sheen afterwards, while others formed bridges and left a pockmarked surface that’s indicative of oxygen getting past the flux barrier.

Not all flux pastes are made the same, which also translates into how easy the flux remnants are to clean up. So-called ‘no clean’ flux pastes are popular, which take little more than some IPA to do the cleaning, rather than specialized PCB cleaners as with the used Mechanic flux. Although the results of these findings are up for debate, it can probably be said that ordering clearly faked brand flux paste is a terrible idea. While the top runner brand Riesba probably doesn’t ring any bells, it might be just a Chinese brand name that doesn’t have a Western presence.

As always, caveat emptor, and be sure to read those product datasheets. If your flux product doesn’t come with a datasheet, that would be your first major red flag. Why do we need flux? Find out.

Continue reading “Testing 8 Solder Flux Pastes After Flux Killed A GeForce2 GTS”

Using GIMP for visual analysis

Decapsulating A PIC12F683 To Examine Its CMOS Implementation

In a recent video, [Andrew Zonenberg] takes us through the process of decapsulating a PIC12F683 to take a peek at its CMOS implementation.

This is a multipart series with five parts done and more to come. The PIC12F683 is an 8-pin flash-based, 8-bit microcontroller from Microchip. [Andrew] picked the PIC12F683 for decapsulation because back in 2011 it was the first microcontroller he broke read-protection on and he wanted to go back and revisit this chip, given particularly that his resources and skills had advanced in the intervening period.

The five videos are a tour de force. He begins by taking a package cross section, then decapsulating and delayering. He collects high-resolution photos as he goes along. In the process, he takes some time to explain the dangers of working with acid and the risk mitigations he has in place. Then he does what he calls a “floorplan analysis” which takes stock of the entire chip before taking a close look at the SRAM implementation.

If you’re interested in decapsulating integrated circuits you might want to take a look at Laser Fault Injection, Now With Optional Decapping, A Particularly Festive Chip Decapping, or even read through the transcript of the Decapping Components Hack Chat With John McMaster.

Continue reading “Decapsulating A PIC12F683 To Examine Its CMOS Implementation”