Bus Pirate

From YobiWiki
Revision as of 22:29, 8 March 2013 by <bdi>PhilippeTeuwen</bdi> (talk | contribs) (→‎udev rules v4)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Bus Pirate V3

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/76-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)

Hardware mod

I found the 2 greed LEDs of bus pirate v3b a bit weak especially through the plastic box so I replaced their resistors (1.1k) by resistors of 100 ohms.
It may vary with the exact LEDs in use with your board so don't assume 100 ohms will work on your own board!

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
The recommended SUMP-compatible client is ols (official page here)

I 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

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

Previously I also tried another 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

See also other analyzers proposed here

Practice

7816-3 T=0 at arbitrary baudrate

I wanted to sniff the exchange between an autonomous smartcard reader and a card.
I used my bus pirate first in logic analyzer mode then in UART mode.
Physically I had simply a fake smartcard linked to a passive reader slot, a bit similar to this device

First thing a smartcard is emitting when powered and reset is it's ATR (Answer-to-Reset)
ATR in this case is 3B 67 00 00 00 00 00 00 00 90 00 as seen by any reader

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
3B 00111011 0.11011100.1.1111... <> 9D 10011101
67 01100111 0.11100110.1.1111... <> B3 10110011
00 00000000 0.00000000.0.1111... <> 80 10000000
00 00000000 0.00000000.0.1111... <> 80 10000000
00 00000000 0.00000000.0.1111... <> 80 10000000
00 00000000 0.00000000.0.1111... <> 80 10000000
00 00000000 0.00000000.0.1111... <> 80 10000000
00 00000000 0.00000000.0.1111... <> 80 10000000
00 00000000 0.00000000.0.1111... <> 80 10000000
90 10010000 0.00001001.0.1111... <> C8 11001000
00 00000000 0.00000000.0.1111... <> 80 10000000

=> We see clearly (last columns) that bus pirate configured at 2400 baud is misinterpreting the bytes, it misses the first LSB and gets the stop bit as MSB.
The reason is that, compared to RS232, smartcards are following the external clock signal and one should use a quartz at 3686400Hz to get a proper I/O communication at 9600 bauds. (T=0: 9600 bit/s, 8 data bits, 1 parity bit, 2 stop bits, no handshake and even parity, + inversion compared to RS232 signals)


Clock of the autonomous reader was around 1.064MHz (measured with a Logic Sniffer, bus pirate needs a CLK for one whole second to be able to measure the frequency but the reader I'm using provides a clock only during operations)

smartcard baudrate = CLK / 372
(from ISO7816-3)
So in our case => 2860 baud

See UART doc (or bus-pirate-uart-guide): we need firmware >= 5.1 to have full BRG control

BRG conversions: (only valid for bus pirate, see PIC datasheets for others)

  • baudrate=4000000/(BRG+1)
  • BRG=(4000000/baudrate)-1

So in our case => BRG=1398

Let's try: 

m3     UART mode
10     BRG raw value
1400   see below
2      8 bits, even parity
1      1 STOP bit
1      1 when idle
1      open drain (we don't connect Tx anyway)
[      UART Live display
....   sniffer is active
]      Stop UART Live display

If BRG/baudrate is wrong by >3% you'll get errors. So finding the proper baudrate is extremely important when sniffing busses not using a standard 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 reader CLK signal to bus pirate AUX probe and press "f" (works both in HiZ or UART modes)


Here are some measures on various readers:

Reader CLK baudrate BRG Remarks
Dell RT7D60 4009216 Hz 10777 370
ACR38U 4009216 Hz 10777 370
Vasco DP905 3700736 Hz 9948 401 mode 9600 works too (416)
Vasco DP810 1.064MHz 2860 1398
Vasco DP840 1.064MHz 2860 1398
Gemalto PC USB-SL 4000768Hz 10755 371
Gemalto "digipass" 1501696Hz 4037 990



It would be much easier if bus pirate integrates those baudrate<>BRG conversions.
E.g. 

UART> m3
Set serial port speed: (bps)
...
10. BRG raw value
11. Approximative baudrate value
(1) > 11
Baudrate value to approximate:
(9600)> 11250
Choosing BRG=355, baudrate=11236, error=0.13%
...

UART> i
Bus Pirate v3b
...
UART (spd brg br dbp sb rxp hiz)=( 11 355 11236 0 0 1 )

Note that there is currently a little bug in UART info display, spd counts from 0 while menu items count from 1 (so menu=5 (9600) => spd=4)

EDIT: Bus Pirate v4 supports introduction of arbitrary baud rates rather than BRG raw values, and even an auto-baud detection (provided that there is some activity on the link)

Frequencemeter

Measured frequency goes to an incredible level of details but don't be abused the precision is lower (but not that bad).

Here are some tests on a XTal of 4MHz:

  • Displayed frequencies are always a multiple of 256 because ATM it's using a 256 prescaler
  • There is an important temperature drift (XTal maintained at room temperature):
    • <9 degres Celcius: 4,001,280 Hz (too cold for my IR medical thermometer)
    • 9.5 degres Celcius: 4,003,072 Hz to 4,003,328 Hz
    • 17.5 degres Celcius: 4,004,352 Hz to 4,004,864 Hz
    • 26.5 degres Celcius: 4,006,912 Hz to 4,007,424 Hz
    • 33.5 degres Celcius: 4,009,728 Hz to 4,009,984 Hz
    • So at most 0.25% of error while PIC24f datasheet announces for Fosc intern (8MHz): +-2% @25deg, +-5% @full range
    • There is also apparently possibility to use a compensation register in the PIC: "OSCTUN"

For greater precision, I tried with an Arduino (16MHz XTal, 25deg):

  • 3,999,920 Hz without calibration
  • 3,999,998 Hz with calibration

UART Bridge, as FTDI cable replacement

Bus Pirate has two bridge modes in UART, see UART doc (or bus-pirate-uart-guide):

  • Macro (1): Transparent UART bridge.
  • Macro (3): Transparent UART bridge with flow control.

Once activated, you've to unplug the Bus Pirate to reset it.

115200 bauds for both PC<>BP & BP<>device speeds

Using socat & chat: 

socat SYSTEM:"/usr/sbin/chat \\\"\\\" m3 \\\(1\\\) 9 \\\(1\\\) 1 \\\(1\\\) 1 \\\(1\\\) 1 \\\(1\\\) 2 UART \\\(3\\\) sure y",pty /dev/bus_pirate,b115200

Chat script is to be read as:

  • ""=don't expect anything
    • m3=select Mode UART
  • (1)=expect prompt
    • 9=115200 bauds
  • (1)=expect prompt
    • 1=8data bits & no parity
  • (1)=expect prompt
    • 1=1 stop bit
  • (1)=expect prompt
    • 1=idle 1
  • (1)=expect prompt
    • 2=normal output 3v3
  • UART=expect UART prompt
    • (3)=run macro 3: UART bridge with flow control
  • sure=expect confirmation prompt
  • y=say yes

9600 bauds for both PC<>BP & BP<>device speeds

To activate same mode with e.g 9600 bauds for both PC<>BP & BP<>device speeds:
First adjust PC<>BP speed: 

socat SYSTEM:"/usr/sbin/chat \\\"\\\" b5",pty /dev/bus_pirate,b115200


Then as before, but first char to send to ACK the new communication speed is a space char, then wait for the HiZ prompt & send m3, select 9600 bauds etc: 

socat SYSTEM:"/usr/sbin/chat \\\"\\\" \\\" \\\" HiZ m3 \\\(1\\\) 5 \\\(1\\\) 1 \\\(1\\\) 1 \\\(1\\\) 1 \\\(1\\\) 2 UART \\\(3\\\) sure y",pty /dev/bus_pirate,b9600

Baudrate can be different on both sides of BP, just take care that overflow won't occur!

Binary

Previous scripts are a bit silly, I forgot about the binary modes.

Bus Pirate V4

Description

Installation v4

udev rules v4

I completed my udev rules to support also the BPv4 as /dev/bus_pirate: 

$ ATTRS=$(sudo udevadm info -a -p \
          $(sudo udevadm info -q path -n /dev/$(dmesg|\
              grep -m1 "USB ACM device"|\
              grep -o "ttyACM[0-9]\+"))|\
          egrep "ATTRS{(serial|idVendor|idProduct)}"|\
          head -n 3)
$ echo "SUBSYSTEM==\"tty\"" $ATTRS "SYMLINK+=\"bus_pirate\""|\
  sudo tee -a /etc/udev/rules.d/76-usb-buspirate.rules

Cable v4

v4 header is larger (12 pins) but also changed somehow the order compared to v3.
I think it's to match the order of earlier versions.
At the moment seeeduino doesn't provide a 12-pin probe kit.
So I modified a 10-pin probe kit.
As I had to put a new header, I wanted the colors to match the ones of v3, just to avoid confusion when playing with them.
Header to fit the socket can be e.g.

  • AMPHENOL - T812112A100CEU - SOCKET, IDC, 2.54MM, 12WAY
  • AMPHENOL - T812112A101CEU - SOCKET, IDC, S/RELIEF, 2.54MM, 12WAY

Second one is as on the original cable, where the flat cable comes again over the header.
So depending which connector you choose and which direction you want the cable to have, be cautious!
You'll need also 2 extra micrograbbers, e.g. POMONA - 4233-0 - PROBE, DIY MICROGRABBER
With a socket with the polarizing slot towards outside (as on the seeeduino version), colors top to bottom are: 

BPv4 header => towards outside                      original cable for BPv3
+----------+
| GDN      |  - brown, black EZhook  _______        
|     +5   |  - pink,  red EZhook    ___ ___\_____  GDN  - brown, black EZhook
| +3.3     |  - red                  ___X___\_____  +3.3 - red
|     Vpu  |  - green                ___ ___\_____  +5   - pink,  red EZhook
| ADC      |  - yellow               ___X___\_____  ADC  - yellow
|     AUX2    - new cable!                  \_____  Vpu  - green
| AUX1        - new cable!                   _____  AUX  - blue
|     AUX  |  - blue                 _______/_____  CLK  - violet
| CS       |  - white                ___ ___/_____  MOSI - grey
|     MISO |  - black                __ X __/_____  CS   - white
| CLK      |  - violet               __X X__/_____  MISO - black
|     MOSI |  - grey                 ___X___/
+----------+

We can perform a self-test with the cable by connecting together red+yellow, then simply run "~" on the CLI.

Firmware upgrade v4

Original firmware

$ screen /dev/ttyACM0 
HiZ>i
Bus Pirate v4
Firmware v6.0-a3 
DEVID:0x1019 REVID:0x0004 (24FJ256GB106 UNK)
http://dangerousprototypes.com

loader

To compile it, run BusPirate.package.v6.1/BPv4-firmware/pirate-loader-v4-source/build-unix.sh
Note that I had to edit it as it expected *.c to be in source/ 

./pirate-loader_lnx 
+++++++++++++++++++++++++++++++++++++++++++
  Pirate-Loader for BP with Bootloader v4+  
  Loader version: 1.0.2  OS: Linux
+++++++++++++++++++++++++++++++++++++++++++

bootloader

Shortcut last 2 pins of ICSP header (PGND & PGC) 

$ sudo ./pirate-loader_lnx --dev=/dev/ttyACM0 --hello
Bootloader version: 4,06
Device ID [f1]:PIC24FJ256GB106

flashing new firmware

Latest firmwares are here, not on Googlecode anymore apparently...
See Instructions 

sudo ./pirate-loader_lnx --dev=/dev/ttyACM0 --hex=BPv4-firmware-v6.1.hex
HiZ>i
Bus Pirate v4
Firmware v6.1 r1676 
DEVID:0x1019 REVID:0x0004 (24FJ256GB106 UNK)

Latest firmware

$ screen /dev/ttyACM0 
HiZ>i
Bus Pirate v4
Firmware v6.1 r1676 
DEVID:0x1019 REVID:0x0004 (24FJ256GB106 UNK)
http://dangerousprototypes.com

On-board EEPROM

See Access Bus Pirate v4 on-board I2C EEPROM

Retrieved from "https://wiki.yobi.be/index.php?title=Bus_Pirate&oldid=7920"