As promised, we are releasing the source code for the X-CTF badge, about 1 month after the event to give interested participants the chance to take a crack at it. If you are interested in the badge design process, check out my previous post on the hardware aspects.
Jeremias and Jeremy gave a talk at one of the Null Security meetups. Check out the slides if you haven’t already. In one part, Jeremy talks about the custom firmware he wrote for his badge and the additional challenges he set up for partipants to get more points. The 2nd part of the talk covers the electronic badge and challenges.
The challenges try to exploit the nature of being a self-contained electronic device. Rather than trying to replicate more CTF puzzles and simply placing them into the badge, we specially designed them for the badge.
You can find the answers to the badge puzzles (and the main CTF puzzles) in the X-CTF GitHub repo, which was released shortly after the event.
Since there’s only a single entry point into the set of challenges (meaning you must solve each puzzle before getting to the next), the puzzles must be designed with increasing levels of difficulty; too difficult and the participants will totally give up.
Stage 1: Catch Me If You Can
I particularly like this one. Unlike a program running on the computer, you can’t easily snapshot the state of the program, nor try to influence (slow down) its execution.
I had the opportunity to collaborate with some NUS students to design the electronic badge for their X-CTF event this year.
The purpose of the badge was to inspire more people to take an interest in hardware hacking, or to get them started on electronics. With so much hype on the Internet-of-Things (IoT) these days, what better idea than to let participants take home their very own IoT device. The super low cost WiFi chip, Expressif’s ESP8266, made this possible. We also wanted it to be shaped like a gaming device, with a D-pad and an LCD.
You can see the final badge design above: a ESP8266-based board with a backlit monochrome Nokia LCD, D-pad and a SELECT button. Powered by a lithium-ion battery, charged via the USB port, which also provides a serial connection to the ESP8266.
I was inspired by the SyScan 2015 badge. It was so simple and spartan: a monochrome LCD, an LED, a 5-way joystick switch and a 32-bit ARM processor (on the back). As the regulator was built-in and it runs all the way down to 2.4V, there was no need for an external regulator.
Around this time last month, the haze (or what some people call smog) here set a record high level for the Pollutant Standards Index (PSI). This is what it looked like outside:
As our National Environment Agency only published 3 hour PSI averages, I thought it would be good if we could get our own measurements. The PSI used here is somewhat like the Air Quality Index (AQI) used in the US, and is made up of 5 components:
- PM10 particulate matter
- sulphur dioxide (SO2)
- carbon monoxide (CO)
- nitrogen dioxide (NO2)
Note that the AQI includes PM2.5 particulate matter whereas PSI does not. From what we can see, I would think that a major contributor to the PSI is particulate matter (PM).
I took a brief look at the projects such as the Air Quality Egg and PACMAN. They used either the Sharp GP2Y1010AU0F or the Shinyei PPD42NS. These sensors generally operate based on the light-scattering principle, by measuring the amount of light that is scattered by particles.
Chris Nafis has done a great job documenting the use of both the GP2Y1010AU0F and the PPD42NS, compared against a Dylos DC1100 air quality monitor. As the GP2Y1010AU0F requires a certain pulse waveform to be supplied to its LED pin, I would say that the PPD42NS is self-contained and thus much easier to hook up.
On the front, it has 2 pots labelled
VR3 that have been already factory-calibrated. The IR detector is covered under the metal can. Interestingly there’s a slot by the side labelled
SL2 which is unused. If you’d like to see what’s under the hood, Chris opened up the black casing and posted a photo here.
Looking at the date code grid on the PCB, the units look like they were manufactured in July 2012. The circuit consists largely of passives and an op-amp.
RH1 is the resistor heater which, in theory, could be removed to save power if there was some other method of air circulation.
In the previous post, techniques on how to capture an IR remote signal were presented and the most reliable one was using the Arduino sketch. The captured signal was also analyzed, although we had much of our work already done for us.
In this concluding post, a remote control whose protocol is unknown will be captured and analyzed as a case study. Lastly, we will cover the re-transmission of the IR signal. The remote control in question is for my ceiling fan, KDK model M56SR. The remote also works for two other fan models M56QR and M11SU.
As I was perusing the SB-Projects site on the different IR protocol formats, I decided to make a summary but later found out that it was a pretty standard thing, as documented by a Vishay document “Data Formats for IR Remote Control” (pdf).
The infrared remote control signals are layered on top of a carrier signal of 36 or 38kHz, therefore the signal can only be “on” or “off”. A transmission typically starts with an a burst (“on” state) that is used for the Automatic Gain Control (AGC) circuitry in the receiver, followed by the “off” state and the actual data transmission.
There are 3 basic types of data transmission formats, which are illustrated in the following diagram. Protocols can be based on these transmission formats, but need not necessarily conform to them.
So how do you know what your remote control uses? And how do you capture the sequence so that you can re-transmit it from an IR diode?