WoWMIPS: A MIPS Emulator For Windows Applications

When Windows NT originally launched it had ports to a wide variety of platforms, ranging from Intel’s x86 and i860 to DEC’s Alpha as well as the MIPS architecture. Running Windows applications written for many of these platforms is a bit tricky these days, which [x86matthew] saw as a good reason to write a MIPS emulator. This isn’t just any old emulator, though. It maps 32-bit Windows applications targeted at the MIPS R4000 CPU to an x86 CPU instead. Since both platforms run in a little-endian, 32-bit mode, this theoretically should be a walk in the park.

The use of the Windows PE executable format is also the same, so the first task was to figure out how to load the MIPS PE binary in a way that made sense for an x86 platform. This involved some reverse-engineering of the MIPS ntdll.dll file to figure out how relocations on that platform were handled. Following this, the mapping of the instructions of the R4000 CPU to the (CISC) x86 ISA was pretty easy. Only Floating Point Unit (FPU) support was left as a future challenge. Memory access was left as direct access, meaning no sandboxing or isolation, for simplicity’s sake.

The final task was mapping the native API calls, which call almost directly into the underlying host Windows OS’s API, with a bit of glue logic. With all of this done, Windows NT applications originally written for 1990s MIPS ran just fine on a modern-day x86_64 PC running Windows — as long as you don’t need an FPU (for now).

An image of a cave drawing of horned cow. There is another one coming up behind it as well. There are four dots as described by the researchers on the main cow's back.

Writing – So Easy A Caveperson Could Do It

We modern humans tend to take writing for granted, and often forget that like any other technology, somebody had to invent it. Researchers from Cambridge believe they’ve determined the purpose of one of the earliest writing beta-tests.

Examining a database of images taken in caves throughout Europe and dated to the Upper Paleolithic, the researchers found “three of the most frequently occurring signs—the line <|>, the dot <•>, and the <Y>—functioned as units of communication.”

It appears the <|> and <.> symbols when “in close association with images of animals” denote time relating to lunar months of the year, starting with spring as the new year. The <Y> symbol appears to carry the meaning <To Give Birth> allowing early people a way to tell others information about the prey of a region, which would be pretty handy when hunting and gathering are your only options for food.

We’ve covered other ancient technologies like storytelling and abrasives. If you’re curious what the climate was like for our ancestors, perhaps paleoclimatology will tickle your fancy.

IoT Air Purifier Makes A Great Case Study In Reverse Engineering

Here at Hackaday, about the only thing we like more than writing up tales of reverse engineering heroics is writing up tales of reverse engineering heroics that succeed in jailbreaking expensive widgets from their needless IoT dependency. It’s got a real “stick it to the man” vibe that’s hard to resist.

The thing is, we rarely see a reverse engineering write-up as thorough as the one [James Warner] did while integrating an IoT air purifier into Home Assistant, so we just had to make sure we called this one out. Buckle up; it’s a long, detailed post that really gets down into the weeds, but not unnecessarily so. [James] doesn’t cloud-shame the appliance manufacturer, so we can’t be sure who built this, but it’s someone who thought it’d be a swell idea to make the thing completely dependent on their servers for remote control via smartphone. The reverse engineering effort started with a quick look at the phone app, but when that didn’t pay off in any useful way, [James] started snooping on what the device was talking about using Wireshark.

One thing led to another, wires were soldered to the serial pins on the ESP32 on the purifier’s main board, and with the help of a FlipperZero as a UART bridge, the firmware was soon in hand. This gave [James] clues about the filesystem, which led to a whole Ghidra side quest into learning how to flash the firmware. [James] then dug into the meat of the problem: figuring out the packet structure used to talk to the server, and getting the private key used to encrypt the packets. This allowed a classic man-in-the-middle attack to figure out the contents of each packet and eventually, an MQTT bridge to let Home Assistant control the purifier.

If it sounds like we glossed over a lot, we know — this article is like a master class on reverse engineering. [James] pulled a lot of tools out of his kit for this, and the write-up is clear and concise. You may not have the same mystery fan to work with, but this would be a great place to start reverse engineering just about anything.

Thanks to [ThoriumBR] for the tip.

A white male in a green shirt sitting next to a tall rectangular robot made of green and black components with an aluminum frame. In front of him are a variety of components from several windshield wiper motor assemblies. Casings, gearboxes, and the like are strewn across the wooden table.

A Wiper Motor 101

Need a powerful electric motor on the cheap? [Daniel Simu] and his friend [Werner] show us the ins and outs of using windshield wiper motors.

Through many examples and disassembled components, the duo walk us through some of the potential uses of wiper motors to power a project. Some of the nuggets we get are the linear relationship of torque to current (10-15A max) and speed to voltage (12-15V DC) on these units, and some of the ways the wiring in these motors is a little different than a simple two wire DC motor.

They also discuss some of their favorite ways to control the motors ranging from a light switch to an Arduino. They even mention how to turn one into a big servo thanks to a project on Hackaday.io and a few modifications of their own. [Simu] also discusses some of the drawbacks of wiper motors, the most evident being that these motors use nylon gears which are prone to stripping or failing in other ways when subjected to high torque conditions for too long.

If you recognize [Simu], it may be from his robotic acrobat built with wiper motors. Want to see some more wiper motor hacks? How about a 3D scanner or making sure your wipers always keep the beat?

Continue reading “A Wiper Motor 101”

Hacking A Xiaomi Air Purifier’s Filter DRM To Extend Its Lifespan

When [Unethical Info] was looking at air purifiers a while back, their eye fell on a Xiaomi 4 Pro, with a purchase quickly made. Fast-forward a while and suddenly the LCD on top of the device was showing a threatening ‘0% filter life remaining’ error message. This was traced back to an NFC (NTAG213) tag stuck to the filter inside the air purifier that had been keeping track of usage and was now apparently the reason why a still rather clean filter was forcibly being rejected. Rather than give into this demand, instead the NFC tag and its contents were explored for a way to convince it otherwise, inkjet cartridge DRM-style.

While in the process of reverse-engineering the system and doing some online research, a lucky break was caught in the form of earlier research by [Flamingo Tech] on the Xiaomi Air Purifier 3, who had obtained the password-generating algorithm used with the (password-locked) NFC tag, along with the target area of the filter’s NFC tag to change. Using the UID of the NFC tag, the password to unlock the NFC tag for writing was generated, which requires nothing more than installing e.g. ‘NFC Tools’ on an NFC-capable Android/iOS smartphone to obtain the tag’s UID and reset the usage count on the filter.

A password generating tool is provided with the [Unethical Info] article, and this approach works across a range of Xiaomi air purifiers, making it an easy fix for anyone who owns such a device but isn’t quite ready yet to shell out the big bucks for a fresh DRM-ed filter. This approach also saves one from buying more NFC tags, which was the case with the previous solution.

Reviving A Sensorless X-Ray Cabinet With Analog Film

In the same way that a doctor often needs to take a non-destructive look inside a patient to diagnose a problem, those who seek to reverse engineer electronic systems can greatly benefit from the power of X-ray vision. The trouble is that X-ray cabinets designed for electronics are hideously expensive, even on the secondary market. Unless, of course, their sensors are kaput, in which case they’re not of much use. Or are they?

[Aleksandar Nikolic] and [Travis Goodspeed] strongly disagree, to the point that they dedicated a lot of work documenting how they capture X-ray images on plain old analog film. Of course, this is nothing new — [Wilhelm Konrad Roentgen] showed that photographic emulsions are sensitive to “X-light” all the way back in the 1890s, and film was the de facto image sensor for radiography up until the turn of this century. But CMOS sensors have muscled their way into film’s turf, to the point where traditional silver nitrate emulsions and wet processing of radiographic films, clinical and otherwise, are nearly things of the past. Continue reading “Reviving A Sensorless X-Ray Cabinet With Analog Film”

Reverse Engineering The Apple Touch Bar Screen

The Apple Touch Bar was an oddity on a fairly small number of Apple laptops which replaced the function key row with a touch display. Yet what is special about this display other than its odd form factor when you consider it as a generic touch display? As [Wenting Zhang] describes in a recent reverse-engineering video, this 2,170 x 60 pixel display is somewhat limited in that it doesn’t support the MIPI DSI video mode, only command mode, along with a special instruction (0x3C) for automatic address offsets. The results of this project can be found on the GitLab account.

In a way these limitations make sense when you consider Apple’s use case for these special MIPI-DSI displays. As a touch screen with dynamic controls being displayed on it, features such as video playback never were a goal, and thus Apple likely decided to save a few bucks, possibly also due to MIPI licensing costs. What this means is that if you had dreamed of snapping up an extremely long and narrow OLED display for a video project you’re in for somewhat of a bad time. Although animated content is possible – as [Wenting] demonstrates – this comes with all the limitations of command mode, meaning slower updates, higher power usage and a lot more overhead.

Continue reading “Reverse Engineering The Apple Touch Bar Screen”