A Literate Assembly Language

May 8, 2023 by Al Williams 80 Comments

A recent edition of [Babbage’s] The Chip Letter discusses the obscurity of assembly language. He points out, and I think correctly, that assembly language is more often read than written, yet nearly all of them are hampered by obscurity left over from the days when punched cards had 80 columns and a six-letter symbol was all you could manage in the limited memory space of the computer. For example, without looking it up, what does the ARM instruction FJCVTZS do? The instruction’s full name is Floating-point Javascript Convert to Signed Fixed-point Rounding Towards Zero. Not super helpful.

But it did occur to me that nothing is stopping you from writing a literate assembler that is made to be easier to read. First, most C compilers will accept some sort of asm statement, and you could probably manage that with compile-time string construction and macros. However, I think there is a better possibility.

Reuse, Recycle

Since I sometimes develop new CPU architectures, I have a universal cross assembler that is, honestly, an ugly hack, but it works quite well. I’ve talked about it before, but if you don’t want to read the whole post about it, it uses some simple tricks to convert standard-looking assembly language formats into C code that is then compiled. Executing the resulting program outputs the desired machine language into a desired file format. It is very easy to set up, and in the middle, there’s a nice C program that emits machine code. It is not much more readable than the raw assembly, but you shouldn’t have to see it. But what if we started the process there and made the format readable?

At the heart of the system is a C program that lives in soloasm.c. It handles command line options and output file generation. It calls an external function, genasm with a single integer argument. When that argument is set to 1, it indicates the assembler is in its first pass, and you only need to fill in label values with real numbers. If the pass is a 2, it means actually fill in the array that holds the code.

That array is defined in the __solo_info instruction (soloasm.h). It includes the size of the memory, a pointer to the code, the processor’s word size, the beginning and end addresses, and an error flag. Normally, the system converts your assembly language input into a bunch of function calls it writes inside the genasm function. But in this case, I want to reuse soloasm.c to create a literate assembly language. Continue reading “A Literate Assembly Language” →

Ask Hackaday: Why Do Self Driving Cars Keep Causing Traffic Jams?

May 8, 2023 by Lewin Day 133 Comments

Despite what some people might tell you, self-driving cars aren’t really on the market yet. Instead, there’s a small handful of startups and big tech companies that are rapidly developing prototypes of this technology. These vehicles are furiously testing in various cities around the world.

In fact, depending on where you live, you might have noticed them out and about. Not least because many of them keep causing traffic jams, much to the frustration of their fellow road users. Let’s dive in and look at what’s going wrong.

Continue reading “Ask Hackaday: Why Do Self Driving Cars Keep Causing Traffic Jams?” →

Hackaday Links: May 7, 2023

May 7, 2023 by Dan Maloney 39 Comments

More fallout for SpaceX this week after their Starship launch attempt, but of the legal kind rather than concrete and rebar. A handful of environmental groups filed the suit, alleging that the launch generated “intense heat, noise, and light that adversely affects surrounding habitat areas and communities, which included designated critical habitat for federally protected species as well as National Wildlife Refuge and State Park lands,” in addition to “scatter[ing] debris and ash over a large area.”

Specifics of this energetic launch aside, we always wondered about the choice of Boca Chica for a launch facility. Yes, it has all the obvious advantages, like a large body of water directly to the east and being at a relatively low latitude. But the whole area is a wildlife sanctuary, and from what we understand there are still people living pretty close to the launch facility. Then again, you could pretty much say the same thing about the Cape Canaveral and Cape Kennedy complex, which probably couldn’t be built today. Amazing how a Space Race will grease the wheels of progress.

Continue reading “Hackaday Links: May 7, 2023” →

The New Hotness

May 6, 2023 by Elliot Williams 35 Comments

If there’s one good thing to be said about the chip shortage of 2020-2023 (and counting!) it’s that a number of us were forced out of our ruts, and pushed to explore parts that we never would have otherwise. Or maybe it’s just me.

Back in the old times, I used to be a die-hard Atmel AVR fan for small projects, and an STM32 fan for anything larger. And I’ll freely admit, I got stuck in my ways. The incredible abundance of dev boards in the $2 range also helped keep me lazy. I had my thing, and I was fine sticking with it, admittedly due to the low price of those little blue pills.

And then came the drought, and like everyone else, my stockpile of microcontrollers started to dwindle. Replacements at $9 just weren’t an option, so I started looking around. And it’s with no small bit of shame that I’ll admit that I hadn’t been keeping up with the changes as much as I should have. Nowadays, it’s all ESP32s and RP2040s over here, and granted there’s a bit of a price bump, but the performance is there in abundance. But I can’t help feeling like I’m a few years back of the cutting edge.

So when I see work like what [CNLohr] and [Bitluni] are doing with the ultra-cheap CH32V003 microcontrollers, it makes me think that I need to start filling in gaps in my comfortable working-set of chips again. But how the heck am I supposed to keep up? And how do you? It took a global pandemic and silicon drought to force me out of my comfort zone last time. Can the simple allure of dirt-cheap chips get me out? We’ll see!

Linux Fu: Supercharge Bash History

May 5, 2023 by Al Williams 18 Comments

Having a history of shell commands is a great idea. It is, of course, enormously handy when you have to run something repetitively or you make a simple mistake that needs correction. However, as I’ve mentioned in the past, bash history isn’t without its problems. For one thing, by default, you don’t get history in one window from typing in another window. If you use a terminal multiplexer or a GUI, you are very likely to have many shells open. You can make them share history, but that comes with its own baggage. If you think about it, we have super fast computers with tons of storage compared to the “old days,” yet shell history is pretty much the same as it has been for decades. But [Rcaloras] did think about it and created Bashhub, a history database for bash, zsh, and probably some other shells, too.

You might think you don’t need anything more than what you have, and, of course, you don’t. However, Bashhub offers privately stored and encrypted history across machines. It also provides context about commands you’ve executed in the past. In other words, you can see the directory you were in, the exact time and date, the system you were on, and the last return code of the command.

Continue reading “Linux Fu: Supercharge Bash History” →

Hackaday Podcast 217: The Unintentional Space And 3D Printing Episode

May 5, 2023 by Tom Nardi No comments

Hackaday Editors Elliot Williams and Tom Nardi definitely didn’t plan on devoting most of this episode to 3D printing and space stories, but let’s be honest, it was bound to happen sooner or later. After an update on the Hackaday Prize, the discussion moves on to a pair of troubled spacecraft and the challenges of exploring the final frontier. From there you’ll hear about a chocolate 3D printer we’ve had our eyes on for years, the tools you should have next to your own (non-chocolate) 3D printer, and a bit of contemplation of what it really means to design for 3D printing versus traditional manufacturing methods. But it’s not all plastic fantastic — by the end of the episode you’ll also hear about some particularly bold high-altitude aviators and the surprisingly short time we have left with the humble barcode.

Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Going to be stranded on a desert island? Download the podcast now!

Continue reading “Hackaday Podcast 217: The Unintentional Space And 3D Printing Episode” →

This Week In Security: Oracle Opera, Passkeys, And AirTag RFC

May 5, 2023 by Jonathan Bennett 10 Comments

There’s a problem with Opera. No, not that kind of opera. The Oracle kind. Oracle OPERA is a Property Management Solution (PMS) that is in use in a bunch of big-name hotels around the world. The PMS is the system that handles reservations and check-ins, talks to the phone system to put room extensions in the proper state, and generally runs the back-end of the property. It’s old code, and handles a bunch of tasks. And researchers at Assetnote found a serious vulnerability. CVE-2023-21932 is an arbitrary file upload issue, and rates at least a 7.2 CVSS.

It’s a tricky one, where the code does all the right things, but gets the steps out of order. Two parameters, jndiname and username are encrypted for transport, and the sanitization step happens before decryption. The username parameter receives no further sanitization, and is vulnerable to path traversal injection. There are two restrictions to exploitation. The string encryption has to be valid, and the request has to include a valid Java Naming and Directory Interface (JNDI) name. It looks like these are the issues leading Oracle to consider this flaw “difficult to exploit vulnerability allows high privileged attacker…”.

The only problem is that the encryption key is global and static. It was pretty straightforward to reverse engineer the encryption routine. And JDNI strings can be fetched anonymously from a trio of endpoints. This lead Assetnote to conclude that Oracle’s understanding of the flaw is faulty, and a much higher CVSS score is appropriate. Particularly with this Proof of Concept code, it is relatively straightforward to upload a web shell to an Opera system.

The one caveat there is that an attacker has to get network access to that install. These aren’t systems intended to be exposed to the internet, and my experience is that they are always on a dedicated network connection, not connected to the rest of the office network. Even the interconnect between the PMS and phone system is done via a serial connection, making this network flaw particularly hard to get to. Continue reading “This Week In Security: Oracle Opera, Passkeys, And AirTag RFC” →