Software Hacks

958 Articles

Remoticon 2021: Uri Shaked Reverses The ESP32 WiFi

December 30, 2021 by 9 Comments

You know how when you’re working on a project, other side quests pop up left and right? You can choose to handle them briefly and summarily, or you can dive into them as projects in their own right. Well, Uri Shaked is the author of Wokwi, an online Arduino simulator that allows you to test our your code on emulated hardware. (It’s very, very cool.) Back in the day, Arduino meant AVR, and he put in some awesome effort on reverse engineering that chip in order to emulate it successfully. But then “Arduino” means so much more than just AVR these days, so Uri had to tackle the STM32 ARM chips and even the recent RP2040.

Arduino runs on the ESP32, too, so Uri put on his reverse engineering hat (literally) and took aim at that chip as well. But the ESP32 is a ton more complicated than any of these other microcontrollers, being based not only on the slightly niche Xtensa chip, but also having onboard WiFi and its associated binary firmware. Reverse engineering the ESP32’s WiFi is the side-quest that Uri embarks on, totally crushes, and documents for us in this standout Remoticon 2021 talk. Continue reading “Remoticon 2021: Uri Shaked Reverses The ESP32 WiFi” →

Linux Fu: Don’t Share Well With Others

December 28, 2021 by 14 Comments

In kindergarten, you learn that you should share. But for computer security, sharing is often a bad thing. The Linux kernel introduced the concept of namespaces starting with version 2.6.24. That’s been a few years ago, but namespaces are not used by many even though the tools exist to manipulate them. Granted, you don’t always need namespaces, but it is one of those things that when you do need it, the capability is priceless. In a nutshell, namespaces let you give a process its own private resources and — more importantly — prevents a process from seeing resources in other namespaces.

Turns out, you use namespaces all the time because every process you run lives in some set of namespaces. I say set, because there are a number of namespaces for different resources. For example, you can set a different network namespace to give a process its own set of networking items including routing tables, firewall rules, and everything else network-related.

So let’s have a look at how Linux doesn’t share names.

Continue reading “Linux Fu: Don’t Share Well With Others” →

Planning Custom Aluminum Enclosures With OpenSCAD

December 26, 2021 by 20 Comments

We’ve seen a number of projects over the years that let you create custom enclosures using OpenSCAD, and for good reason. The parametric CAD tool is ideal for generating 3D models based on user-adjustable variables, and if you leverage its integrated Customizer, producing a bespoke box is as easy as moving some sliders around. The resulting files get sent off to the 3D printer, and you’re set. But what if you’re looking for a custom enclosure that’s not so…plastic?

In that case, AlClosure by [0xPIT] might be the answer. Rather than generating STL files intended for your 3D printer, the code is written to help you design an enclosure made from aluminum sheets. The top and bottom panels are intended to be cut from 1.5 mm – 2.5 mm sheets, while the sides are made from thicker 5 mm – 8 mm stock to accept a machined pocket that holds the front and rear inserts.

Since it’s OpenSCAD, much of the design is governed by variables which you can tweak. Obviously the outside dimensions of the enclosure can be changed in a flash, but it’s just as easy to modify the thickness of the aluminum sheet being used, or the size of the screw holes. [0xPIT] has also done a great job of documenting the code itself, so you’ll know exactly what you’re modifying.

Obviously, you’ll need the ability to cut and machine aluminum to actually utilize this project. The code itself is really just a way to conceptualize the design and get your dimensions figured out ahead of time. But as we were recently reminded by the keynote presentation [Jeremy Fielding] gave at the 2021 Remoticon, this sort of early prototyping can often save you a lot of headaches down the line.

Lisp In 436 Bytes

December 23, 2021 by 26 Comments

You would assume that any programming language available back in the 1960s would be small enough to easily implement on today’s computers. That’s not always true though, since old languages sometimes used multiple passes. But in some cases, you can implement what would have been a full language decades ago in a tiny footprint. A case in point is a pretty good implementation of Lisp — including garbage collection — in 436 bytes.

SectorLISP claims to be the tiniest real language, beaten only by toy languages that are not really very useful. If you want to, you can try it in your browser, but that version has better error messages and persistent bindings, so it hogs up a whole 509 bytes.

Continue reading “Lisp In 436 Bytes” →

Building MS-DOS From Scratch Like It’s 1983

December 20, 2021 by 52 Comments

Building a complete operating system by compiling its source code is not something for the faint-hearted; a modern Linux or BSD distribution contains thousands of packages with millions of lines of code, all of which need to be processed in the right order and the result stored in the proper place. For all but the most hardcore Gentoo devotees, it’s way easier to get pre-compiled binaries, but obviously someone must have run the entire compilation process at some point.

What’s true for modern OSes also holds for ancient software such as MS-DOS. When Microsoft released the source code for several DOS versions a couple of years ago, many people pored over the code to look for weird comments and undocumented features, but few actually tried to compile the whole package. But [Michal Necasek] over at the OS/2 Museum didn’t shy away from that challenge, and documented the entirely-not-straightforward process of compiling DOS 2.11 from source.

The first problem was figuring out which version had been made available: although the Computer History Museum labelled the package simply as “MS-DOS 2.0”, it actually contained a mix of OEM binaries from version 2.0, source code from version 2.11 and some other stuff left from the development process. The OEM binaries are mostly finished executables, but also contain basic source code for some system components, allowing computer manufacturers to tailor those components to their specific hardware platform.

Compiling the source code was not trivial either. [Michal] was determined to use period-correct tools and examined the behaviour of about a dozen versions of MASM, the assembler likely to have been used by Microsoft in the early 1980s. As it turned out, version 1.25 from 1983 produced code that most closely matched the object code found in existing binaries, and even then some pieces of source code required slight modifications to build correctly. [Michal]’s blog post also goes into extensive detail on the subtle differences between Microsoft-style and IBM-style DOS, which go deeper than just the names of system files (MSDOS.SYS versus IBMDOS.COM).

The end result of this exercise is a modified DOS 2.11 source package that actually compiles to a working set of binaries, unlike the original. And although this does not generate any new code, since binaries of DOS 2.11 have long been available, it does provide a fascinating look into software development practices in an age when even the basic components of the PC platform were not fully standardized. And don’t forget that even today some people still like to develop new DOS software.

SDR Toolkit Bends Weather Station To Hacker’s Whims

December 17, 2021 by 9 Comments

We probably don’t have to tell most Hackaday readers why the current wave of low-cost software defined radios (SDRs) are such a big deal for hackers looking to explore the wide world of wireless signals. But if you do need a refresher as to what kind of SDR hardware and software should be in your bag of tricks, then this fantastically detailed account from [RK] about how he hacked his La Crosse WS-9611U-IT weather station is a perfect example.

Looking to brush up his radio hacking skills, [RK] set out to use the ADALM-PLUTO software defined radio from Analog Devices to intercept signals between the La Crosse base station and its assorted wireless sensors. He notes that a $20 USD RTL-SDR dongle could do just as well if you only wanted to receive, but since his ultimate goal was to spoof a temperature sensor and introduce spurious data into the system, he needed an SDR that had transmit capabilities.

No matter your hardware, Universal Radio Hacker (URH) is the software that’s going to be doing the heavy lifting. In his write-up, [RK] walks the reader through every step required to find, capture, and eventually decode the transmissions coming from a TX29U wireless temperature sensor. While the specifics will naturally change a bit depending on the device you’re personally looking to listen in on, the general workflow is going to be more or less the same.

In the end, [RK] is not only able to receive the data coming from the wireless sensors, but he can transmit his own spoofed data that the weather station accepts as legitimate. Getting there took some extra effort, as he had to figure out the proper CRC algorithm being used. But as luck would have it, he found a Hackaday article from a couple years back that talked about doing exactly that, which help put him on the right path. Now he can make the little animated guy on the weather station’s screen don a winter coat in the middle of July. Check out the video below for a demonstration of this particular piece of radio prestidigitation.

Continue reading “SDR Toolkit Bends Weather Station To Hacker’s Whims” →

The Second Worst CAD Package Ever

December 17, 2021 by 28 Comments

A while back, [Heavydeck] remembered stumbling across the worst CAD package ever, which is a schematic editor whose existence was purely intended for use to make quick circuit sketches for documentation, presentations and the like. All good. But, being based on low quality JPEG graphics, which when blown up to projector size on a big screen, they look really rough. After deciding that the original nasty, clunky interface was just nasty and clunky enough, [Heavydeck] then proceeded to reimplement the idea over the course of an afternoon, and came up with Kludge (possibly the second worst CAD package ever) making an actually useful tool even more useful.

You see, whether you make website content, YouTube tutorials, or just need to write technical reports, if you’re in the electronics business, you’re going to need to make high-quality editable schematic images at some point, and Kludge might well solve some problems for you. Kludge lets you do so many things; you can save a schematic, you can load a schematic, you can even export it to an SVG file. Actually, that’s all you can do, but it is actually just enough. Once you’ve got an image as an SVG, you can whack that into Inkscape to add some more details and you’re done. We demonstrate this with the image above, which was not annoying at all to create.

So here’s to Kludging your way around a problem, and hoping that the somewhat limited symbol library may expand a little more in the future!