Difference between revisions of "Bus Pirate"
m (→7816-3 T=0) |
m (→7816-3 T=0) |
||
Line 173: | Line 173: | ||
|align="right" | 9637 |
|align="right" | 9637 |
||
|align="right" | 414 |
|align="right" | 414 |
||
− | | |
+ | | (416 of 9600 mode works too) |
|- |
|- |
||
! Vasco DP810 |
! Vasco DP810 |
||
Line 179: | Line 179: | ||
|align="right" | ~2734 |
|align="right" | ~2734 |
||
|align="right" | 1400 |
|align="right" | 1400 |
||
− | | |
+ | | (works better than BRG=1462) |
|- |
|- |
||
! Vasco DP840 |
! Vasco DP840 |
||
Line 185: | Line 185: | ||
|align="right" | ~2734 |
|align="right" | ~2734 |
||
|align="right" | 1400 |
|align="right" | 1400 |
||
− | | |
+ | | (works better than BRG=1462) |
|- |
|- |
||
! Gemalto PC USB-SL |
! Gemalto PC USB-SL |
||
Line 191: | Line 191: | ||
|align="right" | ~11224 |
|align="right" | ~11224 |
||
|align="right" | 365 |
|align="right" | 365 |
||
− | | |
+ | | (works better than BRG=355) |
|- |
|- |
||
|} |
|} |
Revision as of 13:39, 12 November 2010
Description
I'm talking about this beast
Installation
My udev rules
I added a /dev/bus_pirate symlink by following this post:
$ ATTRS=$(sudo udevadm info -a -p \ $(sudo udevadm info -q path -n /dev/$(dmesg|\ grep "FTDI.*attached"|\ tail -n 1|\ grep -o "ttyUSB[0-9]\+"))|\ egrep "ATTRS{(serial|idVendor|idProduct)}"|\ head -n 3) $ echo "SUBSYSTEM==\"tty\"" $ATTRS "SYMLINK+=\"bus_pirate\""|\ sudo tee /etc/udev/rules.d/91-usb-buspirate.rules
If you've problems with modem-manager trying to access the device (as seen in /var/log/syslog), you can add the following rule:
ATTRS{idVendor}=="0403" ATTRS{idProduct}=="6001" ENV{ID_MM_DEVICE_IGNORE}="1"
Firmware upgrade
My bus pirate is a hardware v3b, firmware v4.1 and boodloader v4.1
To upgrade those two last ones:
Latest stable firmwares are available here
Let's take Bus.Pirate.firmware.v5.9.zip
And for the bootloader we'll follow this procedure, using this zip
To use the uploader, see here
$ screen /dev/bus_pirate 115200 Type "$" to enter bootloader mode Press ctrl-a \ y to quit screen $ ./pirate-loader_lnx --dev=/dev/bus_pirate --hex=BPv3-bootloader-upgrade-v4xtov4.3.hex $ screen /dev/bus_pirate 115200 Type "yes" to upgrade bootloader Press ctrl-a \ y to quit screen $ ./pirate-loader_lnx --dev=/dev/bus_pirate --hex=BPv3-Firmware-v5.9.hex Unplug/replug
Firmware v5.9 extra contains a few more things but only those modes:
Firmware v5.9 (r529) [HiZ 2WIRE 3WIRE KEYB LCD DIO]
While for normal firmware:
Firmware v5.9 (r539)
Usage
CLI
screen /dev/bus_pirate 115200 i Bus Pirate v3 Firmware v4.2 Bootloader v4.2 DEVID:0x0447 REVID:0x3043 (B5) http://dangerousprototypes.com HiZ> ctrl-A \ (y) to quit
Pinouts
See also http://dangerousprototypes.com/category/pin-reference/
WARNING in the nice sticker colorscheme, the cable is put upside-down (it's said in the comment but I missed it completely the first time)
So if you put your cable going "outwards of the PCB", as seen in the introduction picture, pinout is the following:
GDN - brown, black EZhook +3.3 - red +5 - pink, red EZhook ADC - yellow Vpu - green AUX - blue CLK - violet MOSI - grey CS - white MISO - black
We can perform a self-test with the cable by connecting together red+yellow and pink+green, then simply run "~" on the CLI.
Logic analyzer
See http://dangerousprototypes.com/docs/Logic_analyzer_mode
Installing SUMP is not that easy...
I chose to try a fork of it mentioned in the comments of Sump PC client page
wget http://dl.dropbox.com/u/1026013/Java/Logic%20Analyzer/Logic%20Analyzer.zip unzip Logic%20Analyzer.zip sudo aptitude install libftdi-dev librxtx-java
I modified the runme as following for my Debian, and to be able to use a symlink to the runme:
#!/bin/bash
if [ -h $0 ]; then
DIR=$(dirname "$(readlink $0)")
cd "$DIR"
fi
java -Xmx256m -cp /usr/share/java/RXTXcomm.jar:analyzer.jar \
-Dgnu.io.rxtx.SerialPorts="/dev/bus_pirate" \
-Djava.library.path="/usr/lib/jni" \
org.sump.analyzer.Loader
Now trying it:
We've only to change the recording size to 4k or lower, other params should be ok
Pins & channels:
chan0 - CS - white chan1 - MISO - black chan2 - CLK - violet chan3 - MOSI - grey chan4 - AUX - blue GND - brown
See also other analyzers:
I also tried this fork: http://www.lxtreme.nl/ols/
and changed a bit the run.sh script to handle it through symlink :
if [ -h $0 ]; then
DIR=$(dirname "$(readlink $0)")
cd "$DIR"
BASEDIR=.
else
BASEDIR=$(dirname -- "${0}")
fi
Practice
7816-3 T=0
I wanted to sniff an ATR from an autonomous reader
ATR was 3B 67 00 00 00 00 00 00 00 90 00
But when trying with the UART mode, I couldn't get the proper bytes being decoded
Let's first have a raw trace to have a rough idea of the signal:
Using the logical analyzer on I/O, sampling 10kHz + a trigger on RST
ATR in bin I/O signal UART 2400 UART 9600 (and another PC-based reader) 3B 00111011 0.11011100.1111... <> 9D 10011101 <> 9F 10011111 67 01100111 0.11100110.1111... <> B3 10110011 <> B7 10110111 00 00000000 0.00000000.1111... <> 80 10000000 <> 00 00 00000000 0.00000000.1111... <> 80 10000000 <> 00 00 00000000 0.00000000.1111... <> 80 10000000 <> 00 00 00000000 0.00000000.1111... <> 80 10000000 <> 00 00 00000000 0.00000000.1111... <> 80 10000000 <> 00 00 00000000 0.00000000.1111... <> 80 10000000 <> 00 00 00000000 0.00000000.1111... <> 80 10000000 <> 00 90 10010000 0.00001001.1111... <> C8 11001000 <> 48 00 00000000 0.00000000.1111... <> 80 10000000 <> 00
=> none of the baudrates was correct enough
Clock of the autonomous reader (case 1) was 1.05MHz, and clock of the PC reader (case 2) was 4.31MHz (measured with an oscillo, bus pirate needs a CLK for one whole second to be able to measure the frequency)
smartcard baudrate = CLK / 384
So in case 1 => ~2734 baud and in case 2 => ~11224 baud
While usually T=0: 9600 bit/s, 8 data bits, 1 parity bit, 2 stop bits, no handshake and even parity, + inversion compared to RS232 signals
See UART doc: we need firmware >= 5.1 to have full BRG control
BRG calculations:
- baudrate=4000000/(BRG+1)
- BRG+1=4000000/baudrate
So case 1 => BRG=~1462 and case 2 => ~355
Let's try:
Case 1:
m3 10 1400 2 1 1 1 [
1461 produced some errors occasionally and I had better results with a slightly higher baudrate (2855 baud)
Case2:
m3 10 365 2 1 1 1 [
355 produced some parity errors occasionally and I had better results with a slightly lower baudrate (10929 baud)
So choosing the proper baudrate is extremely important when sniffing busses not using a standard baudrate!
We couldn't measure the CLK frequency very well so we had to do trial & error to find a suitable baudrate.
On some readers, CLK signal is kept running all the time, from insertion or during operation.
In that case, we can measure very precisely the frequency with the bus pirate: link CLK to AUX probe and press "f" (works both in HiZ or UART)
Here are some measures on various readers:
Reader | CLK | baudrate | BRG | |
---|---|---|---|---|
Dell RT7D60 | 4009216 Hz | 10441 | 382 | |
ACR38U | 4009216 Hz | 10441 | 382 | |
Vasco DP905 | 3700736 Hz | 9637 | 414 | (416 of 9600 mode works too) |
Vasco DP810 | ~1.05MHz | ~2734 | 1400 | (works better than BRG=1462) |
Vasco DP840 | ~1.05MHz | ~2734 | 1400 | (works better than BRG=1462) |
Gemalto PC USB-SL | ~4.31MHz | ~11224 | 365 | (works better than BRG=355) |