Dangerous Prototypes

Hey ya everyone. I picked up a BusbBlaster along with a JtagNT  and a BusPirate..

Is there any how-to's on pulling/writing firmware with any of the windows and or linux jtag software on known devices like lets say the DDWRT54G?

In my quest to learn about devices I want to know how difficult it would be to identify jtag points on a device then pull firmware off it and then write it back? I'm kinda going into this semi blind but I have always wanted to poke around with some radios I have and compare firmware modify it and put it back on the device, perhaps attempting to decompile it and make better sense of it would be good too??

I have instructions to jtag the linksys device with a JtagNT and their software but wouldnt mind trying this BusBlaster device using other software to know what errors to expect when I poke around with some unknown stuff.

Thanks.

check out the open_ocd website, and http://http://dangerousprototypes.com/docs/Bus_Blaster
data sheets are your best friend, start with a well documented project.
search the forum here for anything jtag related, you may get some ideas.

good luck

Hi CheezeWiz,

Thanks for letting us know the Bus Blaster arrived.

Is there any how-to's on pulling/writing firmware with any of the windows and or linux jtag software on known devices like lets say the DDWRT54G?

You best bet is probably the most popular Windows/Linux debugging app, OpenOCD. It supports the Bus Blaster as a "jtagkey" style programmer. There are a ton of OpenOCD tutorials out there, you might also see frank's example:
viewtopic.php?f=37&t=1979 (http://dangerousprototypes.com/forum/viewtopic.php?f=37&t=1979)

I don't know of any how-tos for that device, but lots of people develop on these routers so there is probably a community somewhere. I think usually only a small bootloader is programmed over JTAG, then most things can be done from a terminal/ftp/telnet/etc. The DDWRT forum might be a good place to start:
http://www.dd-wrt.com/wiki/index.php/What_is_DD-WRT%3F (http://www.dd-wrt.com/wiki/index.php/What_is_DD-WRT%3F)

how difficult it would be to identify jtag points on a device then pull firmware off it and then write it back?

Easy to impossible, depending :) There are a few ways to identify the jtag pins, I think the arduino tester was linked in a reply to your other post, that's probably the easiest I've seem. Reading and writing depends on the chip and the copy protection features that the manufacturer enabled. Many chips are code protected at the factory and cannot be read.

perhaps attempting to decompile it and make better sense of it would be good too??

It can be done, but you'll need to invest a lot of time with the datasheet learning the opcodes for the device, or find a reverse compiler and learn ASM.

I'll poke around with it all I suppose, Maybe I have a stupid question, Maybe I need to do more "RTFM" although

I got Urjtag installed do "cable help"
cable FT2232 <------- is this the correct one for the Busblaster? If so

Once I do "Detect" with nothing connected it says TD0 seems to be stuck at 1. so I jumper tdo and ground and still get that error.

Normal? not normal? should I go rtfm some more?... humor me :)

The bus blaster is a jtagkey type device, so try:

Cable jtagkey

Yeah I actually found that about 10 minutes ago before I read your post. The device still says TDO stuck at 1.
I jumper tdo and ground and it still says stuck at 1

Is this normal?

--A

OOH and when is the dso quad suppose to appear?

Try bridging TDO to TDI, but preferably connect a known JTAG target (do you have a Logic sniffer?).

I'm sorry, we're not affiliated with the DSO quad and I don't know anything about it.

Hi Ian,

Bridging TDO and TDI shows the same output.

I connected this to a DDWRT and the output is the same. Is there any other way I can test this BusBlaster?

I'm going off this image and have jumpers connected as shown. The only connections in question  are
nSRST is going to TSRST on the BusBlaster and nTRST is going to TRST on the busBlaster.

and ground is any one of the pins on the far right if the usb port is on the left.

just keep hitting detect in UrJtag and says TDO Stuck at 0 .... Kinda running out of ideas.

--A

The error means that nothing is responding to the chain scan. It is normal if there is no JTAG device connected. Does this target work with your other JTAG debugger?

What is powering the buffer? There must be an external voltage from the device under test on the VTG pin.

Yes this works with my JTagNT. I'm guessing its my lack of knowledge in the subject and my effort into diving into things head first, but is there a way to test jtag adapters via a loop-back of sorts?

As for what's powering the buffer "Not sure what you mean" In my setup I have the router powered up with the jtag pins attached to the BusBlaster. I did some reading on what the VTG pin is, "Voltage Target Detect" is this something that needs to be jumpered? or does a wire need to be connected to it then onto another pin on my target device?

I'm not familiar with the VTG pin... I'm potentially guessing that its a bus blaster specific thingy?


Thanks,
--Aaron

The Bus Blaster talks to the device at the device's native voltage. For example the Logic Sniffer is a 2.5volt JTAG device, when you feed 2.5volts into the VTG pin it runs the buffer at 2.5volts.

You should connect the VTG pin to the power supply that runs the JTAG interface on your device under test. If it is 3.3volts, put 3.3volt to vtg, if it is 2.5volt, use 2.5volts, etc.

Many times a JTAG header has a pin where you can tap the JTAG supply for running the programmer buffer.

Oh, Okay so that makes sense, I always wanted to know what the difference was between a buffered and un buffered jtag device

I guess I should poke around the board and find a suitable pin to pull the correct voltage off, I guess I thought that's why you ground the jtag device so you have a ground reference pin and the other pins monitor the voltage differential on the other pins.

Hey there Ian, I was able to get this working, I found a hole that had 3.2volts and once I connected it, the target LED lit up on the bus blaster. So thanks :)



So I was going though the list of stuff "I'm new to jtaging something that really isn't documented" SO that above image can you tell me what the values on the right are, 1, 594, 32, 594, 32 are??

I'm guessing this is jtagable hardware on the chain that you can debug??pull firmware/write firmware too??

Anyway THANKS for the help thus so far.
--A

can you tell me what the values on the right are, 1, 594, 32, 594, 32 are??

I guess the length of each instruction register on the board? As far as I know you need a BSDL file to define how to interact with each of these registers. I have never used that command, maybe you could ask urJTAG (or check the urJTAG docs).

What did the output of the chain scan (detect) look like?

I'm guessing this is jtagable hardware on the chain that you can debug??pull firmware/write firmware too??

It may be debuggable, but as far as I understand you will need the BSDL files at minimum (either download or create from scratch with this scan command I guess). There are a number of ways to debug ARM chips, but some chips will only work with manufacturer''s tool, and some are locked down to prevent tampering.

As far as I know, the only way to program with urJTAG is to use an SVF file. These are usually prepared directly from the manufacturer's (or 3rd party) development software. There is no generic jtag read or program operation. Also, I don't know if it is possible to read out with urJTAG at all, you'd need a SVF that did the read action, but I don't know if urJTAG has the ability to save the result of SVF actions to a file.

I see, well I'm not really trying to debug  it, Mainly concerned with pulling flash off the device and putting it back, perhaps using a hex editor and comparing changes.

Is there a way I can do this without knowing really anything about the hardware , kinda attacking the problem blind?

So far this is what I'm planning on doing, since I have documentation about pulling firmware off the wrt54g with the JtagNT and its software I want to try it with Urjtag software and compare flash results to make sure its the same I probably wont have access to the bsdl files and svf files so that's a no go "Unless you said theres a way of creating them from a scan?? if so GENIUS good news for my project" But I thought pulling flash off a device was somewhat of a generic item? I can read flash type or have a general idea how big the flash is couldnt I just like trial and error the number since flash sizes are pretty generic.. perhaps?


However It would be awesome to start viewing ram while the device is running, like how you can edit memory address in emulators to cheat, I'm guessing the bsdl files break up memory so you can view each chips memory/data within the jtag chain?


So I wonder if anyone has any idea what that DR length is... Again I want to learn about this so later when I start attempting to learn about other unknown jtag targets, maybe I'm missing the big picture but is there any generalized documentation that anyone knows about?

Is there a way I can do this without knowing really anything about the hardware , kinda attacking the problem blind?

Not as far as I know. You'd need to know at least some stuff about the hardware and similar devices to base your guesses on. This isn't a strong field for me though, I bet there are a bunch of DDTWRT and TJTAG forum members who know exactly how to do this stuff with thier eyes closed.

An important thing to remember about JTAG is it only defines some wires and that a instruction (IR) and data (DR) register existing in the chain. Everything else is proprietary to the chip. There isn't a 'scan and read' JTAG command. Rather, you load the read command for a specific chip into the IR then read some data from DR. The exact way to do that is totally different among chips.

Here's a tutorial I wrote on JTAG, scroll down about half way for illustrations:
http://hackaday.com/2008/12/01/bus-pira ... -and-more/ (http://hackaday.com/2008/12/01/bus-pirate-firmware-update-v0c-jtag-and-more/)

So far this is what I'm planning on doing, since I have documentation about pulling firmware off the wrt54g with the JtagNT

The jtagNT app must have some form of definition file or BSDL file to interface the router, in all likelihood you can reuse it. I would guess that OpenOCD and urJTAG and TJTAG are the preferred tools of router hackers, I think there are probably tools and tutorials to get you started, I'm just not familiar with them.

However It would be awesome to start viewing ram while the device is running, like how you can edit memory address in emulators to cheat, I'm guessing the bsdl files break up memory so you can view each chips memory/data within the jtag chain?

Exactly, they define each register location within the chip (and more, but that is a good starting point).

So I wonder if anyone has any idea what that DR length is...

It depends on the device, this is the kind of info that would be in the BSDL file.

is there any generalized documentation that anyone knows about?

I would highly recommend a specialized forum like DDTWRT. They have a passion for this stuff and know it inside and out. I just like to make open source hardware to support their cause. I can build the tools, but this is one particular use that I'm not yet skilled at.

I see some very good info! I would really like to try that JtagEnum software on the Arduino but rather use a Mega "I have zero knowledge to these"


And scan for jtag pads.

What is the feasibility of
1) Finding jtag pads
2) pulling firmware off a flash chip?


Are these 2 things just giant leaps?

I'm not sure how the jtag NT does it, but when I do a -Detect in the software it probably compares it with a config file for the chip and lists it in plain text? probably the same thing with Urjtag right? an unknown chip will just spit out a binary id "if the jtag is connected correctly, and the Urjtag does not support the chip" am I spot on?

--A

What is the feasibility of
1) Finding jtag pads
2) pulling firmware off a flash chip?

With the Arduino app I would guess it is pretty likely that you can find the pads. I know nothing about it though, so I can't really give you a solid answer.
Pulling firmware depends on the chip, protocol, etc. Do you have a part number and datasheet for the chip? I can take a look at it.

I'm not sure how the jtag NT does it, but when I do a -Detect in the software it probably compares it with a config file for the chip and lists it in plain text? probably the same thing with Urjtag right? an unknown chip will just spit out a binary id "if the jtag is connected correctly, and the Urjtag does not support the chip" am I spot on?

That is my assumption too. The BSDL files are plain text files, urjtag uses them directly or in a processed format. For unknown chips usually the IR from the chain scan is shown.

Hey Ian,

First off, you have been THE most informative person I have ever spoken with on a forum.

Well one of the chips is a St19af08 , appears to be some smartcard mcu <-- I can find a 2 page data sheet that tells me nil :( no pinout info.
STA801  <-- DSP for sat radio also trying to find the pinout info on this.
STA855 "BGA" <--- no pinout info either
STA210 No pinout info
And these 2 chips..

Also the link you posted a couple posts back on hackaday I like this info! I wish there was more documentation on the bus pirate and how to do certain things although this is a good start for me to poke around with it! digging it. I did get a kick out of the laundry card hack where the person makes his card hold 99.99

Reason why I wanted the bus pirate was for things like these http://http://life-is-a-hack.blogspot.com/2010/07/free-laundry-for-everybody.html

--A

Hi A,

We don't endorse free laundry hacks, but I'm glad you found it interesting :)

There are a bunch of demos and documentation on the wiki:
http://dangerousprototypes.com/docs/Bus ... nstrations (http://dangerousprototypes.com/docs/Bus_Pirate#Chip_demonstrations)

Hey CheezeWiz,

I do not usually use OpenOcd except for IXP targets, but I did connect a WRT54Gv4, just to test with IAN's Ft2232H breakout board, the BBv1 pinout may be a little different, I honestly have not looked. Anyway, here is the opnocd-5352.cfg file I'm using with the current trunk:

telnet_port 4444
gdb_port 2001

#interface
interface ft2232
ft2232_device_desc "TJTAG-PRO USB FT2232H A"
ft2232_layout "jtagkey"
ft2232_vid_pid 0x0403 0x8a98
jtag_khz 1500



#jtag scan chain
# format    L IRC  IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
#jtag_device 8 0x01 0x7f 0x1e

if { [info exists CHIPNAME] } {	
   set  _CHIPNAME $CHIPNAME    
} else {	 
   set  _CHIPNAME bcm5352
}

if { [info exists ENDIAN] } {	
   set  _ENDIAN $ENDIAN    
} else {	 
   set  _ENDIAN little
}

if { [info exists CPUTAPID ] } {
   set _CPUTAPID $CPUTAPID
} else {
  # force an error till we get a good number
   set _CPUTAPID 0x0535217F
}

gdb_memory_map enable
gdb_flash_program enable


#jtag_nsrst_delay 250
#jtag_ntrst_delay 250

#use combined on interfaces or targets that can't set TRST/SRST separately
reset_config srst_only
#reset_config srst_only srst_pulls_trst
#reset_config trst_and_srst separate
#reset_config trst_and_srst srst_pulls_trst
#reset_config trst_and_srst separate trst_push_pull srst_push_pull
#reset_config trst_and_srst separate


#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag newtap $_CHIPNAME cpu -irlen 8  -ircapture 0x1 -irmask 0x7f -enable -expected-id $_CPUTAPID

set _TARGETNAME [format "%s.cpu" $_CHIPNAME]
target create $_TARGETNAME mips_m4k -endian $_ENDIAN -chain-position $_TARGETNAME 

#$_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x80300000  -work-area-size 0x40000 -work-area-backup 0

#flash bank <driver> <base> <size> <chip_width> <bus_width>


flash bank 0 cfi 0x1fc00000 0x200000 2 2 0


#$_TARGETNAME configure -event halted { script bcm5352.script }

and this is my output, I have not tried flashing with this yet.

openocd -f openocd-ftdi-5352.cfg
Open On-Chip Debugger 0.5.0-dev-00808-g68bd107 (2011-03-28-19:00)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1500 kHz
srst_only separate srst_gates_jtag srst_open_drain
Warn : use 'bcm5352.cpu' as target identifier, not '0'
Info : max TCK change to: 30000 kHz
Info : clock speed 1500 kHz
Info : JTAG tap: bcm5352.cpu tap/device found: 0x0535217f (mfg: 0x0bf, part: 0x5352, ver: 0x0)

You will need to change vid/pid and also set _CPUTAPID 0x0535217F in the .cfg file.

P.S. also need to change ft2232_device_desc "TJTAG-PRO USB FT2232H A"

Hope this helps a little.

Regards,

Tornado

Ian,

I didn't think anyone condoned hacking but Ive always liked ripping into things like that, seem to be the most exciting, however I do it for myself not for others, the buck stops at me.


Tjtag,

I think maybe I did not explain myself as to my intentions towards the DDWRT.
Basically since the wrt has a lot of documentation I thought Id take the wrt as an example and jtag it with the BusBlaster and attempt to pull firmware off and write it. Maybe its possible that the bus blaster was something un necessary in my poking around / hacking arsenal of tools. My main goal is to jtag targets that really don't have any or a whole lot of documentation and pull firmware/hex edit it/ then put it back onto the device for new features or simply the fact to do it and see if what I want to happen happens really.

I have a JtagNT as well as its software and it seems to work on the ddwrt very easily as it has config files for it "-Detect, ldram "address" "size in bits" and it pulls the data off it. Ian mentioned that BDSL files are used in jtag for communication with chips, so JtagNT software probably has that on the back end of things.

So maybe its a lack of windows software that does this for the bus blaster? I haven't really seen a whole lot of documentation on the bus blaster and maybe its too new

Maybe it was my mis-understanding :)

Regrads,

tornado@dd-wrt.com

No no I explained it wrong, I have yet to try OpenOCD so I'll use your info and poke with it, I am new to JTAG in terms of the debugging aspect, as for Jtag pulling/writing firmware, I thought that's the only use for it.

Hope that makes sense.

As for debugging the DDWRT what exactly can you do with the Ejtag when DDWRT is running on it? poke a memory address so that its transmitting at 251mw vs the default without going into the router config and applying it?

or is it more for checking ...............I drew a blank here.

--A