TechyMagThings

Researchers [Charles Ye], [Jasmine Cui], and [Dylan Hadfield-Menell] have shown that AI Large Language Models (LLMs) can fail to correctly distinguish between different instruction sources because they prioritize writing style over metadata tags, and this role confusion leads to a powerful attack called CoT (Chain of Thought) Forgery. We’ll explain exactly how it works after a bit of background review.

Prompt injection was where “getting an LLM to do something it shouldn’t” started by exploiting the fact that LLMs communicate like people, but are much more obedient. For a while, simply telling an LLM “ignore all previous instructions and <do something funny>” yielded results no matter how transparently dumb the instructions were, and the reason it worked at all was because LLMs do not have separate data and instruction streams; it’s all one big lump of input. It’s up to the model to sort legit instructions from untrusted, user-provided data. One step towards mitigating this was the addition of roles.

Roles are a method of segmenting that big blob of input into an organized hierarchy with metadata tags. For example with <system> at the top, and <user> requests much lower down. Instructions in a role are followed as long as they don’t conflict with higher-priority ones. A system-level directive of “don’t discuss illegal things” would override a user’s request to provide a recipe for cocaine.

Another type of tag is <think>, the contents of which represent a model’s internal reasoning process. Predictably, this role has high trust. What if one could inject spoofed internal reasoning? Researchers demonstrate this with an attack called CoT (Chain of Thought) Forgery.

CoT Forgery relies on LLMs being shown to prioritize writing style over actual tag content. By writing convoluted reasoning in a style that closely matches a model’s internal and highly distinct <think> style, the model is tricked into treating it like an already-reached conclusion. Note this attack does not simply wrap the injected prompt in <think> tags.

That’s the core of it, but the rest of the research makes a compelling case that, at least for the time being, mitigating prompt injection-style attacks is likely to remain an evolving process rather than become a solved problem anytime soon. LLMs are obedient but stuck with instructions and data in a single channel, role perception isn’t binary, and humans are clever and creative.

The complete paper is available online, and code examples are on GitHub.

Many of us remember back in our school days taking tests and filling out answers on a Scantron sheet, those long rows of A, B, C, D, and E that had to be filled in with a #2 pencil. Ever wonder why it needed a #2 pencil, or what the point of using a Scantron was at all? That question is answered in the latest video from [SimonRetro], where he takes a look at the Scantron and how it works.

One of the more interesting things about the Scantron is that it’s such a standalone device. No software needed, no keypad to mess with just two rocker switches. The on/off switch is also the way you tell it to forget the last answer sheet and allow you to program in a new test. Upon booting, you feed in a Scantron sheet with some specific boxes filled in, and then it’s programmed and ready to take in and grade all the students’ answers. Opening up the Scantron reveals it’s pretty interesting inside: one control board with early-’90s-era chips. There’s also a lightbulb (no LEDs) shining through the six reading sections of the card, as well as an arrangement of belts and motors to move the card through the machine. The printer is a seven-pin printer used in conjunction with a pair of ink rollers to print out the results on the cards.

[SimonRetro] also went ahead and tried different ways to mark the sheets including pens, Sharpies, colored pencils, and different thicknesses of pencils besides the #2 to see which would and wouldn’t work in the Scantron. Thanks [SimonRetro] for exploring this machine from many of our childhoods and sharing its inner workings. Be sure to check out some of our other reverse engineering articles that explore how classic devices work.

There are plenty of radios you can buy that pick up MW and SW bands if that’s what you’re into. Or, you can follow [mircemk]’s example, and whip one up yourself instead.

The build employs an ESP32 as the brains of the operation. It’s hooked up to a rotary encoder and a small colour TFT screen, which displays an old-school style tuning dial for choosing the desired frequency. This setup is paired with an Si5351—a capable clock generator chip that can deliver just about any frequency from <8KHz up to 150+ MHz on command. There’s naturally a bunch of supporting analog hardware for the radio end of things, plus a NE612 mixer IC and a PAM8403 class D audio amplifier board, hooked up to a small 0.25W speaker for audio output. [mircemk] has set up the rig to act as a simple radio set, or, with the flick of a switch, it can be configured for SDR use with an attached computer.

It’s a handsome build, and one that likely proves a pleasant way to browse the MW and SW bands on a rainy afternoon. We’ve looked at other hardware in this category before, too. Video after the break.

This is one of those projects that was both inspired and made possible by the absolute embarrassment of dev boards available to the modern hacker. In this case, the dev board was the M5Stack PaperS3, which as the name implies combines an ESP32-S3 with an e-ink panel. [Wenting Zhang] picked one up and was immediately inspired to try and make an e-ink Game Boy.

The M5Stack PaperS3 made this project possible by exposing the display with row/column control — parallel, some would call it, as opposed to the usual serial interface of SPI. That allowed [Wenting] to work some of the same e-ink magic he perfected on his Modos monitors to allow partial refresh at up to 60 Hz. That the ESP32-S3 is capable of emulating a Game Boy while driving the screen should surprise no one, since it can emulate an MSX while outputting VGA or even Windows 95 on a 386. In this case, he’s basing the actual Game Boy emulation on Crank Boy.

Of course the e-ink screen on the M5Stack is far larger and has a much higher resolution than what the Game Boy shipped with, which lets him implement touch controls and scale the image up 3X so he can fake a couple of shades of grayscale while actually outputting black and white. Even better, if he was actually playing this thing on the regular, once the high-refresh portion of the screen starts to wear out, he can flip the orientation and keep gaming on the virtually-unrefreshed control portion of the screen — doubling the lifetime of the system, something many of you raised as a concern when we last looked at a his e-ink monitor project.

The only real shortcoming of this hack is the sound. With one-bit beeps coming out of the M5Stack buzzer, it’s got nothing on Nintendo’s hardware. Of course, that’s partially down to using the hardware as-is. With the addition of an I2S sound chip like the one used in the MOD player project we featured recently, you’d just need to squeeze out enough processor cycles to make this sound as good as it looks.

[Brian] had an absolute monster of a PCB with thousands of nets to be routed, the kind of design that stopped traditional routers in their tracks. It would take months to route by hand, likely trying the patience of a saint in the process. To solve this specific problem he created OrthoRoute, a GPU-accelerated autorouter that he cautions is no more trustworthy than any other autorouter, but at least it’s fast!

A KiCad plugin, OrthoRoute is so named because traces are laid down in a Manhattan lattice, a grid of orthogonal segments. All components (surface-mount only, no through-hole stuff) go on the top layer of the PCB, and all lower levels contain a grid of traces, connected as needed with blind and buried vias to route everything. OrthoRoute takes a structured and iterative approach, eventually converging on a satisfactory layout.

How does OrthoRouter actually decide how to connect things? [Brian] adapted PathFinder, an algorithm designed for routing FPGAs. Laying out a grid of orthogonal traces and punching down through them with vias to make connections has a lot in common, conceptually, with routing FPGAs. GPU acceleration makes the whole thing far more efficient than pipelining the calculations through a CPU.

OrthoRoute was built to solve a very specific problem, but in the process showed that GPU-accelerated routing is definitely feasible. Check it out in the videos, embedded below the page break.

[Brian] cautions that as-is, OrthoRoute is useful to maybe a handful of people at best, but as a KiCad plugin it’s highly modular and the hard parts are all done. If you want a closer look, or have some ideas about how to repurpose or extend it, check out the GitHub repository.

We’ve seen some nifty KiCad plugins for all kinds of purposes, from breadboarding to giving PCB traces an old-timey look, and even one specifically for designing custom keyboards. It’s not every day we see a plugin aimed at handling high-density boards with thousands of nets, though.

The first known use of humans using wind to perform mechanical work with machines dates back to ninth-century Persian windmills. But if we count sailing vessels among those machines, the history goes back to sometime just before the invention of written language. Since then, humans have been sailing everything from the tiniest of Sunfish to the largest of shipping vessels, and even sailing boats like canoes that aren’t typically designed for efficient sailing. For those who already own a canoe, the conversions can be straightforward but often involve drilling into the hull. This homemade conversion kit, on the other hand, requires no drilling at all.

The first, and most obvious, part of the conversion is to add a mast and sail. [Tea]’s primary setup does involve drilling a mast thwart into the gunwales of the canoe, but he also built an alternative setup which clamps to the gunwales and the bow deck instead. The standing lug sail is then hoisted on an unstayed wooden mast. The next major component of the build are a pair of leeboards which also clamp to the gunwales and function like a centerboard, and can be adjusted for one’s preferred amount of weather helm. Rounding out the stern of the boat is a custom-built rudder with a pair of lines in lieu of a tiller which can be positioned anywhere along the length of the boat.

All of the wooden parts of this build were custom-built from common lumber with finishing touches from a router to soften all of the hard edges. Canoe sailing is fairly popular, although without the leeboards these common sailing kits are often meant for downwind sailing only. A complete setup like this turns it into a much more capable craft. Without a canoe as a base vessel to start with, though, a complete sailing vessel can be built from common lumber as well.

We’re all used to satellite navigation systems such as GPS or GLONASS, sheer magic in which the combination of a set of reference transmitters and super-accurate timing information can be used to calculate a position to an astounding precision. They had land based predecessors such as LORAN and Decca Navigator which worked in a similar fashion but with fixed land-based reference transmitters. Terra is an attempt to do the same thing without a network of dedicated transmitters, instead using FM broadcast transmitters as its fixed points.

This might seem like an impossible task without access to the transmitters, but they have a workaround using the Internet as a backhaul. Instead of transmitting their timing information like the systems mentioned above, they rely on a set of reference receivers sharing it online to the client’s receiver software. So far they have a demo running in Denver.

The interesting thing about this system is that it’s open-source, and requires only a relatively inexpensive software defined radio receiver and a computer to operate. Now anyone with a group of internet-connected friends to set up reference receivers can have their own positioning system, it’s no longer the exclusive preserve of governments. We like this idea, and we look forward to seeing it being tested more widely.

If you’d like to know where we’ve come from, we’ve taken a look at LORAN before.