hardhack

site

search

hardhack definition

[hahrd-hak] verb: to skillfully devise or modify a computer program or electronics device; noun: wiretrip web site devoted to hacking on gadgets and electronics; unrelated: steeplebush, a thorny shrub

 
You can read more regarding what wiretrip hardhack is about in our welcome message

MCU Programming Intro Series #1: SOS on the Arduino

[This article is written by the Wiretrip Hardhack Team and originally appeared on the uCHobby.com website]

During our amateur travels with electronics, we thought it would be interesting to document some our introductory-level experiments on new MCU (microcontroller) platforms. Whenever we get our hands on a new platform, we take the time to do some rudimentary level programming just to get a feel for the platform and the associated development environment. This is the first in a multi-part series that are going to explore different hardware MCU platforms and programming environments.

The programming goal for all of the platforms is a slightly more complex twist on the usual 'hello world' hardware hacking project: blinking a LED. In our case, we want to specifically blink out an SOS pattern (i.e. three short blinks, three long blinks, three short blinks, pause, repeat). We like the idea of the SOS pattern, because it requires an explicit control of the LED based on different timing characteristics. Also, while there are tons of 'blink the LED' tutorials for most platforms on the Internet, there are few 'blink the LED in SOS pattern' tutorials...so it's not a matter of a simple copy/paste job from someone else's prior work. And there is a certain useful utility to blinking out an SOS: you can use it in your own code to indicate (in overly fancy fashion) when your board experiences a fatal error. Anyways, on to the walk through.

Arduino Duemilanove board

Our first platform is the Arduino Duemilanove, a highly popular and easy to use microcontroller development platform based on the ATmega168. Despite being based on an ATmega MCU, Arduino uses a special C-esque programming language (based on the Wiring language) rather than the usual AVR programming language. The Arduino also uses a programming IDE based on Processing, rather than the usual suite of AVR tools. The main Arduino home site is at www.arduino.cc. There are many Arduino derivatives and offshoots, such as the Freeduino, Lilypad, etc. Overall, Arduino is an open platform that is easy to adapt and extend into many forms, while keeping a few common key characteristics (supporting the Arduino programming language, utilizing USB connectivity for programming, etc.).

Interfacing with an Arduino Duemilanove is relatively simple: you plug it into your computer via a USB cable, install the USB driver, and it shows up as a serial (COM) port on your system. The Arduino programming IDE interfaces with the Arduino via the COM port. Arduino calls the firmware programs you write a 'sketch'; a sketch is typically composed of some setup code (in a function called setup()) and the main application code which repeats in an infinite loop (contained in a function called loop()). For those familiar with C, the implied main() code (which you do not see/manipulate) is: 

void main( void ) {
	setup();
	while(1)
		loop();
}

MCUs often come equipped with GPIO (general purpose input/output) pins that are used to control electronic circuits. For output-based digital GPIO pins, the MCU generates either a high or low electric current on the pin (i.e. a digital one or digital zero). You can connect and control an appropriate LED via GPIO; setting the GPIO output to high causes the LED to light, while setting the GPIO output to low causes the LED to turn off. In an Arduino, you can control the output of a GPIO pin with the digitalWrite() function.

The standard Arduino Duemilanove comes equipped with a LED connected to GPIO pin 13; thus a basic Arduino has all of the hardware necessary for our SOS blinking needs. All we need to do is create our custom sketch (software) to blink the LED in the right pattern.

Arudino IDE

If you haven't done it already, connect your Arduino Duemilanove to your computer with the USB cable. The Arduino uses power from the USB port to power itself, so no external power supplies are required (although you can optionally use one if necessary). Windows will want to install a USB device driver for the Arduino the first time. The driver is included in the free Arduino IDE download, in the 'drivers/' folder (be sure to unzip the downloaded .zip file to some suitable location first). When prompted by the driver installation dialog, select the 'specify an exact location' option and browse to this folder. Windows will find the right drivers and install a USB-based virtual serial (COM) port. Detailed steps of this process are available at http://arduino.cc/en/Guide/Windows.

Now start the Arduino IDE (just double-click the arduino.exe file in the directory you previously unzipped). The Arduino IDE is fairly minimal, but that also makes it easy to navigate and use. You must make sure you configure the IDE to the right COM port and Arduino device you are using. You'll find these configuration options via the Tools -> Serial Port and the Tools -> Board menu options. Note: if you have an Arduino Duemilanove and don't see it listed in the IDE's board selection list, select the Arduino Diecimila board model.

The IDE ships with many example sketches for use including a basic 'blink the LED' sketch. Let's go ahead and load that sketch by going to File -> Sketchbook -> Examples -> Digital -> Blink.

Loading the Blink sketch

You will see some basic code in the setup() and loop() functions. First we see that a variable 'ledPin' is created and assigned the value 13, which is the GPIO pin number that contains the LED. This variable is created purely for convenience and to enhance readability of the code (i.e. it is easier to know what 'ledPin' means than the plain number '13'). In the setup() function, the pinMode() function is used to specify that GPIO pin 13 is used in output mode. Then the loop() function uses digitalWrite() to set GPIO pin 13 to a high state (i.e. send electricity on the pin and thus turn on the LED), wait for a little bit via the delay() function, then use digitalWrite() again to set GPIO pin 13 to a low state (i.e. stop sending electricity and make the LED turn off). This process is repeated in an indefinite loop.

Just for fun, let's go ahead and run this example sketch as-is. Click the 'verify' button (verify button) to compile and check that the code is valid, and then click the 'upload' button (upload button) to have it uploaded to the Arduino and executed. Within moments, you should see the LED blinking. So far, so good.

Now we need to adapt the code to blink the specific SOS pattern. Basically we want three short blinks, followed by three long blinks, followed by another set of three short blinks, and then a noticeable pause. We could code this up as a sequential series of 18 calls to digitalWrite() with associated delay()s, but that seems excessive. Let's use a simple loop, like so:

for(int i=0; i<3; i++){			// do the following sequence three times
	digitalWrite(ledPin, HIGH);	// turn on the LED
	delay(300);			// leave LED on for.3 seconds -- short blink
	digitalWrite(ledPin, LOW);	// turn off the LED
	delay(200);			// leave LED off for .2 seconds
}
for(int i=0; i<3; i++){			// do the following sequence three times
	digitalWrite(ledPin, HIGH);	// turn on LED
	delay(700);			// leave LED on for .7 seconds -- long blink
	digitalWrite(ledPin, LOW);	// turn off the LED
	delay(200);			// leave LED off for .2 seconds
}
for(int i=0; i<3; i++){			// do the following sequence three times
	digitalWrite(ledPin, HIGH);	// turn on the LED
	delay(300);			// leave the LED on for .3 seconds -- short blink
	digitalWrite(ledPin, LOW);	// turn off the LED
	delay(200);			// leave the LED off for .2 seconds
}

This is a little better, but is still pretty redundant because each loop is still doing essentially the same thing (turning the LED on for a period of time, then turning it off for a period of time). We can further reduce the size of the code by making a custom 'tripleBlink()' function, which lets you specify how long the LED should be on and how long it should be off:

void tripleBlink(int time_on, int time_off){
	for(int i=0; i<3; i++){			// do the following sequence three times
		digitalWrite(ledPin, HIGH);	// turn on the LED
		delay(time_on);			// leave the LED on for time_on seconds
		digitalWrite(ledPin, LOW);	// turn off the LED
		delay(time_off);		// leave the LED off for time_off seconds
	}
}

Now our main code can just call the tripleBlink() function like so:

tripleBlink(300, 200);	// blink three blinks at .3 seconds each -- short blinks
tripleBlink(700,200);	// blink three blinks at .7 seconds each -- long blinks
tripleBlink(300,200);	// blink three blinks at .3 seconds each -- short blinks
delay(500);		// wait .5 seconds before repeating the process

This will reproduce our SOS blink pattern. The final complete sketch looks like:

int ledPin = 13;
void setup() {
        pinMode(ledPin, OUTPUT);
}
void tripleBlink(int time_on, int time_off){
	for(int i=0; i<3; i++){
		digitalWrite(ledPin, HIGH); 
		delay(time_on);	
		digitalWrite(ledPin, LOW); 
		delay(time_off); 
	}
}
void loop(){
	tripleBlink(300, 200);
	tripleBlink(700, 200);
	tripleBlink(300, 200);
	delay(500);
}

Go ahead and run this sketch; you should see your Arduino blink out a desperate SOS plea. Success! If you are interested in seeing what other functions the Arduino programming language supports natively, see the full reference at http://arduino.cc/en/Reference/HomePage. The Arduino web site also has some good introductory descriptions of basic concepts related to MCUs at http://arduino.cc/en/Tutorial/Foundations.

In the next article of our series, we will walk through getting an MSP430 MCU to blink out an SOS using the IAR Kickstart IDE.

- Wiretrip Hardhack Team

posted on 01 Mar 2009 | permalink | comment on this post

inside the Belkin desktop Skype phone

One of the hardhack team members recently purchased a Belkin Desktop Internet Phone for Skype (product ID F1PP010EN-SK). These phones are a self-contained unit that runs Skype natively without the assistance of a PC. We decided to take a peek inside the phone to see what we see. Unfortunately, this phone is meant for actual use, so we did not want to actually try to hook anything up to it (JTAG, etc.) or experiment with it at this time; maybe we'll buy another one in the future to dedicate to more devious purposes. At US$80 (Amazon, circa Dec 2008), it's not that expensive.

The main PCB of the phone is largely one sided, as the opposite side essentially just holds the button pads and the LCD screen. The lower-right side of the board (as pictured, below) holds the RJ45 Ethernet and power jacks, and the extreme left side holds the RJ11 phone handset jack and on-hook switch. The LCD is on the opposite side of the PCB (not shown), immediately right of the pictured speaker (the big circle thing, can't miss it).


 

IC/component markings are as indicated:

  • 1: Broadcom CPU, BCM1191KPGB. We couldn't find info on the BCM1191, but the BCM1190 is an VoIP-centric 32-bit CPU meant for residential ethernet IP phone devices. The BCM1191 might be a derivitive of the BCM1190 especially adapted for Skype.
  • 2: 256 Mbit DDR SDRAM, Qimonda HYB25DC256160CE-5
  • 3: Unknown IC, 809L1 A4890
  • 4: 32MB NAND Flash, Samsung 810 K9F5608U0D
  • 5: Ethernet transformer, TAIMAG HA-103
  • 6: Generic 74HC32D IC - Quad 2-input OR gate

There are only a few obvious connection locations. There are two unpopulated connector locations next to the existing RJ45 connector; the BCM1190 supports two Ethernet MAC/PHY, so it is very likely that the unpopulated 8-pin connector location is meant for the second RJ45 Ethernet connector. On the upper-left are two 20-point connection pads and a 4-pin connector. Perhaps the 20-point pads are MIPS JTAG (particularly the top one as pictured, below), and/or the 4-pin connector is a UART? Unfortunately it's a multi-layer PCB and the traces to these connection locations were not easily followable (they disappear into vias, under dense component clusters, etc.).


 

A simple nmap of the network-side of the device (when up and running, obviously) looks like: 

hardhack:~# nmap -sS -p 1-65535 -n -O 10.0.100.73
Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2008-12-30 22:51 EST
Interesting ports on 10.0.100.73:
Not shown: 65532 closed ports
PORT      STATE SERVICE
80/tcp    open  http
443/tcp   open  https
13230/tcp open  unknown
MAC Address: 00:1C:DF:80:05:AC (Unknown)
Device type: general purpose
Running: Linux 2.4.X|2.5.X|2.6.X
OS details: Linux 2.4.7 - 2.6.11
Uptime 49.709 days (since Tue Nov 11 05:50:56 2008)
Nmap finished: 1 IP address (1 host up) scanned in 20.660 seconds
The reported update is bogus, because the device was only powered on for about 2 minutes before this nmap scan was ran. You can see that a port 80 was listed; there is indeed a webserver running on it (default auth is user "admin" and no password). This brings you to a device page that allows you to update the device's firmware. Speaking of firmware, the product CD includes a GPL tarball with the basic GPL components of the device's firmware. A quick review of some of the files shows that it is indeed running Linux, and seems to be based on a generic platform called the Broadcom 'OnePhone', which is also apparently used for Wi-fi VoIP phones too (Samsung's SPH-V6900 was mentioned by name). There definately seems to be hacking potential.

Some minor hacking of the web CGI interface can cause it to dump a status blurb if you give it a bad page parameter. On our device, it lists the image as being "ota_BCM91103_vlinux-2.6.17.14_cramfs.bin", built on Jan 14 11:50:31 2008 and version 1_0_0L.

- hardhack team

posted on 31 Dec 2008 | permalink | comment on this post

.NET Micro Framework devices update

We received a lot of feedback on our original .NET Micro Framework device roundup, most of which was positive (bonus!). However, one re-occuring comment was that we didn't really do the devices justice when listing the features. We agree, as we kind of ignored what we didn't care about and listed a few items that wouldn't take up to much page space.

So we learned our lesson, and to make up for it, we went back and constructed a more thorough chart that detailed out many of the specs. This time around we focused only on the SSJ and GHI offerings, as they are the most practical choices when you factor in overall price.

IMPORTANT CHANGE: SSJ dropped the prices of the EDK and EDKplus; they also announced support for more of the components included with the devices. At this point, our personal opinion is the EDK is now by far the best value (fast CPU, lots of flash and RAM, and Ethernet), unless you really need native USB support.

So, with that, here is the chart:


SSJ EDK SSJ EDKplus GHI USBizi   GHI EM
Price (US $) 115 175 100 200
CPU Mhz 200 200 72 72
CPU Type ARM9 ARM9 ARM7 ARM7
Flash 8MB 8MB 512KB 4.5MB
RAM 8MB 8MB 96KB 8MB
RS232 port 1 (debug only) 2 (1 is debug only) - -
UART - - 4 4
Ethernet 1 1 - 1
CAN - - 2 2
GPIO lines 16 16 44 51
PLD output lines 16 16 ? ?
PLD input lines 8 8 ? ?
SPI yes yes yes yes
I2C ? ? no yes
PWM I/O 2 2 6 5
A/D input 5 x 16 bit 5 x 16 bit 7 x 10 bit 4 x 10 bit
D/A output ? ? ? x 10 bit ? x 10 bit
MMC/SD socket yes yes yes yes
USB host port 2 (no .NET support) 2 (no .NET support) 1 1
USB device port - - 1 1

posted on 07 Dec 2008 | permalink | comment on this post

we can hear your keyboard

We've long hypothesized that wireless keyboards are just simply insecure, period. The odds that the wireless keyboard vendors use cheesy RF signaling in the clear (or with a weak smattering of FHSS) are just too high to really convince ourselves that wireless keyboards are worth the insecurtiy they likely harbor. It could be as simple as taking the receiver of an identical model keyboard and tuning it to receive the keyboard signals (depending upon how the devices sync; you have better odds of this working if you get a setup that requires you manually select a 'channel' to use). Of course, we're talking proprietary RF 'protocol' (we use that term loosely) and not Bluetooth, although there are those that would still not sleep well at night with Bluetooth either...

Anyways, imagine our surprise when we wandered across this. These guys are sniffing EM from wired keyboards (not wireless)! Usually we leave TEMPEST activities to the three letter agencies, but this is just scary. It's probably just a matter of time before this becomes accessible to the mainstream. I did notice that the demo video shows massive latency between when the keys were pressed and when they were decoded/shown on the receiving PC; that makes me believe the signals need to be captured and buffered, and then post-processed. It's probably just a matter of time until this becomes real-time. Joy.

Maybe we just ditch keyboards and stick with mice and touch screens. I rather like my tablet PC, actually.

posted on 21 Oct 2008 | permalink | comment on this post

.NET Micro Framework: Bringing BSoD to embedded devices

Microsoft has ported (a subset of) the Microsoft .NET Framework over to embedded devices running on ARM or Blackfin processors. The .NET Micro Framework basically is just the .NET CLR compiled to different platforms, and then the .NET IL assemblies can be executed on top of the CLR, just like any other .NET execution process. The main support for the .NET Micro Framework seems to focus on the C# language. Wikipedia has a good overview of the details of the .NET Micro framework.

Despite our jesting in the title, we are actually a bit intrigued by the .NET Micro Framework. Many hardhack contributors are seasoned C# programmers, so the idea of using C# for desktop apps, smart phone apps, and now embedded devices drastically unifies the toolchains needed. You do need a full version of Visual Studio to support .NET Micro Framework--the free Express editions will not work.

We decided we wanted to take the plunge into .NET Micro, but first we needed to find a suitable development board. After a bit of research, we compiled the list of the following candidates:

DeviceSolutions Tahoe .NET Micro Framework Dev Platform
Price: US$399.00 (Oct/2008)
Specs: Freescale i.MXS 100Mhz ARM920T CPU, 4MB Flash, 8MB SDRAM
Features: 2.7" LCD, push buttons, serial
Notes: Optional Ethernet add-on for US$49.00
Product page: http://devicesolutions.net/Products/Tahoe.aspx

Digi Connect ME JumpStart Kit
Price: US$299.00 (Oct/2008)
Specs: 55Mhz NS7520 CPU, 2MB Flash, 8MB SDRAM
Features: serial
Product page: http://www.digi.com/products/model.jsp?lid=EN&pgid=90&pfid=122&mtid=2256&amtid=2256&pm=Y

Digi ConnectCor 9P JumpStart Kit
Price: US$499.00 (Oct/2008)
Specs: 150Mhz NS9210 CPU, 4MB Flash, 8MB SDRAM
Features: 2x serial, ethernet
Product page: http://www.digi.com/products/model.jsp?lid=EN&pgid=90&pfid=122&mtid=2749&amtid=2749&pm=Y

SJJ Micro EDK
Price: US$165.00 (Oct/2008)
Specs: CL EP9302 200Mhz ARM9 CPU, 8MB Flash, 8MB SDRAM
Features: ethernet, 2x USB host, 5 chan 16 bit A/D, 2x PWM, MMC/SD socket
Notes: no battery-backed RTC; all features may not be supported
Product page: http://www.sjjmicro.com/EDK.html

SJJ Micro EDKPlus
Price: US$225.00 (Oct/2008)
Specs: CL EP9302 200Mhz ARM9 CPU, 8MB Flash, 8MB SDRAM
Features: serial, ethernet, 2x USB host, 5 chan 16 bit A/D, 2x PWM, MMC/SD socket
Notes: battery-backed RTC; all features may not be supported
Product page: http://www.sjjmicro.com/EDK.html

GHI Electronics USBizi
Price: US$99.95 (Oct/2008)
Specs: 72Mhz ARM7 CPU, 512KB Flash, 96KB RAM
Features: USB host/device, 2x CAN, SD socket, 6x PWM
Product page: http://www.ghielectronics.com/details.php?id=113

GHI Electronics Embedded Master Dev System (non-TFT)
Price: US$199.95 (Oct/2008)
Specs: 72Mhz ARM7 CPU, 4.5MB Flash, 8MB SDRAM
Features: 128x64 display, ethernet, USB host + device, serial, CAN, SD card, 7 buttons
Product page: http://www.ghielectronics.com/details.php?id=107&sid=114

Overall, the SJJ kits seem to have a nice collection of hardware features bundled with them; however, it seems that the firmware they provide may not be compatible with all the hardware...so it would be unusable. That makes us concerned. Thi GHI USBizi is very affordable and has CAN (cool!), but no ethernet and very little Flash/RAM; it would only be good for minor apps...but still perhaps a good starter. The GHI Embedded Master has ethernet and better RAM and Flash than the USBizi counterpart, but it's still only a 72Mhz ARM7 CPU. Choices, choices... If the Embedded Master had a 200Mhz ARM9 processor, we would feel it would be the clear choice.

At the end of the day, we decided to look into the GHI devices. Look for future posts were we talk about the devices and give you our hands-on observations.

posted on 04 Oct 2008 | permalink | comment on this post