Reverse Engineering Cyclic Redundancy Codes

June 27, 2019 by Ted Yapo 17 Comments

Cyclic redundancy codes (CRC) are a type of checksum commonly used to detect errors in data transmission. For instance, every Ethernet packet that brought you the web page you’re reading now carried with it a frame check sequence that was calculated using a CRC algorithm. Any corrupted packets that failed the check were discarded, and the missing data was detected and re-sent by higher-level protocols. While Ethernet uses a particularly common CRC, there are many, many different possibilities. When you’re reverse-engineering a protocol that contains a CRC, although it’s not intended as a security mechanism, it can throw a wrench in your plans. Luckily, if you know the right tool, you can figure it out from just a few sample messages.

A case in point was discussed recently on the hackaday.io Hack Chat, where [Thomas Flayols] came for help reverse engineering the protocol for some RFID tags used for race timing. Let’s have a look at the CRC, how it is commonly used, and how you can reverse-engineer a protocol that includes one, using [Thomas’] application as an example.

Continue reading “Reverse Engineering Cyclic Redundancy Codes” →

Homemade Magic Makes The Metcal Go

June 16, 2019 by Kerry Scharfglass 29 Comments

First soldering irons are often of the ~~Radioshack or Maplin~~ firestarter variety. They’re basically wall power shorted across a nichrome heater or similar with some inline resistance to make it harder to burn down the house. You plug them in, the current flows, and they get hot. Done.

If you stick with the hobby for a while, these eventually get replaced with something like the venerable HAKKO FX-888D or that one Weller everyone likes with the analog knob. These are much improved; having temperature control leads to a more consistently heated tip and much improved soldering experience.

Entering the electronics workplace one comes across the next level of quality soldering iron: high end HAKKOs, Metcals, JBCs, and the like. Using one of these irons is practically a religious experience; they heat in a flash and solder melts while you blink. They even turn off when you put the handpiece down! But they’re expensive to buy (hint: think used). What’s a hobbyist to do?

[SergeyMax] seems to have had this problem. He bit the bullet, figured out how the Metcal works, and made his own base. This is no mean feat as a Metcal might look like a regular iron but it’s significantly more complex than ye olde firestarter. The Metcal magic is based on a oscillating magnetic fields (notice the handpiece is connected via BNC?) interacting with a tip bearing a special coating. In the presence of the changing field the tip heats up until it hits its Curie temperature, at which point it stops interacting with the magnetic field and thus stops heating.

When the user solders, the tip cools by sinking its heat into the part and drops below the Curie temperature again, which starts the heating again. It’s like temperature control with the sensor placed absolutely as close to the part as possible and a nearly instant response time, without even a control loop! [SergeyMax] has a much more thorough description of how these irons work, which we definitely recommend reading.

So what’s the hack? Based on old schematics and some clever reverse engineering from photos [SergeyMax] built a new base station! The published schematic is as rich with capacitors and inductors as one could hope. He didn’t post source or fab files but we suspect the schematic and photos of the bare board combined with some tinkering are enough for the enterprising hacker to replicate.

The post contains a very thorough description of the reverse engineering process and related concerns in designing a cost efficient version of the RF circuitry. Hopefully this isn’t the last Metcal replacement build we see! Video “walkthrough” after the break.

Edit: I may have missed it, but eagle eyed commentor [Florian Maunier] noticed that [SergeyMax] posted the sources to this hack on GitHub!

Continue reading “Homemade Magic Makes The Metcal Go” →

Reverse Engineering WyzeSense Hardware

June 11, 2019 by Lewin Day 6 Comments

Wyze are a company that produces a variety of home automation products. Their Wyze Sense package is a system of contact and PIR home security sensors, that piggy backs off their Wyze Cam product. In the interests of being able to use this hardware outside the prescribed corporate ecosystem, [Xuan Xing] got down to hacking.

The project starts by tearing down the Wyze Cam, and getting serial console access. This was made easier by an existing Github project, which develops custom firmwares for smart cameras. With that in place he was able to see what was going on under the hood, and read the camera’s system logs.

By poring over these logs, and examining the disassembled Wyze Sense dongle, he’s well on the way to discovering how the sensors communicate with the Wyze Cam. The end goal is to enable the Wyze security sensors to be used with the Raspberry Pi platform, and to share the code on Github for other makers to experiment with.

Home automation platforms come and go quicker than the seasons change. This makes the hardware a popular target for hackers trying to get things running independently of any one company’s servers.

Hail To The King, Baby: Reverse Engineering Duke

June 8, 2019 by Tom Nardi 15 Comments

If you’re a fan of DOS games from the 1990s, you’ve almost certainly used DOSBox to replay them on a modern computer. It allows you to run software in a virtual environment that replicates an era-appropriate computer. That’s great for historical accuracy, but doesn’t do you much good if you’re trying to leverage modern computing power to breathe some new life into those classic titles. For that, you need to dig in a little deeper.

For the last two and a half years, [Nikolai Wuttke] has been doing exactly that for 1993’s Duke Nukem II. The end result is RigelEngine, an open source drop-in replacement for the original game binary that not only runs on a modern Windows, Linux, or Mac OS machine, but manages to improve on the original in a number of ways. An accomplishment made even more impressive once you learn that the original source code for the game has been lost to time, and that he had to do everything blind.

In a blog post chronicling his progress so far, [Nikolai] explains the arduous process he used to make sure his re-implementation was as accurate as possible to the original game. He spent untold hours studying the original game’s disassembled code in Ida Pro, handwriting out pages of notes and pseudocode as he tried to understand what was happening behind the scenes. Once a particular enemy or element of the game was implemented in RigelEngine, he’d record the gameplay from his version and compare it to the original frame by frame so he could fine tune the experience.

So what’s the end result of more than two years of work and over 25K lines of code? Thanks to the incredible advancements in computing power since the game’s release nearly 30 years ago, [Nikolai] has managed to remove the need for loading screens. His engine is also capable of displaying an unlimited number of particle effects on the screen at once, and multiple sound effects can now be played simultaneously. In the future he’s looking to implement smooth character movement (in the original game, movement was in 8 pixel increments) and adaptive volume for sound effects based on their distance from Duke. Ultimately, RigelEngine should be able to replace the original graphics with new high resolution textures once some issues with the rendering buffer gets sorted out.

It’s hard to overstate how important some of these classic games are to those who grew up playing them. With John Romero still releasing DLC for the original DOOM and hackers disassembling nearly 40 year old games to fix bugs, it doesn’t seem like they’re in any danger of being forgotten.

Continue reading “Hail To The King, Baby: Reverse Engineering Duke” →

Your Table Is Ready, Courtesy Of HackRF

June 4, 2019 by Tom Nardi 28 Comments

Have you ever found yourself in a crowded restaurant on a Saturday night, holding onto one of those little gadgets that blinks and vibrates when it’s your turn to be seated? Next time, bust out the HackRF and follow along with [Tony Tiger] as he shows how it can be used to easily fire them off. Of course, there won’t actually be a table ready when you triumphantly show your blinking pager to the staff; but there’s only so much an SDR can do.

Even if you aren’t looking to jump the line at your favorite dining establishment, the video that [Tony] has put together serves as an excellent practical example of using software defined radio (SDR) to examine and ultimately replicate a wireless communications protocol. The same techniques demonstrated here could be applied to any number of devices out in the wild with little to no modification. Granted these “restaurant pagers” aren’t exactly high security devices to begin with, but you’d be ~~horrified~~ surprised how many other devices out there take a similarly cavalier attitude towards security.

[Tony] starts by using inspectrum to examine the Frequency-shift keying (FSK) modulation used by the 467.750 Mhz devices, and from there, uses Universal Radio Hacker to capture the actual binary data being sent over the air. Between studying the transmissions and the information he found online, he was eventually able to piece together the packet structure used by the restaurant’s base station.

Finally, he wrote a Python script which generates packets based on which pager he wants to set off. If he’s feeling particularly mischievous, he can even set them all off at once. The script outputs a binary file which is then loaded into GNU Radio for transmission via the HackRF. [Tony] says he’s not quite ready to release his script yet, but he gives enough information in the video that the intrepid hacker could probably get their own version up and running by the time he gets it posted up to GitHub anyway.

We saw some very similar techniques demonstrated at the recent WOPR Summit security conference, so once you’re done hacking the local restaurants, you can take these same lessons and apply them to the rest of the Internet of Things. If you’re wondering, it’s even easier to eavesdrop on the non-restaurant pagers.

Continue reading “Your Table Is Ready, Courtesy Of HackRF” →

Solving The Final Part Of The IClicker Puzzle

May 21, 2019 by Tom Nardi 9 Comments

The regular Hackaday reader might remember the iClicker from our previous coverage of the classroom quiz device, or perhaps you even had some first hand experience with it during your university days. A number of hackers have worked to reverse engineer the devices over the years, and on the whole, it’s a fairly well understood system. But there are still a few gaps in the hacker’s map of the iClicker, and for some folks, that just won’t do.

[Ammar Askar] took it upon himself to further the state of the art for iClicker hacking, and has put together a very detailed account on his blog. While most efforts have focused on documenting and eventually recreating how the student remotes send their responses to the teacher’s base station, he was curious about looking at the system from the other side. Specifically, he wanted to know how the base station was able to push teacher-supplied welcome messages to the student units, and how it informed the clients that their answers had been acknowledged.

He started by looking through the base station’s software update tool to find out where it was downloading the firmware files from, a trick we’ve seen used to great effect in the past. With the firmware in hand, [Ammar] disassembled the AVR code in IDA and got to work piecing together how the hardware works. He knew from previous group’s exploration of the hardware that the base station’s Semtech XE1203F radio is connected to the processor via SPI, so he started searching for code which was interacting with the SPI control registers.

This line of logic uncovered how the radio is configured over SPI, and ultimately where the data intended for transmission is stored in memory. He then moved over to running the firmware image in simavr. Just like Firmadyne allows you to run ARM or MIPS firmware with an attached debugger, this tool allowed [Ammar] to poke around in memory and do things such as simulate when student responses were coming in over the radio link.

At that point, all he had to do was capture the bytes being sent out and decode what they actually meant. This process was complicated slightly by the fact the system uses to use its own custom encoding rather than ASCII for the messages, but by that point, [Ammar] was too close to let something like that deter him. Nearly a decade after first hearing that hackers had started poking around inside of them, it looks like we can finally close the case on the iClicker.

Analog Failures On RF Product Cause Production Surprise

May 13, 2019 by Kerry Scharfglass 15 Comments

A factory is a machine. It takes a fixed set of inputs – circuit boards, plastic enclosures, optimism – and produces a fixed set of outputs in the form of assembled products. Sometimes it is comprised of real machines (see any recent video of a Tesla assembly line) but more often it’s a mixture of mechanical machines and meaty humans working together. Regardless of the exact balance the factory machine is conceived of by a production engineer and goes through the same design, iteration, polish cycle that the rest of the product does (in this sense product development is somewhat fractal). Last year [Michael Ossmann] had a surprise production problem which is both a chilling tale of a nasty hardware bug and a great reminder of how fragile manufacturing can be. It’s a natural fit for this year’s theme of going to production.

Surprise VCC glitching causing CPU reset

The saga begins with [Michael] receiving an urgent message from the factory that an existing product which had been in production for years was failing at such a high rate that they had stopped the production line. There are few worse notes to get from a factory! The issue was apparently “failure to program” and Great Scott Gadgets immediately requested samples from their manufacturer to debug. What follows is a carefully described and very educational debug session from hell, involving reverse engineering ROMs, probing errant voltage rails, and large sample sizes. [Michael] doesn’t give us a sense for how long it took to isolate but given how minute the root cause was we’d bet that it was a long, long time.

The post stands alone as an exemplar for debugging nasty hardware glitches, but we’d like to call attention to the second root cause buried near the end of the post. What stopped the manufacturer wasn’t the hardware problem so much as a process issue which had been exposed. It turned out the bug had always been reproducible in about 3% of units but the factory had never mentioned it. Why? We’d suspect that [Michael]’s guess is correct. The operators who happened to perform the failing step had discovered a workaround years ago and transparently smoothed the failure over. Then there was a staff change and the new operator started flagging the failure instead of fixing it. Arguably this is what should have been happening the entire time, but in this one tiny corner of the process the manufacturing process had been slightly deviated from. For a little more color check out episode #440.2 of the Amp Hour to hear [Chris Gammell] talk about it with [Michael]. It’s a good reminder that a product is only as reliable as the process that builds it, and that process isn’t always as reliable as it seems.