Hacklet 45 – Reverse Engineering Projects

Sooner or later, all of us end up putting on our reverse engineering hats and digging in to a device. It might be that you’re trying to keep an old piece of equipment running – the manufacturer is long defunct, and parts are no longer available. It might be that sweet new router with locked down firmware. Or, it might just be that you’re curious. Whatever the reason, reverse engineering is a rewarding endeavor. Some of our favorite reverse engineering projects read like spy novels. Instead of cloak and dagger, it’s encryption and soldering iron. This week’s Hacklet focuses on some of the best reverse engineering projects on Hackday.io!

c02We start with [Henryk Plötz] and Reverse-Engineering a low-cost USB CO₂ monitor. Carbon monoxide detection and measurement devices are household safety items these days, and have become rather cheap. Carbon dioxide measuring devices are less common, and as expected, more expensive. [Henryk] found a device for around 80€ which did what he needed. The included USB connector was supposedly just for power, but when plugging it in, the device enumerated on his Linux box. The accompanying windows software displayed live data from the detector, but there wasn’t much information on the protocol. Time to bust out Ida pro, and go to town on that software! [Henryk] did battle with his CO₂ monitor”s software and was justly rewarded.

mavrickNext up is [Bob Blake] and Reverse Engineering the Maverick ET-732. [Bob] loves barbecue, but hates to babysit his smoker. Thankfully there are wireless temperature sensors out there built just for that purpose, but they have limited range and you can’t have multiple receivers around the house. [Bob] aimed to fix all of that by sending his Maverick wireless thermometer data to the web, so he could check in on his cooking from anywhere. First he had to reverse engineer the protocol used by the sensor. A spectrum analyzer told [Bob] that the sensor transmit frequency was  433.92 MHz, which is common for low-cost transmitters like this. [Bob] actually had some compatible receivers at his office, so he was quickly able to capture some data with his Saleae logic analyzer. The real fun came in figuring out exactly how the data was organized!

hmdA chance Ebay sale netted [Technics] a sweet head mounted magnifier, but no way to control it. Reverse engineering a Life Optics M5 documents [Technics] efforts to get his new headgear working. The Life Optics M5 is actually a re-branded version of the Leica HM500 head mounted zoom microscope. These devices were originally designed for medical use. They provide a stereo view to the surgeon or dentist using them, as well as sending a video feed to be displayed for the rest of the team to use or record. Cracking open the M5’s head-mounted box revealed several modules, but no obvious means of controlling zoom or focus. Scoping out a few of the mystery wires did reveal what looks to be a 9600 baud serial data stream though. This is a brand new project, and we’re waiting for [Technics] next update to see if he gets to do some soldering with his new toy!

 

biosBIOS password protection – it’s the bane of any used laptop buyer’s existence. Sometimes removing these passwords are as easy as popping out the CMOS battery, other times, not so much. [q3k] found themselves in the latter situation with a bundle of Toshiba R100 laptops. and no way to start them up. [q3k] didn’t give up though – they broke out the soldering iron and started Reverse engineering Toshiba R100 BIOS. The R100 is a Pentium M era machine – old but still usable for many hacking purposes. Dumping the ROM BIOS of the laptop didn’t yield the information [q3k] needed, so they moved on to the TLCS-870 controller, and built a really nice board with a Xilinx Spartan6 FPGA to help with the effort. It turns out that the 870 is just used for power management. – [q3k] has now turned their attention to a Renesas microcontroller which might be just the droid they are looking for!

We think that reverse engineering projects are pretty darn cool, so we’ve created a Reverse Engineering List to keep them all organized.

That’s it for this Hacklet, As always, see you next week. Same hack time, same hack channel, bringing you the best of Hackaday.io!

18 thoughts on “Hacklet 45 – Reverse Engineering Projects

  1. Yeah, the Renesas uC is probably where the BIOS password is on those Toshiba boards. My (later model) M405 got a replacement motherboard a couple of years back (I refuse to give up this machine!) but it came with a setup password set. So I could boot it, but not configure it. Augh!

    Turns out there’s a Renesas microcontroller hidden under the PCMCIA socket that contains the password. I really wasn’t prepared to risk damaging the board trying to remove the socket to get at the chip. Luckily for me I didn’t need to, because this model can also be configured from a windows control panel, and although it still did password auth against the microcontroller, I could just patch and bypass the check altogether :)

    1. Wow, what a potential waste of security! Better way would be to ask the microcontroller to check the supplied password against it’s internal one. But then again loopholes are often handy for when things go wrong like this. One good thing that Windows is so badly written, some of the flaws are useful in coping with the other flaws.

      1. It does ask the uC to validate the password, so I couldn’t just retrieve the password from the windows executable. But when the binary is hacked to bypass the password check altogether, it still happily lets me modify bios settings. I can’t change them all, but enough to make it a non-issue.

  2. One later toshiba satellites, there are unmarked exposed pads located near the cmos battery that can be shorted to clear the eeprom that stores the bios passwords.

  3. Toshiba R100 BIOS – Woop Woop for the Warsaw hackerspace. Btw I was the one who pointed real EC (Mitsubishi M306K5F8LRP) to q3k ;o) on Warsaw hackerspace mailing list (archive behind password login so cant link directly :( ). This pretty much killed the project :P. I also found EC/KBC firmware updates, it turned out they are compressed/encrypted, and EC chip itself extracts/decrypts them internally. We dont know the cypher/compression method used. There is a way to read back over debug port of Renesas chip, but it requires super secret 7 byte unlock string (something ChipWhisperer could be good at cracking), there are companies dumping renesas microcontrollers, and screenshots on those sites suggest power analysis being used.

    Redford reverse engineered bios password check, writeup is only in polish on hackerspace mailinglist, so im gonna translate:
    1 BIOS computes MD5 of user input, sends to EC over port 66h ( http://wiki.laptop.org/go/Ec_specification#Port_66_Commands ) in a format:
    command byte: 9E (used when communicating with EC in security context)
    data: 0x24
    2 command 9F, receives 3-byte reply, checks bit 0x10 or 0x20 of last received byte, if set then password was correct.

    Challenge/Response
    1 BIOS displays “PC Serial” (stored as a string in bios eprom, separate from bios code, probably generated when flashing bios in factory)
    2 fills 16B buffer with 8B rdtsc + first 8 bytes of MD5(PC_SERIAL)
    3 appends 1A in front of this buffer and sends it to EC (1A seems to be some kind of subcommand)
    4 receives 16B buffer (high entropy)
    5 translates to a string, displays on the screen as a challenge
    6 asks for response input, translates to 16B
    7 appends 1B in front and sends it to EC
    8 receives one byte, 1 means pass

    Now at this point my suggestion was to try one of those:
    a/ modify bios, see what happens if we simply nop this code
    b/ hang little microcontroller on LPC bus, sniff traffic and hijack replies to 9F/1B command.

    Sadly both REdford and q3k were more interested in challenge/response algorithm than simply bypassing password. This is where whole project died :( Im hoping chipwhisperer will be able to revive it and enable reading back EC firmware.

    Renesas M306K EC firmware flashing is a two stage operation.
    “part1”: very small, for example 2528B.
    “part2”: rest of compressed firmware file
    Both compressed (high entropy) with one byte checksum. We have v1.10, v1.30, v2.30, v3.10 firmwares, they are same for all Toshiba laptops from that era/model line (all ECs run same firmware). All versions share same first 7 bytes of part1 (FEFF010408029E)

    This is where project got stuck, seems q3k was too lazy to update writeup on hackaday :P

  4. Carbon MONOxide is dangerous, but is CO – one Oxygen. Carbon Dioxide is CO₂ – TWO oxygens and is only dangerous in large quantities if it blocks oxygen in the atmosphere (dry ice is a sublime example). Not checking compounds elemental problems.

    Which does the detector detect?

    1. CO2 makes you feel dizzy at 1% and can kill you at 7% to 10%, heavier than air so accumulating in closed spaces, byproduct of burning natural gas, so the thing to watch out for in the home.

      Yes it’s not ‘toxic’ per se but it is an asphyxiant

      Last but not least: the picture of the display of the thing clearly shows it saying CO2, so do the math.

      Still confused? Sit in your car in the garage with the door closed, turn on the engine and wait a while. j/k

      1. What about gardens where the environment has supplemented CO2, a random article says plants may use up to 1600ppm, are these people using gas masks?

        “There is usually about 300 to 600 p.p.m. (parts per million) of CO2 in the atmosphere. Most plants can use 1500 p.p.m. in optimum growing conditions (Random article.)”

        1. CO2 concentration in air is measured by volume, ppmv, though the v is typically omitted. 1,000,000ppm = 100%, so 1,600ppm is only 0.16%. No need for a gas mask, you can survive it indefinitely without ill effect. Air inside well-insulated buildings with people can reach this on its own.

        2. I guess ill do some sloppy math : Given a random sample of air, average 400ppm of CO2 (0.04% of total composition) and 2×10^5 ppm of O2 (20% of total composition), would put a 300-400% increase of CO2 at that optimal 1200ppm-1600ppm range, leaving the room at 0.12% to 0.14% CO2.

          Very well under the 1% CO2 threshold that can makes humans dizzy.

          So it seems a grow room that is safe for plants should yield an environment safe for humans, espacially true if the garden is checked/entered in cycles of exchanging the air.

        3. Interesting tidbit from wikipedia:
          “The body produces approximately 2.3 pounds (1.0 kg) of carbon dioxide per day per person, containing 0.63 pounds (290 g) of carbon.”

          Amazing stuff (assuming it’s correct of course)

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.