Here’s A Spy Movie-Grade Access Card Sniffing Implant

Some of our devices look like they’re straight out of hacker movies. For instance, how about a small board you plant behind an RFID reader, collecting access card data and then replaying it when you next walk up the door? [Jakub Kramarz] brings us perhaps the best design on the DIY market, called The Tick – simple, flexible, cheap, tiny, and fully open-source.

Take off the reader, tap into the relevant wires and power pins (up to 25V input), and just leave the board there. It can do BLE or WiFi – over WiFi, you get a nice web UI showing you the data collected so far, and letting you send arbitrary data. It can do Wiegand like quite a few open-source projects, but it can also do arbitrary clock+data protocols, plus you can just wire it up quickly, and it will figure out the encoding.

We could imagine such a board inside a Cyberpunk DnD rulebook or used in Mr Robot as a plot point, except that this one is real and you can use it today for red teaming and security purposes. Not to say all applications would be NSA-catalog-adjacent pentesting – you could use such a bug to reverse-engineer your own garage door opener, for one.

Screenshot of the REPL running on the Flipper, importing the flipper API library and calling infrared receive function out of it with help of autocomplete

A MicroPython Interpreter For Flipper Zero

Got a Flipper Zero? Ever wanted to use a high-level but powerful scripting language on it? Thanks to [Oliver] we now have a MicroPython application for the Flipper, complete with a library for hardware and software feature support. Load it up, start it up, connect over USB, and you’ve got the ever-so-convenient REPL at your disposal. Or, upload a Python script to your Flipper and run them directly from Flipper’s UI at your convenience!

In the API docs, we’re seeing support for every single primitive you could want – GPIO (including the headers at the top, of course), a healthy library for LCD and LCD backlight control, button handling, SD card support, speaker library for producing tones, ADC and PWM, vibromotor, logging, and even infrared transmit/receive support. Hopefully, we get support for Flipper’s wireless capabilities at some point, too!

Check out the code examples, get the latest release from the Flipper app portal or GitHub, load it up, and play! Mp-flipper has existed for the better half of a year now, so it’s a pretty mature application, and it adds quite a bit to Flipper’s use cases in our world of hardware hacking. Want to develop an app for the Flipper in Python or otherwise? Check out this small-screen UI design toolkit or this editor we’ve featured recently!

Reverse-Engineering SKS Airspy Tire Pressure Sensors For Custom Firmware

Although a somewhat common feature on cars these days, tire pressure sensors (TPS) are also useful on bicycles. The SKS Airspy range of TPS products is one such example, which enables remote monitoring of the air pressure either to a special smartphone app (SKS MYBIKE) or to a Garmin device. Of course, proprietary solutions like this require reverse-engineering to liberate the hardware from nasty proprietary firmware limitations, which is exactly what [bitmeal] did with a custom firmware project.

Rather than the proprietary and closed communication protocol, the goal was to use the open ANT+ sensor instead, specifically the (non-certified) TPS profile which is supported by a range of cycling computers. Before this could happen the Airspy TPS hardware had to be first reverse-engineered so that new firmware could be developed and flashed. These devices use the nRF52832 IC, meaning that development tools are freely available. Flashing the custom firmware requires gaining access to the SWD interface, which will very likely void the warranty on a $160 – 240 device.

The SWD programmer is then attached to the 1.27 mm spaced SWD holes per the instructions on the GitHub page. After flashing the provided .hex file you can then connect to the TPS as an ANT+ device, but instructions are also provided for developing your own firmware.

This Week In Security: OpenSSH, JumbledPath, And RANsacked

OpenSSH has a newly fixed pair of vulnerabilities, and while neither of them are lighting the Internet on fire, these are each fairly important.

The central observation made by the Qualsys Threat Research Unit (TRU) was that OpenSSH contains a code paradigm that could easily contain a logic bug. It’s similar to Apple’s infamous goto fail; SSL vulnerability. The setup is this: An integer, r, is initialized to a negative value, indicating a generic error code. Multiple functions are called, with r often, but not always, set to the return value of each function. On success, that may set r to 0 to indicate no error. And when one of those functions does fail, it often runs a goto: statement that short-circuits the rest of the checks. At the end of this string of checks would be a return r; statement, using the last value of r as the result of the whole function.

Continue reading “This Week In Security: OpenSSH, JumbledPath, And RANsacked”

In A World Without USB…

It is easy to forget that many technology juggernauts weren’t always the only game in town. Ethernet seems ubiquitous today, but it had to fight past several competing standards. VHS and Blu-ray beat out their respective competitors. But what about USB? Sure, it was off to a rocky start in the beginning, but what was the real competition at that time? SCSI? Firewire? While those had plusses and minuses, neither were really in a position to fill the gap that USB would inhabit. But [Ernie Smith] remembers ACCESS.bus (or, sometimes, A.b) — what you might be using today if USB hadn’t taken over the world.

Back in the mid-1980s, there were several competing serial bus systems including Apple Desktop Bus and some other brand-specific things from companies like Commodore (the IEC bus) and Atari (SIO). The problem is that all of these things belong to one company. If you wanted to make, say, keyboards, this was terrible. Your Apple keyboard didn’t fit your Atari or your IBM computer. But there was a very robust serial protocol already in use — one you’ve probably used yourself. IIC or I2C (depending on who you ask).

Continue reading “In A World Without USB…”

Game Bub Plays ROMs And Cartridges

With today’s technology, emulating video game consoles from the 90s or before is trivial. A Raspberry Pi and a controller of some sort is perhaps the easiest and simplest way to go to get this job done, but to really impress the masses some extra effort is required. This handheld from [Eli] called the Game Bub not only nails the appearance and feel of the first three generations of Nintendo handhelds but, thanks to its FPGA, can play not only ROMs but the original game cartridges as well.

As [Eli] notes, the FPGA is not strictly necessary for emulation, but does seem to be better at interfacing with physical hardware like controllers and game cartridges. For this task an Xilinx XC7A100T with integrated memory was chosen, with a custom PCB supporting the built-in controller, speaker, a rechargeable lithium battery, and a 480×320 display (that had to be rotated out of portrait mode). An SD Card reader is included for any ROM files, and there’s also a ESP32-S3 included to give the handheld WiFi and Bluetooth capabilities, with future plans to support the communications protocol used by the Game Boy Advance Wireless Adapter.

There are a few other features with the Game Bub as well, including the ability to use an authentic link cable to communicate with the original Game Boy and Game Boy Color, and a Switch-like dock that allows the Game Bub to be connected to an external monitor. It’s also open source, which makes it an even more impressive build. Presumably it doesn’t include the native ability to dump cartridges to ROM files but you don’t need much more than a link cable to do that if you need to build your ROM library.

Continue reading “Game Bub Plays ROMs And Cartridges”

Forgotten Internet: Giving (or Getting) The Finger

Hey, you know that guy in accounting, Marco? If you want to find out more about him, you’d probably go surf LinkedIn or maybe a social media site. Inside a company, you might look on instant messaging for a profile and even find out if he is at his desk or away. But back in the 1970s, those weren’t options. But if Marco was on the computer system, maybe you could finger him. While that sounds strange to say today, Finger was a common service provided by computer services at the time. It was like a LinkedIn profile page for the 1970s.

Based on RFC 742, Finger was the brainchild for [Les Earnest]. From a user’s point of view, you put a few files in your home directory (usually .project and .plan; both hidden files), and when someone “fingered” you, they’d see some human-friendly output about your account like your name and office location, if you were logged in or not, and the contents of your project and plan files.

Modern versions may also show your public PGP key and other data. You could usually put a file in your home directory called .nofinger if you wanted to stop people from fingering you.

Continue reading “Forgotten Internet: Giving (or Getting) The Finger”