Trouble Flashing Your ESP8266? Meet DIO and QIO

[Pete] was building a hot tub controller, using a WEMOS board based on the venerable ESP8266. After assembly, the board was plugged into USB and [Pete] hit the flash button. No dice. Investigation with some terminal software indicated a checksum error.

Assuming the board was dead, [Pete] grabbed another — and suffered the same problem.  The WEMOS boards wouldn’t program, but other boards had no issues. Sensing that something may be amiss, further research was in order. A forum post turned up discussing different programming modes for the ESP8266.

It turns out that there are different types of flash used with the ESP8266, and the correct programming mode must be selected for a given hardware setup. These modes are known as DIO and QIO, meaning “dual IO” and “quad IO” respectively. This refers to the number of IO line used to talk to the flash memory. There are also further modes, known as DOUT and QOUT. It’s important to identify the modes supported by the flash chip on board, by looking at the datasheet. Obviously this can be difficult on some pre-built modules, so experimentation is the key here.

With the wrong mode selected, writes to the flash will fail, and reading back will turn up a checksum error. It’s a simple matter of changing a line in the make file and trying different modes, to see which one works. This forum post has a more in-depth coverage of the issue. 

By choosing different flash memory parts and selecting the DIO or DOUT modes, it’s actually possible to free up more GPIO pins as well. This knowledge is handy when optimizing ESP8266 designs for memory speed or maximum IO flexibility. It’s a good lesson that it always pays to look at the datasheet to get the best out of your parts.

In Which Robots Fight the Console Wars

Though the names have changed over the years, the console wars wage on. [moop] must have been feeling nostalgic for the NES vs. SEGA days when he started his current project, Foobot, which is a tabletop football (soccer) game played by robots that are controlled with classic NES and SEGA controllers.

Each team has two robots that tool around on laser-cut perspex wheels attached directly to 16,000RPM motors. An SN754410 controls the motors, and each robot has an ATtiny2313 brain. They all communicate with a single transmitter over their 433MHz 1402 radio receiver modules. To avoid collisions, [moop] used a packet system, wherein each robot has an ID. The messages all contain a robot ID, message payload, and checksum. The robots ignore messages addressed to others, and any message with an invalid checksum.

[moop] has made everything available on his github, including the PCB layouts and CAD files for the robot chassis and transmitter case. Watch them battle it out after the break. If the Foobots have riled you up about vintage gaming, check out these sweet arcade hacks.

Continue reading “In Which Robots Fight the Console Wars”

Cracking Weather Station Checksum

[BaronVonSchnowzer] is spinning up some home automation and settled on an inexpensive ambient temperature sensor which is sold to augment the data a home weather station collects. He found that the RF protocol had been reverse engineered and will use this information to harvest data from a sensor in each room. In true hacker fashion, he rolled his own advances out to the Internet so that others may benefit. Specifically, he reverse engineered the checksum used by the Ambient F007TH.

He got onto this track after trying out the Arduino sketch written to receive the sensor’s RF communications. One peculiar part of the code turned out to be a filter for corrupt messages as the protocol’s checksum hadn’t yet been worked out. Figuring out how the checksum byte owrks wasn’t an easy process. The adventure led him to dump 13k samples into a spreadsheet to see if sorting similar sets of 5-byte message and 1-byte checksum would shed some light on the situation. The rest of the story is some impressive pattern matching that led to the final algorithm. Now [BaronVonSchnowzer] and anyone else using these modules can filter out corrupt data in the most efficient way possible.

BIOS password cracking

[Dogbert] took a look at the security that goes into BIOS passwords on many laptops. He starts off with a little background about how the systems work. People are bound to forget their passwords, so when you enter a wrong one three times in a row you get a message similar to the one above that locks you out until all power is removed from the system (then you get three more tries). But check out that five-digit number in the picture. That’s a checksum of the password. Some BIOS versions display it automatically, some require you to hold down a certain key during POST, but it’s the pivotal data needed to crack the password.

[Dogbert’s] post doesn’t go into verbose detail about the algorithms he uses to brute force the passwords. But he has posted the Python scripts he uses to do so. Learning how to generate the passwords based on the checksum is as simple as studying the code, which is often the best way to learn.

Subway hacker speaks

Popular Mechanics has an interview with [Zach Anderson], one of the MIT hackers that was temporarily gagged by the MBTA. The interview is essentially a timeline of the events that led up to the Defcon talk cancellation. [Zach] pointed out a great article by The Tech that covers the vulnerabilities. The mag stripe cards can be easily cloned. The students we’re also able to increase the value of the card by brute forcing the checksum. There are only 64 possible checksum values, so they made a card for each one. It’s not graceful, but it works. The card values aren’t encrypted and there isn’t an auditing system to check what values should be on the card either. The RFID cards use Mifare classic, which we know is broken. It was NXP, Mifare’s manufacturer, that tipped off the MBTA on the actual presentation.