arduino on irq5 test

Making USBasp Chinese Clones Usable

Tue, 25 Jul 2017 00:06:00 +0000

I don’t have any dedicated programmers. I have been programming Atmel chips using the USB-to-serial bitbang method.

Recently, I thought I’d get one because doing a re-programming cycle is taking quite a bit of time (a disadvantage of serial port bitbanging).

A popular one on Aliexpress seems to be this “USB ISP” one, so I bought one. I chose this one because it has a nice aluminium case, and a pinout diagram imprinted on the case, which is handy. After having so many one-off projects with bare PCBs collecting dust, I now appreciate the importance of having projects in their own box or case.

While it has “USBasp” in the item name, it turns out that this was not a USBasp device, and getting it to work like one takes some effort.

It identifies itself as a zhifengsoft HID device when I plug it into Linux:

[705621.968025] usb 3-1: new low-speed USB device number 3 using ohci-platform
[705622.199065] usb 3-1: New USB device found, idVendor=03eb, idProduct=c8b4
[705622.205939] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[705622.213194] usb 3-1: Product: USBHID
[705622.216876] usb 3-1: Manufacturer: zhifengsoft

avrdude does not recognize the device, even after creating an entry with the corresponding vendor/product ID. This particular device was designed to work with their Windows-based UI called ProgISP and will not work with avrdude.

And apparently you can’t just take the USBasp firmware and flash it into this device, because the circuit is somewhat different.

After some research based on the PCB markings, I found these sites that talk about them:

Disassembly

Disassembling the device is simple. While grabbing the side of the case, firmly push the USB connector inwards and the board should slide out the other end. You can then gently pull the board out by the IDC connector.

The programmer seems to be based off of the popular USBasp programmer, but modified somewhat (to what end I’m not sure). It lacks some features offered by other USBasp programmers, like the ability to control the target’s clock, or to use 3.3V for certain targets. But at $2 with a nice aluminium case, what more can you ask for?

It’s powered by an ATmega88 (I read that older versions were based on ATmega8). The markings on the board indicate that this is a MX-USBISP-V4.00. You can ignore tHe date because it was never updated; the older V3.02 also has the same date. While the GreenPhotons blog was talking about V3.00, I have verified that this version suffers from the same issue.

Note that there are provisions on the PCB to add a voltage regulator, and the PCB link marked “C” can be cut to separate USB power from the rest of the system. Link “D” can be cut if you wish to disable target power. However, none of these options were used.

The crucial difference with this clone is that the USB D- pin is additionally connected to PD3, shown here highlighted in blue:

However, in the USBasp’s main() function, PORTD’s data direction register was initialized like so:

 /* all outputs except PD2 = INT0 */
 DDRD = ~(1 << 2);

This causes the USB D- line to be actively driven from PD3, thereby impeding communication to/from the USB host.

The rest of this post will talk about (1) correcting this problem in USBasp, and (2) uploading the firmware into your zhifengsoft programmer.

X-CTF 2016 Badge Firmware

Tue, 19 Jul 2016 00:29:00 +0000

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

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.

Designing the X-CTF 2016 Badge

Wed, 22 Jun 2016 00:29:00 +0000

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.

Testing the Shinyei PPD42NS

Wed, 24 Jul 2013 00:20:00 +0000

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)
ozone

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.

The PPD42NS

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 VR1 and 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.

Infrared Remote Control Protocols: Part 2

Sat, 11 Aug 2012 00:55:00 +0000

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.

Infrared Remote Control Protocols: Part 1

Fri, 27 Jul 2012 00:13:00 +0000

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?

My First Arduino

Sat, 08 Oct 2011 01:02:00 +0000

I finally bought myself an Arduino Uno this week. “Wait a minute… then what have you been using?” I hear you ask. Previously I had access to an Arduino Duemilanove, and used it to burn the Optiboot bootloader onto an ATmega168 that I had. The Duemilanove board used an FTDI chip which had additional pins brought out to an unsoldered header marked as X3. Following this guide by Kimio Kosaka, I downloaded the precompiled avrdude for Windows and used it to program the ATmega168 via the X3 header.

Reading BIOS EEPROM chips

Thu, 01 Jul 2010 00:51:00 +0000

I had these chips extracted from the old motherboards I threw away some time ago, and I thought I’d have some use for them some day.

These are Electrically Erasable and Programmable Read-Only Memory (EEPROM) chips which are used to hold the BIOS code. I was curious to find out what’s in these chips and if I could re-use them for storage in my projects, so I decided to interface with them.