Tag Archives: arduino

Making USBasp Chinese Clones Usable

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.

USB ISP programmer with aluminium 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:

usb 3-1: new low-speed USB device number 3 using ohci-platform
usb 3-1: New USB device found, idVendor=03eb, idProduct=c8b4
usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 3-1: Product: USBHID
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.

Disassembly how-to photo

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.

USBISP programmer, with aluminium case

USPISP PCB rear

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:

Clone difference in schematic view

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.

Continue reading →

X-CTF 2016 Badge Firmware

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

animation of challenge 1

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.

Continue reading →

Designing the X-CTF 2016 Badge

X-CTF 2016 badge with Lithium-ion battery attached

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.

SyScan 2015 electronic badge

Continue reading →

Testing the Shinyei PPD42NS

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:

haze vs no haze

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:

  1. PM10 particulate matter
  2. sulphur dioxide (SO2)
  3. carbon monoxide (CO)
  4. nitrogen dioxide (NO2)
  5. 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.

PPD42NS (front)

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.

PPD42NS PCB

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.

Continue reading →

Infrared Remote Control Protocols: Part 2

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.

KDK remote control

Continue reading →