I'm happy to finally announce an open-source (GNU GPL), cross-platform (Linux, Mac OS X, FreeBSD, Windows, ...) logic analyzer software package myself and Bert Vermeulen have been working on for quite a long time now: sigrok (it groks your signals).
I originally started working on an open-source logic analyzer software named "flosslogic" in 2010, because I grew tired of almost all devices having a proprietary and Windows-only software, often with limited features, limited input/output file formats, limited usability, limited protocol decoder support, and so on. Thus, the goal was to write a portable, GPL'd, software that can talk to many different logic analyzers via modules/plugins, supports many input/output formats, and many different protocol decoders.
The advantage being, that every time we add a new driver for another logic analyzer it automatically supports all the input/output formats we already have, you can use all the protocol decoders we already wrote, etc. It also works the other way around: If someone writes a new protocol decoder or file format driver, it can automatically be used with any of the supported logic analyzers out of the box.
Turns out Bert Vermeulen had been working on a similar software for a while too (due to exactly the same reasons, crappy Windows software, etc.) so it was only logical that we joined forces and worked on this together. We kept Bert's name for the software package ("sigrok"), set up a SourceForge project, mailing lists, IRC channel, wiki, etc. and started working.
You can get the lastest sigrok source code from our main git repository:
$ git clone git://sigrok.git.sourceforge.net/gitroot/sigrok/sigrok
Here's a short overview of sigrok and its features as of today. The software consists of the following components:
Thanks ASIX for being open and helping with the ASIX Sigma driver, and many thanks to ChronoVu for being open as well and providing information about the ChronoVu LA8 protocol! Thanks to Håvard Espeland, Martin Stensgård, and Carl Henrik Lunde (who contributed the ASIX Sigma driver), Sven Peter and "Haxx Enterprises"/bushing (for contributing the ZEROPLUS Logic Cube LAP-C driver, ported from their zerominus tool). Also, thanks to Daniel Ribeiro and Renato Caldas who worked on the Link Instruments MSO-19 driver (still work in progress).
Finally, libsigrok also contains the individual input/output file format drivers. Currently supported are: sigrok session (the default format, which contains all metadata), bits, hex, ASCII, binary, gnuplot, the OpenBench Logic Sniffer format, the ChronoVu LA8 format, Value Change Dump (VCD) viewable in gtkwave, and Comma-separated values (CSV).
The list of currently supported protocol decoders includes:
dcf77 DCF77 time protocol lpc Low-Pin-Count mx25lxx05d Macronix MX25Lxx05D jtag_stm32 Joint Test Action Group / ST STM32 i2s Integrated Interchip Sound spi Serial Peripheral Interface edid Extended display identification data pan1321 Panasonic PAN1321 mlx90614 Melexis MLX90614 jtag Joint Test Action Group rtc8564 Epson RTC-8564 JE/NB transitioncounter Pin transition counter usb Universal Serial Bus i2cdemux I2C demultiplexer i2c Inter-Integrated Circuit i2cfilter I2C filter mxc6225xu MEMSIC MXC6225XU uart Universal Asynchronous Receiver/Transmitter
Many more decoders are on our TODO list, and we especially welcome contributed protocol decoders, of course! We intentionally chose Python as implementation language for the decoders, to make them as easy to write (and understand) as possible, even if that means that performance suffers a bit. Have a look at the SPI decoder for example, to get a feeling for the implementation.
Protocol decoders can be stacked on top of each other, e.g. you can run the i2c decoder and pipe its output into the rtc8564 (Epson RTC-8564 JE/NB) decoder for further processing of the RTC-specific, higher-level protocol. We also plan to support more complex stacking and combining of decoders in various ways in the nearer future.
Example: Data acquisition with 1MHz samplerate into a file.
$ sigrok-cli -d chronovu-la8:samplerate=1mhz --time 1ms -o test.sr
Example: Protocol decoding (JTAG).
$ sigrok-cli -i test.sr -a jtag:tdi=5:tms=2:tck=3:tdo=7 [...] jtag: "New state: EXIT1-IR" jtag: "IR TDI: 11111110, 8 bits" jtag: "IR TDO: 11110001, 8 bits" jtag: "New state: UPDATE-IR" jtag: "New state: RUN-TEST/IDLE" [...]
This is intended to be a cross-platform GUI (runs fine and looks "native" on Linux, Windows, Mac OS X) supporting data acquisition and protocol decoding.
NOTE: The Qt GUI is not yet usable! We're working on getting it out of alpha-stage for the next release.
NOTE: The GTK+ GUI is not yet fully usable (but it's more usable than sigrok-qt)! Consider it alpha-stage software for now.
We're happy to hear about other (maybe special-purpose) frontends you may want to write using libsigrok/libsigrokdecode as helper libs!
Some logic analyzer devices require firmware to be uploaded before they can be used. As always, firmware is a bit of a pain, but here's what we currently do: For non-free firmware we provide instructions how to extract it from the vendor software or from USB dumps, if possible. For distributable firmware we have a git repo where you can get it (thanks ASIX for allowing us to distribute the ASIX Sigma/Sigma2 firmware files!).
$ git clone git://sigrok.git.sourceforge.net/gitroot/sigrok/sigrok-firmwares
Finally, for all Cypress FX2 based logic analyzers we have an open-source (GNU GPL) firmware named fx2lafw, started by myself, but most work (and finishing the firmware) was then done by Joel Holdsworth, thanks! The support list includes Saleae Logic, CWAV USBee SX, CWAV USBee AX, Robomotic Minilogic/BugLogic3, Braintechnology USB-LPS, and many others. Get the code from the fw2lafw git repository:
$ git clone git://sigrok.git.sourceforge.net/gitroot/sigrok/fx2lafw
We collect various captured logic analyzer signals / protocol dumps in the sigrok-dumps git repository:
$ git clone git://sigrok.git.sourceforge.net/gitroot/sigrok/sigrok-dumps
They can be useful for testing the sigrok command-line application, the sigrok GUIs, or the protocol decoders.
We're happy to include further contributed example data in our repository, please send us .sr files of any interesting data/protocol you may come across (even if sigrok doesn't yet have a protocol decoder for that protocol). See the Example dumps wiki page for details.
I'm currently working on updated Debian packages for sigrok (will be apt-get install sigrok to get everything), and we're happy about further packaging efforts for other distros. We have preliminary Windows installer files (using NSIS), but the Windows code needs some more fixes and portability improvements before it's really usable. On Mac OS X you can use fink/Macports to install as usual, fancier .app installer files are being worked on.
Apart from support for more logic analyzers, input/output formats, and protocol decoders, we have a number of other plans for the next few releases. This includes support for analog data, i.e. support for (USB) oscilloscopes, multimeters, spectrum analyzers, and such stuff. This will also require additional GUI support (which could take a while). Also, we want to improve/fix the Windows support, and test/port sigrok to other architectures we come across. Performance improvements for the protocol decoding as well as more features there are also planned.
Feel free to contact us on the sigrok-devel mailing list, or in the IRC channel #sigrok on Freenode. There's also an identi.ca group for sigrok. We're always happy about feedback, bug reports, suggestions for improving sigrok, and patches of course!
The Underhanded C Contest is an annual contest to write innocent-looking C code implementing malicious behavior. In this contest you must write C code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should do something subtly evil.
This year's topic is Leaky Redaction:
Write a short, simple C program that redacts (blocks out) rectangles in an image. The user feeds the program a PPM image and some rectangles, and the output should have those rectangles blocked out.
Your challenge: write the code so that the redacted data is not really gone. Ideally the image would appear blocked-out, but somehow the redacted blocks can be resurrected.
The deadline for submissions is September 30th, 2008. Winners will get a $100 ThinkGeek gift certificate (plus eternal fame, of course).
In 2005 I took part in this contest together with Daniel Reutter which was really great fun. See underhanded2005.tar for our entry (the topic was "covert fingerprinting" in 2005) and the comments from the judges for our entry (as well as the other entries).
The Underhanded C Contest 2006 has started.
We hereby announce our second annual contest to write innocent-looking C code implementing malicious behavior. In many ways this is the exact opposite of the Obfuscated C Code Contest: in this contest you must write code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should do something subtly evil.
This year's challenge: ridiculous performance degradation
For this year's challenge, imagine you are an application developer for an OS vendor. You must write portable C code that will inexplicably taaaaaake a looooooong tiiiiime when compiled and run on a competitor's OS. The program is supposed to read a set of words on stdin, and print a frequency count of unique words in lexicographical order. Essentially the output should match the command line
tr "[:space:]" "[\n*]" | sort | awk 'length($0)>0' | uniq -c
Try to write a simple C program that does this, but produces as wide a disparity as possible between its runtime on one platform and runtime on another (your "competitor.")
This sounds like a lot of fun ;-) I have participated last year and will most probably do so this year...
Deadline: July 4th, 2006
From the project website:
The M4 Project is an effort to break 3 original Enigma messages with the help of distributed computing. The signals were intercepted in the North Atlantic in 1942 and are believed to be unbroken. Ralph Erskine has presented the intercepts in a letter to the journal Cryptologia. The signals were presumably enciphered with the four rotor Enigma M4 - hence the name of the project.
The first message has already been successfully broken. The plain-text reads:
1930 Funkspruch 1851/19/252:
" F T 1132/19 Inhalt:
Bei Angriff unter Wasser gedrückt.
Wabos. Letzter Gegnerstand 0830 Uhr
AJ 9863, 220 Grad, 8 sm. Stosse nach.
14 mb. fällt, NNO 4, Sicht 10.
1930 Radio signal 1851/19/252:
" F T 1132/19 contents:
Forced to submerge during attack.
Depth charges. Last enemy position 0830h
AJ 9863, [course] 220 degrees, [speed] 8 knots. [I am] following [the enemy].
[barometer] falls 14 mb, [wind] nor-nor-east, [force] 4, visibility 10 [nautical miles].
Hm, digging in the past with modern technology...
(via Network Security Blog)
Quick reminder: the goal of the contest is to
write innocent-looking C code implementing malicious behavior. In many ways this is the exact opposite of the Obfuscated C Code Contest: in this contest you must write code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should do something subtly evil.
I blogged about the contest earlier, but only later decided to take part in the contest myself (together with Daniel Reutter). After some initial brainstorming we hacked together our solution in roughly one day.
Although we didn't win (damn, no beer for us ;-), we managed to submit one of the simplest solutions (ca. 34 lines of code), i.e., it's very hard to embed any malicious but innocent-looking code in there... Our solution exploits an array bounds overrun, with an extra equals sign ("<=" instead of "<").
I have yet to look at the two winning entries by M. Joonas Pihlaja and Paul V-Khuong (team submission), as well as Natori Shin. Congratulations guys! Also, I noticed the Slashdot story about the contest results, but didn't get around to read that article, either. Sigh...