A Browser Approach To Parsing

June 26, 2023 by Al Williams 3 Comments

There are few rites of programmer passage as iconic as writing your first parser. You might want to interpret or compile a scripting language, or you might want to accept natural-language-like commands. You need a parser. [Varunramesh] wants to show you parser combinators, a technique used to make practical parsers. But the demonstration using interactive code cells in the web page is nearly as interesting as the technique.

Historically, you parse tokens, and this technique can do that too, but it can also operate directly on character streams if you prefer. The idea is related to recursive descent parsing, where you attempt to parse certain things, and if those things fail, you try again.

Continue reading “A Browser Approach To Parsing” →

Exploring The Anatomy Of A Linux Kernel Exploit

June 25, 2023 by Bryan Cockfield 21 Comments

A lot of talk and discussion happens anytime a hardware manufacturer releases a new line of faster, more powerful, or more efficient computers. It’s easy to see better and better specifications and assume that’s where all the progress is made. But without improved software and algorithms, often the full potential of the hardware can’t be realized. That’s the reason for the creation of io_uring, an improved system call interface in the Linux kernel. It’s also where [chompie] went to look for exploits.

The reason for looking here, in a part of the kernel [chompie] had only recently learned about, was twofold. First, because it’s a place where user space applications interact with the kernel, and second because it’s relatively new and that means more opportunities to find bugs. The exploit involves taking advantage of a complicated asynchronous buffer system, specifically at a location where the code confuses a memory location being used by the kernel with one which is supposed to be used for user space.

To actually get this to work as an exploit, though, a much more involved process is needed to make sure the manipulation of these memory addresses results in something actually useful, but it is eventually used to gain local privilege escalation. More about it can be found in this bug report as well. Thanks to the fact that Linux is open-source, this bug can quickly be fixed and the patch rolled out to prevent malicious attackers from exploiting it. Open-source software has plenty of other benefits besides being inherently more secure, though.

A 32-Bit RISC-V CPU Core In 600 Lines Of C

June 24, 2023 by Donald Papp 29 Comments

If you have ever wanted to implement a RISC-V CPU core in about 600 lines of C, you’re in luck! [mnurzia]’s rv project does exactly that, providing a simple two-function API.

Technically, it’s a user-level RV32IMC implementation in ANSI C. There are many different possible flavors of RISC-V, and in this case is a 32-bit base integer instruction set (RV32I), with multiplication and division extension (M), and compressed instruction set extension (C).

There’s a full instruction list and examples of use on the GitHub repository. As for readers wondering what something like RISC-V emulation might be good for, it happens to be the not-so-secret sauce to running Linux on an RP2040.

Robodog Goes Free Thanks To Unofficial SDK

June 24, 2023 by Donald Papp 8 Comments

What’s better than a pretty nice legged robot? One with an alternate SDK version that opens up expensive features, of course. The author didn’t like that the original SDK only came as pre-compiled binaries restricted to the most expensive models, so rolled up their sleeves and started writing a new one.

The manufacturer’s SDK limits access to programmatic functions, but that needn’t stop *you*.

There are a number of commercially-available robotic quadrupeds that can trace their heritage back to the MIT Mini Cheetah design, and one of them is the Unitree Go1 series which sports a distinctive X-shaped sensor cluster on its “face”. The basic models are affordable (as far as robots go, anyway) but Unitree claims only the high-priced EDU model can be controlled via the SDK. Happily, the Free Dog SDK provides a way to do exactly that.

The SDK is a work in progress, but fully usable and allows the user to send various high level and low level commands to the Go1 robots. High level examples include things like telling the robot to perform pushups, turn 90 degrees, or walk. Low level commands are things like specifying exact positions or torque levels for individual limbs. With the new SDK, doing those things programmatically is only a Python script away.

Know any other robots that might be based on the same system? This SDK might work on them, too.

An Open Source Firmware For Cheap Geiger Counters

June 24, 2023 by Al Williams 11 Comments

It is a time-honored tradition: buy some cheap piece of gear and rewrite the firmware to make it work better. [Gissio] managed to do just that for a cheap FS2011 Geiger counter. Apparently, the firmware will also work with some similar Chinese models, too.

The new firmware boasts an improved UI and multiple measurement units, including Sievert, Rem, and counts per minute or second. You can hold the measurement or compute a dose or average rate. The new firmware also has a host of customizations and can accommodate different tubes.

There are, however, two really key features. First, the new firmware offers about 40% more battery life than the stock version. Second, there is now an onboard nuclear chess game! That way, you can enjoy yourself while you are getting irradiated. There are also a few suggested hardware mods that are optional to improve measurements and increase the buzzer volume, among other things.

If you get a Geiger counter, you might be surprised at what things are slightly radioactive. If you don’t need the microcontroller, you can make a workable counter on the cheap.

Continue reading “An Open Source Firmware For Cheap Geiger Counters” →

A Simple Guide To Bit Banged I2C On The 6502

June 18, 2023 by Dave Rowntree 5 Comments

We covered [Anders Nielsen]’s 65duino project a short while ago, and now he’s back with an update video showing some more details of bit-banging I²C using plain old 6502 assembly language.

Obviously, with such a simple system, there is no dedicated I²C interface hardware, so the programmer must take care of all the details of the I²C protocol in software, bit-banging it out to the peripheral and reading back the response one bit at a time.

The first detail to concern us will be the I²C addresses of the devices being connected to the bus and how low-level bit manipulation is used to turn the 7-bit I²C address into the byte being bit-banged. As [Anders] shows, setting a bit is simply a logical-OR operation, and resetting a bit is a simple logical-AND operation using the inversion (or one’s complement) bit to reset to form a bitmask. As many will already know, this process is necessary to code for a read or a write I²C operation. A further detail is that I²C uses an open-collector connection scheme, which means that no device on the bus may drive the bus to logical high; instead, they must release the drive by going to the high impedance state, and an external pull-up resistor will pull the bus high. The 6532 RIOT chip (used for I/O on the 65unio) does not have tristate control but instead uses a data direction register (DDR) to allow a pin to be an input. This will do the job just fine, albeit with slightly odd-looking code, until you know what’s going on.

From there, it’s a straightforward matter to write subroutines that generate the I²C start, stop, and NACK conditions that are required to write to the SSD1306-based OLED to get it to do something we can observe. From these basic roots, through higher-level subroutines, a complete OLED library in assembly can be constructed. We shall sit tight and await where [Anders] goes next with this!

We see I²C-connected things all the time, like this neat ATtiny85-based I²C peripheral, and whilst we’re talking about the SSD1306 OLED display controller, here’s a hack that shows just how much you can push your luck with the I²C spec and get some crazy frame rates.

Continue reading “A Simple Guide To Bit Banged I2C On The 6502” →

Learning X86_64 Assembly By Building A GUI From Scratch

June 18, 2023 by Dave Rowntree 34 Comments

Some professional coders are absolutely adamant that learning to program in assembly language in these modern times is simply a waste of time, and this post is not for them. This is for the rest of us, who still think there is value in knowing at a low level what is going on, a deeper appreciation can be developed. [Philippe Gaultier] was certainly in this latter camp and figured the best way to learn was to work on a substantial project.

Now, there are some valid reasons to write directly in assembler; for example hand-crafting unusual code sequences for creating software exploits would be hindered by an optimising compiler. Creating code optimised for speed and size is unlikely to be among those reasons, as doing a better job than a modern compiler would be a considerable challenge. Some folks would follow the tried and trusted route and work towards getting a “hello world!” output to the console or a serial port, but not [Philippe]. This project aimed to get a full-custom GUI application running as a client to the X11 server running atop Linux, but the theory should be good for any *nix OS.

The first part of the process was to create a valid ELF executable that Linux would work with. Using nasm to assemble and the standard linker, only a few X86_64 instructions are needed to create a tiny executable that just exits cleanly. Next, we learn how to manipulate the stack in order to set up a non-trivial system call that sends some text to the system STDOUT.

To perform any GUI actions, we must remember that X11 is a network-orientated system, where our executable will be a client connected via a socket. In the simple case, we just connect the locally created socket to the server path for the local X server, which is just a matter of populating the sockaddr_un data structure on the stack and calling the connect() system call.

Now the connection is made, we can follow the usual X11 route of creating client ids, then allocating resources using them. Next, fonts are opened, and a graphical context is created to use it to create a window. Finally, after mapping the window, something will be visible to draw into with subsequent commands. X11 is a low-level GUI system, so there are quite a few steps to create even the most simple drawable object, but this also makes it quite simple to understand and thus quite suited to such a project.

We applaud [Phillip] for the fabulous documentation of this learning hack and can’t wait to see what’s next in store!

Not too long ago, we covered Snowdrop OS, which is written entirely in X86 assembly, and we also found out a thing or two about some oddball X86 instructions. We’ve also done our own Linux assembly primer.