Announcement

**TheCotMan** · August 3, 2010, 22:16

Re: Connecting to DefCon 18 Badge

Originally posted by mykill View Post

I can't connect to the DefCon 18 Badge with minicom on Linux or with PuTTY or TeraTerm on Windows. My exact efforts (and failures) are documented below.
...
Using minicom on Linux
After plugging the device into Linux, I ran dmesg and learned that it was present as /dev/ttyUSB0. I configured minicom to connect to that device. In minicom,...

Don't know about the badge as I don't have one and have not connected to it. However, when USB devices are detected, there is a process by which a flatfile database (or other database) is used to compare information claimed by a device and vendor to known and supported usb devices. After this, the appropriate kernel modules are usually installed.

A device name of /dev/ttyUSB0 sounds really generic. About 7 years ago, when adding USB-based "old fashioned serial port" dongles and using PCMCIA-based serial devices for modems, new serial devices showed up as /dev/ttyS[0-9]+ with the first 4 used by COM1, COM2, COM3, COM4 (using their MS-DOS names) while the first USB serial port devices started at around 16 for /dev/ttyS16... The number that they start using will likely depend on the distribution you are using.

Have you checked to see if all of the necessary kernel modules for supporting serial over USB for the badge's USB-to-serial device are loaded and supported? Are there any new devices in the "ls /dev/ttyS*"?

Hope this helps.

**fresh** · August 3, 2010, 23:07

Re: Connecting to DefCon 18 Badge

Try "screen /dev/ttyUSB0"

**YenTheFirst** · August 3, 2010, 23:47

Re: Connecting to DefCon 18 Badge

I second the recommendation of screen. I've discovered changing the badge mode, after the device connects but before sending '#', tends to help.

here's a bit of ruby code I wrote to connect, I can post the larger file if desired. It seems to work pretty much 100%.

Code:

@file = File.open("/dev/ttyUSB0",File::RDWR | File::NOCTTY | File::NONBLOCK)
@file.sync=true
p "change the badge state at least once, then press enter"
gets
@file << "#"

**thumper17** · August 4, 2010, 00:21

Re: Connecting to DefCon 18 Badge

On linux, /dev/ttyUSB0 is the right style name . Did you set all the communications parameters?

In the configuration section of minicom, you want to do the following:
* Comm parameters: make sure the serial device is /dev/ttyUSB0, and use 9600 8N1, no hardware flow control, Yes software flow control (this is what Xon/Xoff is).
* under "Modem and Dialing", just erase the Init string and Reset string; they don't do anything useful for talking to the badge.
Then be sure and save your setup so that you don't have to do this configuration each time. The mistake I always make in using minicom is thinking that "minicom /dev/ttyUSB5" means that it's talking to /dev/ttyUSB5 -- if you look in the config, you'll find some other device mentioned typically, unless you've previously modified and saved the config.

Under windows XP, I used HyperTerminal with similar settings. To find the right COM port, I unplugged the badge and restarted hyperterminal to find out which COM port was deleted.

**YenTheFirst** · August 4, 2010, 09:58

Re: Connecting to DefCon 18 Badge

I haven't tried with minicom, but I've double and triple checked my steps. Here's exactly what I did, and it's worked just now 3 times in a row.

plug in badge. dmesg should tell you the FTDI device is attached to /dev/ttyUSB0. You can do "stty -F /dev/ttyUSB0 -a" to ensure the settings are correct, but they should be correct by default.
run the command 'screen /dev/ttyUSB0'
change the badge mode (i.e., if it's on the 'defcon' screen, hit the top button and move it to the 'grand idea studio' screen)
in screen, type '#'. you'll get the message.
type 'CU'. you'll get two acks, and the screen will clear.
hit 'X'. you'll get an ack and the screen will go back to 'defcon'
unplug. screen will close

you CANNOT skip the 'change badge mode' step, and get any sort of reliability. I tried it, skipping step 3, and it didn't work. I then changed the badge mode, and it worked. I'll post an analysis from the source code in a bit.

Additional hint: if you try to open up the /dev/ttyUSB0 as a file in a program (which you'd have to do for more than simple scripting), make sure you set the file to sync after every write, or manually flush it after every write.

edit: an analysis of the source code.
this is all in DC18_Badge.c

in the 'main loop' (void dc18_badge(void)):
'case USB', which prints the message, is on lines 144-188
to switch to 'case USB', we check the status of whether we've received the character '#'. on lines 211-215
but, that's wrapped up in the if statement that checks whether the USB is plugged in on lines 202-216.

Code:

[line 202]
   	if (!gUSB_EN) // if we are running on battery power...
   	{ 
    	LED1_PutVal(OFF); // turn off USB indicator LED
    	dc18_sleep(); 		// sleep until external interrupt
		}
		else // USB is plugged in, so stay awake to receive and process commands
		{
    	LED1_PutVal(ON); 				 // turn on USB indicator LED
 			
			if (Term_KeyPressed()) // if there's a byte waiting in the rx queue...
			{	
				Term_ReadChar(&c); 	 // ...then get it
				if (c == '#') badge_state = USB; // enter USB mode if requested
			}
    }

so, in theory, when we get to line 202, if we're plugged in, we'll fall through to line 211, and check for the '#'. if we get it, we'll go into USB mode. What's the problem?
the problem is the first half of the if statement. if we're not in USB mode, when it hits that, it will go into dc18_sleep(), where the CPU sleeps until it gets external interrupt. however, plugging in the USB doesn't count as an interrupt! only SW_0 and SW_1 will wake the CPU!

Code:

(in dc18_sleep())
line 520	Cpu_SetWaitMode(); // Awake on the next external interrupt from SW0 or SW1

so, what we have to do is: plug in the USB, then wake the cpu with a button press. dc18_sleep() will exit, we'll run around to the end of the main loop, start it again, and when we hit line 211, we'll see the USB plugged in. so, we'll skip the first part of the if statement, NOT go to sleep, and keep looping until we get a '#'. when we do, we've entered USB mode, and on the next loop we'll enter line 144, and loop there until the USB mode is left.

**mykill** · August 4, 2010, 13:23

Re: Connecting to DefCon 18 Badge

I checked in, read some of the replies, and quickly gave it a shot using GNU screen, which works perfectly.

I'll catch up on the rest of the thread after work today, I see a lot of interesting information above. Thanks so much for the insightful suggestions and explanation.

Cheers!

-M.

**TheCotMan** · August 4, 2010, 13:38

Re: Connecting to DefCon 18 Badge

Thanks for the confirmation about /dev/ttyUSB[0-9]+ as that is new to me. I've not needed old-fashioned serial over USB for several years now. The rare case I've needed old fashioned serial, I had a DB9 port with motherboard integrated serial support.

Moving this to the "badge hacking forum" as other people will probably look there for similar information. I'll leave a permanent redirection/shortcut here for people to find where I moved it.

**elegin** · August 4, 2010, 16:57

Re: Connecting to DefCon 18 Badge

There are 2 ways to connect to the badge and 3 ways to modify it. You connect via usb cable and the USB TAP (JTAG).

I will explain how put a temp image on the badge via usb cable and give some code.

First you need an image. All this will be completed under linux. I have perfermed this with Backtrack4 and ubuntu. You need an image. On the defcon disk are some Kent exe's. They can install and work under wine. It needs an image exactly 132x64. The Kent display will only show 132x32 and it must be single color bmp. All this can be done under GIMP. Hint: resize your image to 132x32, convert to 1color bmp, then resize the canvas to 132x64.

Here is a perl script that will convert the .c file to a nicer format for the kent display and also the correct format to insert in the source code for permanent changes.

Code:

#usage:
# ./fix_c_bmp.pl <input > output
# example.. my gimp created images is named elegin.bmp 
#           the kent 132x64 BMP to C app will create elegin.c
#  ./fix_c_bmp.pl <elegin.c > elegin.defcon
# crappy script by elegin
#!/usr/bin/perl -w
use strict;
my $line;
my $i=0;
my $j=0;
my $n=0;
my @f;
while (defined($line=<>)) 
{
if($j<51 && $j>6)
  {
  if ($i ==10)
    {
      $line =~ s/^   //g;
      @f=split(/ /, $line);
	#12 pieces
	while($n < 7)
	{
	      if($j==43){$f[$n]=~ s/,//g; print " $f[$n]";}else{
	   print " $f[$n] ";}
	   $n++;
	}
	 print "\n";
     $i=0; 
     $n=0; 
    }else{
      print $line;
      $i++;
    };
     $j++;
 }else{$j++;};
}

To load the image to the screen the following perl script will do just that. Credit goes to grymoire for this..I am not 100% sure if this is his orginal code..I made some changes here and there but I reverted some back..I lost his orginal..he mentioned that he was going to post his script ( I couldn't find his handle so I am just posting and giving him credit)

Code:

#!/usr/bin/perl -w
#usage ./defcon_badge.pl <input >/dev/ttyUSB0
#  input would be the output of fix_c_bmp.pl 
# example ./defcon_badge.pl <elegin.defcon >/dev/ttyUSB0
# Read from the inputfile
# and write to the device
# code by Bruce/grymoire
 
# First let's get the parsing of the input
# This is in ASCII, represending HEX values
# separated by lines and commas
use strict;
use bytes;
$|=1;
my $line;
my @a;
my $i;
my @f;
my ($x, $y);
$x=0;
$y=0;

printf("#");
sleep(1);
printf("C");
sleep(1);
while (defined($line=<>)) {
    chomp $line;
    $line =~ s/,//g;
    $line =~ s/  / /g;
    $line =~ s/^ //g;
    @f=split(/ /, $line);
    if (1) 
    {
	    foreach $i (@f) 
      {
	        if (length($i)==4) 
          {
    	    	my $t=hex($i);
          #	printf(STDERR "$i=$t\n");
    	    	printf("L%c%c%c", $y, $x, $t);
    	    	$x++;
    	    	if ($x >=256) 
            {
  		        $x=0;$y++;
            }
		
	        }
	    }
    }

}


printf("U");
sleep(1);

if you hit tab at /dev/ttyUSB you will see which device is a available..

This is only for a temp image to the display it will clear when reset.

I will write up separate instructions for permanent change to images later..if it is need or not if someone else does it.

Both other ways to modify the badge windows XP is needed with freescale codewarrior IDE installed.

**thumper17** · August 4, 2010, 17:25

Re: Connecting to DefCon 18 Badge

Originally posted by YenTheFirst View Post

I haven't tried with minicom, but I've double and triple checked my steps. Here's exactly what I did, and it's worked just now 3 times in a row.

plug in badge. dmesg should tell you the FTDI device is attached to /dev/ttyUSB0. You can do stty -a /dev/ttyUSB0 to ensure the settings are correct, but they should be correct by default.
run the command 'screen /dev/ttyUSB0'

Neato burrito -- I didn't know 'screen' could do that.

I just tried the "stty -a /dev/ttyUSB0" command, but it just tells me "when specifying an output style, modes may not be set". I am using Ubuntu 9.10.

Oh wait, I just read the man page. The command is actually "stty -F /dev/ttyUSB0 -a".

**thumper17** · August 4, 2010, 18:15

Re: Connecting to DefCon 18 Badge

So, I've always uploaded my code using HyperTerminal from Windows XP running inside of VMware. After reading the messages in this thread, I thought it would be cool to try uploading directly from Linux, but it isn't working for me.

screen: how do you upload a file via screen?
minicom: I've tried both "Paste File" and "Send File (ascii)", and both give me "Error: 3002".

What am I missing? For now, I'm just trying to upload the cd18-with-boot.s file from the CD.

**YenTheFirst** · August 4, 2010, 22:36

Re: Connecting to DefCon 18 Badge

Originally posted by thumper17 View Post

screen: how do you upload a file via screen?
minicom: I've tried both "Paste File" and "Send File (ascii)", and both give me "Error: 3002".

What am I missing? For now, I'm just trying to upload the cd18-with-boot.s file from the CD.

I'll have to try it to be sure, but my intuition is that if the badge was in bootloader mode, you should just be able to do 'cat file.elf.s > /dev/ttyUSB0'.
(apparently bootloader mode involves removing the battery, and holding both buttons while inserting the cable)

also, thanks for the fixed stty command.

**mykill** · August 5, 2010, 20:20

Re: Connecting to DefCon 18 Badge

I just wanted to follow up by documenting the results I got: I bricked it!

After using GNU screen to access the badge, I was able to access it using minicom as well--strange. Perhaps the keypress issue was getting in my way before.

In any case, after hitting CU to see the device clear its FB and update the LCD, I set to sending drawing commands. I created a file with drawing commands using a hex editor, like so:

Code:

00000: 4c01 00ff 55             L...U

I sent the file by hitting CTRL-A followed by S in minicom, selecting ASCII, and choosing the file by name. After that, the screen refreshed and drew a very short line, which I decided was success.

Then I closed minicom, unplugged the badge, held down both switches, and plugged it back in. I waited a while, released the two buttons, opened minicom, and set minicom to upload sdm_pROM_xRAM.elf.S in ASCII mode. Similar to the previous post by Thumper17, I received the following output:

Code:

ASCII upload of "sdm_pROM_xRAM.elf.S"

0.0 Kbytes transferred at 32CPS!
PROGRAM&**
Error: 3002
Serial bootloader started.
12.7 Kbytes transferred at 1083 CPS

The transfer seemed to continue, so I let it go. Once it was finished, I pressed enter to acknowledge the completed transfer, unplugged the device, and closed minicom. Before doing so, I made sure that there was no need to close the connection or anything. Kingpin's directions read:

Code:

Send the hex file and the badge will do the rest...
• 9600, 8N1, Xon/Xoff
• /output/sdm_pROM_xRAM.elf.S
• Typical load time ~90 seconds

Ominously, the next slide in his presentation is titled: "In Case Of Bricking . . ."

After I unplugged and restarted the device, no longer responded to any input I could think of. LEDs light up when I plug it in, but it is unresponsive to the switches and to serial connections using screen and minicom. No worries though, I'll get a JTAG connection and fix myself with the original ROM at a later point. But first I will have to solder the surface-mount JTAG port onto my badge, as mine did not come with one, only the pristine solder pads where it belongs

**bradt** · August 5, 2010, 20:28

Re: Connecting to DefCon 18 Badge

Originally posted by mykill View Post

I just wanted to follow up by documenting the results I got: I bricked it!

A quick sanity check: did you really brick it, or can you still get it into bootloader mode? Just asking because I though I'd bricked it a couple of times, but I could still load images.

**thumper17** · August 5, 2010, 23:20

Re: Connecting to DefCon 18 Badge

Originally posted by bradt View Post

A quick sanity check: did you really brick it, or can you still get it into bootloader mode? Just asking because I though I'd bricked it a couple of times, but I could still load images.

I should have relayed the rest of my experience: I thought I had bricked my badge as well. It was definitely dead on "normal boot"; didn't respond to button presses or chars from terminal. And when I went into bootloader mode, the LEDs on back were dim.

Eventually, I went back into Windows and tried to load again with HyperTerminal. Even there I thought it was dead, because it didn't echo the '*' to the terminal when I tried uploading the image again. What finally put it back in the right mode was to unplug the badge, quit hyperterminal, then plug in the badge (as "bootloader") and restart hyperterminal and load the image again.

I don't have a good explanation for what changed, partly because it was late and my memory is fuzzy. But the moral here is to give it a try one or two more times if you think you've bricked it.

Announcement

[Defcon 18] Connecting to DefCon 18 Badge

[Defcon 18] Connecting to DefCon 18 Badge

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment