If you’ve ever read up on the basics of cryptography, you’ll be aware of steganography, the practice of hiding something inside something else. It’s a process that works with digital photographs and is the subject of an article by [Aryan Ebrahimpour]. It describes the process at a high level that’s easy to understand for non-maths-wizards. We’re sure Hackaday readers have plenty of their own ideas after reading it.
The process relies on the eye’s inability to see small changes at the LSB level to each pixel. In short, small changes in colour or brightness across an image are imperceptible to the naked eye but readable from the raw file with no problems. Thus the bits of a smaller bitmap can be placed in the LSB of each byte in a larger one, and the viewer is none the wiser.
The origin story for many who’d call themselves a member of the hacker community usually starts with taking things apart as a child just to see how they worked. For [Radoslav], that trend doesn’t seem to have slowed down, and he’s continued taking toys apart. Although since it’s his daughters little radio controlled car, he stuck to a non-destructive teardown. The result? He’s able to control the car with his laptop through a HackRF One SDR transceiver as shown in the video below the break.
[Radoslav] is no stranger to reverse engineering embedded devices, IoT gadgets, and probably more. So he started with what information was publicly available about the radio control interface in use. Many electronic devices sold in the US must be certified by the FCC (Federal Communications Commission) and prominently display their ID number, and this toy was no exception. The FCC database gave [Radoslav] enough information to know that the communication protocol is modulated with GFSK, a type of Frequency Shift Keying.
He fired up his favorite radio signal analysis tool and and got to work on the protocol itself. Along the way he found that communication between the car and controller is bidirectional but also very easy to get around. The result is that he can drive the car around with his laptop- definitely a cool hack, but for this one, the journey was surely the goal, not the destination.
Most of us are familiar with virtual machines (VMs) as a way to test out various operating systems, reliably deploy servers and other software, or protect against potentially malicious software. But virtual machines aren’t limited to running full server or desktop operating systems. This tiny VM is capable of deploying software on less powerful systems like the Raspberry Pi or AVR microcontrollers, and it is exceptionally fast as well.
The virtual machine is built from scratch, including the RISC processor with only 61 opcodes, a 64 bit core, and runs code written in his own programming language called “Brackets” or in assembly. It’s designed to be modular, so only those things needed for a given application are loaded into the VM. With these design criteria it turns out to be up to seven times as fast as comparably small VMs like NanoVM. The project’s creator, [koder77], has even used its direct mouse readout and joystick functionality to control a Raspberry Pi 3D camera robot.
For anyone looking to add an efficient VM to a small computing environment, [koder77] has made the project open-source on his GitHub page. This also includes all of the modules he has created so far which greatly expand the project’s capabilities. For some further reading on exceedingly tiny virtual machines, we featured this project way back in 2012 which allows users to run Java on similar hardware.
[Stanislaw Pusep] has gifted us with the Pianolizer project – an easy-to-use toolkit for music exploration and visualization, an audio spectrum analyzer helping you turn sounds into piano notes. You can run his toolkit on a variety of different devices, from Raspberry Pi and PCs, to any browser-equipped device including smartphones, and use its note output however your heart desires. To show off his toolkit in action, he set it up on a Raspberry Pi, with Python code taking the note data and sending color information to the LED strip, displaying the notes in real time as he plays them on a MIDI keyboard! He also created a browser version that you can use with a microphone input or an audio file of your choosing, so you only need to open a webpage to play with this toolkit’s capabilities.
He took time to make sure you can build your projects with this toolkit’s help, providing usage instructions with command-line and Python examples, and even shared all the code used in the making of the demonstration video. Thanks to everything that he’s shared, now you can add piano note recognition to any project of yours! Pianolizer is a self-contained library implemented in JavaScript and C++ (which in turn compiles into WebAssembly), and the examples show how it can be used from Python or some other language.
[Stanislaw] also documented the principles behind the code, explaining how the note recognition does its magic in simple terms, yet giving many insights. We are used to Fast Fourier Transform (FFT) being our go-to approach for spectral analysis, aka, recognizing different frequencies in a stream of data. However, a general-purpose FFT algorithm is not as good for musical notes, since intervals between note frequencies become wider as frequency increases, and you need to do more work to distinguish the notes. In this toolkit, he used a Sliding Discrete Fourier Transform (SDFT) algorithm, and explains to us how he derived the parameters for it from musical note frequencies. In the end of the documentation, he also gives you a lot of useful references if you would like to explore this topic further!
It’s one of those things that certainly sounds simple enough: take a picture of a receipt, run it through optical character recognition (OCR), and send the resulting information to whatever expense-tracking website or software you wish. There are companies that offer such a service, so it can’t be too difficult to replicate on your own…right?
That’s what [Marcel Robitaille] thought when he set out to create his homebrew “Receipt Ingestion” system, anyway. But in reality it took so much time to troubleshoot and implement that he says it would have been faster to just enter in all his receipts by hand. We’re happy he stuck with it though, otherwise you wouldn’t be reading about it on Hackaday, and we wouldn’t be able to learn anything from the detailed account he’s provided.
It only took an evening to hack together a rough demo, and the initial results were very promising. The code could detect the edges of the receipt, rotate the captured image appropriately, and then pull out the critical information such as date, total amount, business name, etc. He was then able to decipher the API for Splitwise, an online service for splitting bills, by capturing the data sent by his browser while adding a new bill. With this information, writing up some Python code to push his captured data into the service was trivial. So far, so good.
Using a QR code as reference point.
But like so many horror films that begin with a happy family starting a new life in a beautiful home, there was a monster lurking in the shadows. It’s one thing to capture data from perfectly clean and flat receipts, but quite another to get any useful info out of one that spent half the day crumpled up in your back pocket. The promising proof of concept that worked a treat under controlled conditions failed completely in the real-world, with [Marcel] reporting that only 1 in 5 receipts he tried to scan actually went through.
In the end, [Marcel] realized that the best way to handle the unreliable condition of the receipts was to focus on a different object in the image. He came up with a QR code marker that he could put on the table with the receipt to be scanned, which his software can use as a known point of reference. This greatly improves the reliability of the image rotation and transformation, which in turn makes the OCR more reliable. It also makes it much easier to tell which images need to be scanned — if there’s no QR code found, the software just skips that shot and keeps looking.
The unique challenges of digitizing large amounts of printed content using OCR makes for some fascinating problem solving, and we’re glad [Marcel] shared this particular story with us. While there’s still some edge cases that need chasing down, he’s using the software on a nearly daily basis, and has posted it up on GitHub for anyone who might wish to build on his efforts.
We’re huge fans of taking retro games and adding new graphics features to them, so you had to know that when [Sultim Tsyrendashiev] released his ray-traced Doom engine, we would have to cover it. Now this does break with tradition — instead of running Doom on every conceivable platform, this version requires an AMD or Nvidia ray tracing capable card. On the other hand, the spirit of Doom is certainly alive, as ray-traced Doom has already been demonstrated on the Steam Deck. Check out the video below for a demo, and come back after the break for more info.
The most exciting part of this graphical feat may be the RayTracedGL1 library that “simplifies the process of porting applications with fixed-function pipeline to real-time path tracing.” Besides Doom, there’s also been demos made of Serious Sam and Half-Life 1. There’s even experimental Linux support! We managed to compile and test it on our system, running a 6700 XT and Fedora 35 with bleeding edge Mesa. There are a few visual glitches to work out, but it’s an outstanding project so far. The only complaint we have is that it’s based on prboom, not the still-maintained GZDoom, though with enough attention who knows where the project will go. If this leaves you hungry for more, check out more retro-upgrades, or Doom on more devices.
There was a time when “real” engineering workstations ran Linux Unix. Apollo and Sun were big names and Sun’s version was Solaris. Solaris has been an iffy proposition since Oracle acquired Sun, but Oracle announced last month that you can download and use Solaris 11.4 CBE free for non-production use.
Do you care? If you ever wanted to run “real” Unix this is an option although, honestly, so is Free BSD and it probably has better community support. On the other hand, since you can virtualize a machine to spin up, it might be worth a little time to install it.
On the other hand, if you have an old SPARC machine — this could be big news. We aren’t sure how far back the hardware this will support will go, but this could be just what you need to breathe new life into that eBay pizza box from Sun you’ve had in the basement. Of course, if you have an FPGA SPARC system, this might be interesting too, but we have no idea how much other stuff you need to implement to be able to benefit from Solaris.
Will you install Solaris? If so, tell us why. We are sure we won’t have to prompt you to tell us why not. In 2017, we thought we’d seen the end of Solaris, but apparently not. Maybe this will help those folks still on Solaris 9.
