[Buttim] loses his car a lot, which might sound a little bit like the plot from an early-00s movie, but he assures us that it’s a common enough thing. In a big city, and after several days of not driving one’s car, it can be possible to at least forget where you parked. There are a lot of ways of solving this problem, but the solution almost fell right into his lap: repurposing a lock from a bike share bicycle. (The build is in three parts: Part 2 and Part 3.)
These locks are loaded with features, like GPS, a cellular modem, accelerometers, and in this case, an ARM processor. It took a huge amount of work for [Buttim] to get anything to work on the device, but after using a vulnerability to dump the firmware and load his own code on the device, spending an enormous amount of time trying to figure out where all the circuit traces went through layers of insulation intended to harden the lock from humidity, and building his own Python-based programmer for it, he has basically free reign over the device.
To that end, once he figured out how it all worked, he put it to use in his car. The device functions as a GPS tracker and reports its location over the cellular network so it can’t become lost again. As a bonus, he was able to use the accelerometers to alert him if his car was moving without him knowing, so it turned into a theft deterrent as well. Besides that, though, his ability to get into the device’s firmware reminded us of a recent attempt to get access to an ARM platform.
If you’re reading Hackaday, you’ve almost certainly heard of JTAG. There’s an excellent chance you’ve even used it once or twice to reflash an unruly piece of hardware. But how well do you actually know JTAG? More specifically, do you know how useful it can be when reverse engineering hardware?
Whether you’re a JTAG veteran or a novice, this phenomenal guide written by [wrongbaud] is sure to teach you a thing or two. Starting with a low-level explanation of how the interface actually works, the guide takes you though discovering JTAG ports on unknown targets, the current state-of-the-art in open source tools to interact with the device, and finally shows a real-world example of pulling and analyzing a gadget’s firmware.
There’s no way to do his write-up justice with a breakdown or a summary, so we won’t even try. Just get comfortable, maybe grab a drink, and dive in. It’s certainly not a short read, but there isn’t a wasted word on the page. Every piece of the puzzle, from how to figure out an unlabeled pinout to determining the instruction length, is explained in exactly the amount of detail you’re looking for. This is a guide for hackers written by a hacker, and it shows.
One of the nice things about Linux and similar operating systems is that you can investigate something to any level you wish. If a program has a problem you can decompile it, debug it, trace it, and — if necessary — even dig into the source code for the kernel and most of the libraries the program is probably using. However, the tools to do this aren’t ones you use every day. One very interesting tool is strace. Using it you can see what system calls any program makes and that can sometimes give you important clues about how the program works or, probably more often, why it doesn’t work.
Let’s consider the least complex use of the command. Suppose you want to make symlink from testxmit.grc to the /tmp directory. That command is simple:
ln -sf testxmit.grc /tmp
But if you tell strace to run it, the command becomes:
strace ln -sf testxmit.grc /tmp
You might want to redirect the output to a file using the shell or the -o option, though. Some commands generate a lot and often the first page or two of output isn’t really what you care about anyway. Continue reading “Linux Fu: Tracing System Calls”→
The Samsung PS-WTX500 subwoofer is designed to be used as part of a 5.1 channel home theater system, but not just any system. It contains the amplifiers for all the channels, but they’ll only function when the subwoofer is connected to the matching receiver. [Alejandro Zarate] figured there must be some way to unlock the system’s full functionality without being limited to the original receiver, he just needed to reverse engineer how the subwoofer worked.
The result is a fantastically well documented write-up that covers the whole process, starting with how [Alejandro] identified and researched the Pulsus PS9829B Digital Audio Processor (DAP). Documentation for this particular chip seems hard to come by, but he was able to find a similar chip from the same manufacturer that was close enough to put him on the right track. From there, he started studying the SPI communications between the DAP and the subwoofer’s S3P70F4 microcontroller.
After analyzing the communication between the two chips, [Alejandro] pulled the S3P70F4 off the board and wired an Arduino Pro Mini 328 in its place. The Arduino was quite a bit larger than the original microcontroller, but with some careful wiring, he manged a very professional looking installation. Short of coming up with a custom PCB adapter, we don’t think it could look much better.
With some relatively straightforward code and a listing of the captured byte sequences, the Arduino was able to power up the PS-WTX500’s amplifiers and handle the incoming audio signal as a stand-alone device.
As the original hardware from the golden era of 8-bit computer gaming becomes a bit long in the tooth, keeping it alive has become something of a concern for enthusiasts. There have been a succession of remanufactured parts for many of the major platforms of the day, and now thanks to [Redherring32] it’s the turn of the NES console.
It’s an interesting exercise in reverse engineering as well as a chance to look at the NES at the chip level. Also for Nintendo-heads, it provides all the component footprints and schematic items in KiCAD format. Will many be built? Given that the NES was the best-selling console of its time there should be no shortage of originals to be found, but that in no way invalidates the effort put into this project. There will be NES consoles somewhere running for decades to come because of work such as this, simply remember that you don’t need to blow in the slot to make it work!
Drivers with a lead foot more often than not have Waze open on their phone so they can see if other drivers have spotted cops up ahead. But avoiding a speeding ticket used to involve a lot more hardware than software. Back before the smartphone revolution, that same driver would have had a radar detector on their dashboard. That’s not to say the gadgets are completely unused today, but between their relatively high cost (one of the top rated models on Amazon as of this writing costs over $300) and the inevitable false positives from so many vehicles on the road having their own radar and LIDAR systems, they’ve certainly become a less common sight over the years
The subject of today’s teardown is a perfect example of “Peak Radar Detector”. Manufactured back in 2007, the Cobra XRS 9740 would have been a fairly mid-range entry offering the sort of features that would have been desirable at the time. Over a decade ago, having an alphanumeric display, voice alerts, and a digital compass were all things worth shouting about on the box the thing was sold in. Though looking like some kind of Cardassian warship was apparently just an added bonus.
As the name implies these devices are primarily for detecting radar activity, but by this point they’d also been expanded to pick up infrared lasers and the strobe beacons on emergency vehicles. But false positives were always a problem, so the device allows the user to select which signals it should be on the lookout for. If you were getting some kind of interference that convinced the detector it was being bombarded with IR lasers, you could just turn that function off without having to pull the plug entirely.
But it’s important to remember that this device was built back when people were still unironically carrying around flip phones. Detecting laser and multi-band radars might sound like something pulled from the spec sheet of a stealth fighter jet, but this is still a piece of consumer electronics from more than a decade in the past. So let’s crack it open and take a look at what goes on inside a radar detector that’s only a few years away from being old enough to get its own driver’s license.
It’s amazing to see how much technology is packed into even the “simple” devices that we take for granted in modern life. Case in point, the third party Xbox controller that [wrongbaud] recently decided to tear into. Not knowing what to expect when he cracked open its crimson red case, inside he found an ARM Cortex microcontroller and a perfect excuse to play around with Serial Wire Debug (SWD).
Though even figuring out that much took a bit of work. As is depressingly common, all the interesting components on the controller’s PCB were locked away behind a black epoxy blob. He had no idea what chip was powering the controller, much less that debugging protocols it might support. But after poking around the board with his multimeter, he eventually found a few test points sitting at 3.3 V which he thought was likely some kind of a programming header. After observing that pulling the line labelled “RES” low reset the controller, he was fairly sure he’d stumbled upon a functional JTAG or SWD connection.
As [wrongbaud] explains in his detailed blog post, SWD is something of a JTAG successor that’s commonly used by ARM hardware. Using just two wires (data and clock), SWD provides hardware debugging capabilities on pin constrained platforms. It allows you to step through instructions, read and write to memory, even dump the firmware and flash something new.
For the rest of the post, [wrongbaud] walks the reader through working with an SWD target. From compiling the latest version of OpenOCD and wiring an FTDI adapter to the port, all the way to navigating through the firmware and unlocking the chip so you can upload your own code.
To prove he’s completely conquered the microcontroller, he ends the post by modifying the USB descriptor strings in the firmware to change what it says when the controller is plugged into the computer. From here, it won’t take much more to get some controller macros like rapid fire implemented; a topic we imagine he’ll be covering in the future.