I got a DSview, it’s pretty decent hardware-wise and the software is good it’s also compatible with sigrock. I got it mostly for the included decoders, i have a Lecroy with decoding options which is much more practical as it can decode in real time but in the dsview you can create stacks for decoders like for example I2C stacked with a 24cxx so you can view the comands (read/write, address) and the data, in that case it is pretty simple but some devices have more complex control commands.
Didn't know there were Salae clones. The original is awesome (we have many of them) but a bit pricey. I use the newer mixed-signal one all the time, the EE's sometimes won't believe when you just show them digital traces but if you can show mixed signal that goes farther.
Digilent's Analog Discovery 2 is my new Saleae. It has all the usual protocol analysis stuff but also has more built-in goodies like a terminal and scripting tools.
On top of that you get a lot more analog thingies including voltmeters, voltage supplies, and waveform generators.
I got a cheap logic analyzer (salae-like clone) and used sigrok this summer to debug a bug (took a week and turns out I never actually turned on the component from the gpio). Trying to match the SCL and SDA lines to the datasheet was a great. Want to get an oscilloscope next :)
I would not recommend opening the linked PDF file. The link above to the PDF file is causing a BSoD on my fully patched Windows 10 sandbox. I've tested it three times, firing up WinDbg to see if I can locate the cause.
Isn’t Windows not supposed to blue screen from user applications? Only kernel level stuff should crash it. Someone else mentioned that it could be graphics drivers?
The last time I opened a pdf file in Chrome/Firefox in Github PDF renderer, the computer ran out of RAM. The pdf file I opened definitely didn't require so much RAM at all.
Alternative solution: download and open it locally
Shameless plug for a low-cost JTAG/SPI/UART/I2C tool/platform (works with OpenOCD etc.) if you don't mind ordering your own PCBs & components and doing a bit of soldering (Well, you ARE all hackers...)
I have an old IBM mainframe which has a card only known as the Camel Card. There's practically no information about it beyond that it exists. Having looked at the chips on it, there does seem to be an FPGA on it. What sort of equipment and software would be needed to extract that?
Bad news: even if you get the bitstream out, there isn't full reverse engineering of what it means for anything other than a few Lattice Semiconductor parts.
But the required steps would be to identify how it loads the bitstream by looking at the pins which control this. Quite often this is from an external SPI device. That can simply be read out with e.g. "bus pirate" device. Otherwise, a suitable JTAG may give you access.
> Bad news: even if you get the bitstream out, there isn't full reverse engineering of what it means for anything other than a few Lattice Semiconductor parts.
This catches so many new people. Bitstreams are not firmware. They are configuration.
And even if you do find out the format of the bitstream, you can’t exactly reverse engineer it with a “disassembler” of sorts; you need to RE it like how one would a die shot of an IC (just guess at what something might be doing and see if you’re right).
You need to provide more information before your question can be answered (if it can be answered):
* Chip manufacturer (Xilinx? Altera? Other?) - typically a logo on the chip.
* Chip part number (typically the first row of letters and numbers on the chip - typically the second row is the date of manufacture in the form YYww where ww is the week of manufacture - all numbers are useful)
If the card has a clearly identifiable JTAG connector and is a common FPGA, you should be able to look up the chip part number on the manufacturer's web site and find the software tools that support that chip. You will need to figure out which JTAG interface the tool set supports - if it is a newer toolset, it probably supports a relatively inexpensive USB-attached JTAG. If it is an older toolset, it may need a specific, often expensive and likely no longer available JTAG interface.
I seem to remember that it is an Altera FLEX 10K; I did scribble it down in a notebook. Thank you for common date information to look for. The machine was released in 1999, so I'm going to assume very much "older".
I'm curious too. I'm very ignorant on programmable logic in general, but I have some hardware with both a large FPGA as well as what I believe is a CPLD powering part of an embedded network interface controller I'm trying to put some missing links together for.
I honestly need to stop buying old hardware before checking if someone uploaded a manual online :p
Funny how JTAG these days is synonym with in-circuit debugger. The original use of the port was to support IC interconnect testing, and for high density boards it still is. For external parallel and serial memories you can use the boundary scan registers to bit bang the pins and read the inputs. In fact, that was a popular way to program external memories on fresh boards if they didn't come with embedded bootloaders.
Even if you don't have the scan configuration file of a particular chip for your tool, they are very standard and easy to figure out. No desoldering required!
It kinda makes sense though. The expansion from boundary scan to debug is just extending the scan chain to all the flip flops in the random logic too, not just the one's controlling the pads.
That’s a bit of a stretch though... jtag for ice/debug at that point just becomes another serial bus interface with a high level protocol controller.. you’re not literally extending any scan chain in most cases. The jtag port was coopted for this purpose simply for the pragmatic reason that it’s a good use of pin real estate.. nothing more.
Those high level protocol controllers came later to speed the process up and allow debug without exposing ridiculous amounts of IP to the debugger vendor. Originally it was just access to the full internal scan chain.
It’s a little more to it than that... I think you are severely understating the necessity of “speeding up the process.” IP concerns aside, an internal scan chain may still not give you features such as practical monitor mode debugging with any useful level performance. The point is, debugging in general is better served by dedicated hardware, at that point putting it on the jtag bus vs any other serial bus is more a basic pragmatic issue.
I've tried my hand at hardware hacking a few times only to hit dead ends. Most recently I wanted to dive into a minor security vulnerability and some other oddities I found in the web interface of a cable modem by trying to get OS access. The details were a bit fuzzy, but I easily identified a UART, however sniffing it wasn't giving me much. There didn't ever appear to be a shell and mostly it was just outputting diagnostic info like channel bonding attempts. I couldn't manage to figure it what exactly it was running. Some things pointed to a stripped down Linux, some pointed to a custom OS (including a strange Chinese github repository that was probably less than legal) and some very weeks hints pointed to something like VxWorks, but i don't remember the UART ever given any sort of boot information. I tried to use a bus pirate to dump the flash a few times but always came up with a bad image. On an interesting note, this was the first time I saw a real life MIPS device though.
There were also what looked like a few different UARTs but only the one had any data coming off it. Eventually I got a little to liberal poking around with a multimeter and shorted something, killing the device.
I'm just really bad with this stuff in general I guess lol. This was just a cheapo cable modem, so if I ever want to pick up again I just have to order a new one of the same model and try to remember the tools. I do have other devices I need to investigate however, that would be expensive or near impossible to replace if I killed them. I'm mildly worried about doing much with those for the time being.
It's such an advanced piece of equipment, and I'm unable to find most of the components listed on it, plus the major processors are under epoxy blobs. I feel totally overwhelmed just looking at it and not knowing where to start.
I wish I could have an expert examine the device with me in real life and help me walk through it a bit; using random bits of online resources still leaves me feeling lost. I would love to have a resource that teaches elements of hardware hacking step-by-step by reverse engineering cheap electronics I can get my actual hands on, starting with simple and moving on to complex items.
Very fun writeup! I'm getting back into hardware, and things like finding UARTs and JTAG pins feels like Hollywood-style hacking. Love reading articles like these.
I would guess standard programming interfaces to be deactivated and further programming happening only through a bootloader. Don't actually know if that is common practice, but that is how I learned it.
Some smaller MCU have alternative pin functions for the SPI/JTAG pins.
A lot of embedded programmers don’t come to it in any formal way. They’ll make it to shipping a product without ever having heard about the idea of blowing the security fuses.
For those that do know to do it it’s different. Before you blow the fuses you need to to be damn sure of your bootloader and that you will never want to debug something in the field.
A lot of companies don’t give you the time before putting it into production. Then once it’s in production you work on the next product instead of hardening the last one.
(Supposed) FCC regulations[0]. To prevent users from using non-compliant firmware on their devices, i.e. locked bootloader which will only boot OEM-supplied signed firmware.
https://sigrok.org/wiki/MCU123_Saleae_Logic_clone