This post is about a teardown of an DPO5000 oscilloscope (DPO5034). This is a 2011, mid-range, Windows-based Tektronix oscilloscope. List price is $12.000, but eBay has them – used – down to $5500 or so if you’re lucky. This particular model is a 350MHz, 5Gs/s model without MSO functionality (adding 16 digital channels, a “poor man’s logic analyzer” -even though it rather *makes* you poor when buying it, since it’s pretty expensive). The higher end models in that series support up to 2GHz bandwidth, 10GS/s (albeit only on two channels in an interleaving configuration) and support the “MSO” function out of the box. The top-end model (MSO5204) has a list price of $28.700. What do we expect from a teardown of an oscilloscope?

http://www.microwavejournal.com/articles/10796-time-is-on-our-side-oscilloscopes-for-microwave-engineering has a block diagram that we somehow expect to find in our scope:

That block diagram isn’t too surprising. What will be more interesting is how they actually implemented it. Turns out – there’s a lot of commodity hardware in it, but also a bunch of custom ASICs.

Here’s a picture of the mainboard (click here for the raw pictures).

But before the signal gets here, it will first go through the analog frontend. But guess what – I’ve opened up that one, too!

Analog Frontend

The analog frontend is a seperate board that sits in the front of the oscilloscope (behind the frontpanel).

The signal enters the oscilloscope on the BNC connectors on the front of the scope. Additionally to the signal connection, there are data connections and power supplies for the probe – called TekVPI. Those data and power connections are handled by the front panel, which I did not photograph. It’s mostly 12V plus I2C and an interrupt pin.

The frontend attenuates/amplifies the signal and converts it to a 50-Ohm differential signal suitable for the ADC. All the low-noise operation happens in this path of the scope. The analog frontend consists of 4 channels, each with an optional 50-Ohm coupling or optional AC-coupling, a passive (RC-based) attenuation circuit with selectable signal paths, an active pre-amplifier with a Tektronix-ASIC (internally called “Tek026″ though the package mark doesn’t mention this part number) and a bandwidth-limiting lowpass filter (implemented as a differential pi-Filter). Higher-bandwidth scopes (1 GHz and 2 GHz models) have an additional second-pass pre-amp called “Hfd144″, which is not present on my 350 MHz scope.

Additionally there is the “Aux” channel, which is good for triggering only. On the MDO4000-Series, which use the same architecture (but a different Analog Frontend) as the DPO5000-Series, instead of the Aux channel, there is a dedicated RF channel.

Trigger Asic

This oscilloscope uses the Tek005 trigger IC, again a Tektronix-specific ASIC. Triggering must be done on the analog signal in order to achieve a sub-sample trigger timing, which is required for things like equivalent-time (ET) sampling. (Equivalent Time sampling is widely explained on the internet, however there is one bit of “magic sauce” that’s usually missing from the explanation: The information on how to re-align the different samples with each other. The answer is that there is a special circuit in an oscilloscope called “timebase interpolator”, that can establish the exact trigger point between two ADC samples. For example, if the oscilloscope supports sampling the analog signal with a sample rate of 5 GS/s, there is an ADC value for every 200ps. If the triggering would be digital, this would be the trigger resolution. Since triggering, at least for simple trigger modes like “Edge”, is done on the analog signal, the timebase interpolator can often pinpoint the trigger point down to 10ps or less. By obtaining multiple traces, all shifted by a random sub-cycle delay, a more accurate waveform can be assembled.)

The trigger ASIC also interfaces to the “slow” MT48LC16M16A2-7E SDRAM (8 chips total, total 256 MByte, or 128 MSamples), which is used for the MSO feature. The total theoretical memory bandwidth is 8 x 16 x 133 Mhz, or 2128 MByte/s, easily covering 500 MSamples/s (each sample being 16 bit). So the MSO feature is actually implemented in the Trigger IC. The “MagniVu” feature, which allows capturing with up to 16.5 GSamples/s, but only up to 10k points, is also implemented directly in this IC.

ADC

The Tektronix DPO5000-Series supports a sample rate of 5 GS/s when all channels are enabled. That means that there is a total sampling capacity of 20 GS/s on this model – distributed to the four analog channels. Some models (the 1 GHz and 2 GHz models) allow combining the sample rate of two channels into a single channel, thereby allowing sampling up to two channels at 10 GS/s. It must be noted that no different ADC configuration is used for these models. The 20 GS/s are divided over two ADC chips. Each ADC outputs 10 Gbyte/s of data.

Demux

The heart of the oscillscope is a device called “demux”. A demux connects the ADCs with the Acquisition Memory – in the DPO5000, there are 4 chips for each of the 4 demux. The chips are marked “D9LHT”, and Micron’s FBGA part decoder tells us that these are MT47H64M16HR-25E:H – 1 Gbit of DDR2-800 SDRAM. That’s 512 Mbyte per demux, with a theoretical bandwidth of 800 Mhz x 16 Bits x 4 Chips / 8 Bits = 6.4 Gbyte/s – barely enough to stream the 5GS/s (=5Gbyte/s) to memory. So the main task for the demux is to store the incoming data from the ADCs to memory.

But the demux also includes a DSP that can provide FIR filtering and other general-purpose data processing on the buffers. This is used for the MDO4000-models, which feature an RF data path, where the Demux-pair (two of the four available are used for the RF path, the other two are used for the analog channels) is used to demodulate the incoming time-domain samples into I and Q, and also transforms them into frequency-domain for a spectrum-analyzer display.

Additional data processing is also used for the “Enhanced Bandwidth”-feature, where DSP filters are used to fix a probe’s frequency response – the software includes tables for various probes, sometimes even in combination with a specific probe solder-down connector (one example being “P7380 Right-Angle Flex_25X.flt”)! This is mostly relevant for the ultra-high bandwidth probes, and thus not really relevant to the midrange scopes.

The demux also contains the “FastAcq” or “DPO” feature, which is basically an embedded framebuffer with 21-bit counters per pixel. http://www.tek.com/document/technical-brief/advanced-statistical-analysis-using-waveform-database-acquisition has some more technical details on the DPO/FastAcq feature.

Display

The demuxes communicate with an FPGA called “Mia”, which merges the outputs of the four channels, and then generates the actual pixel data that is displayed on the screen. The data is transmitted over PCI Express to the integrated PC for display on the integrated touch-screen.

Comparing DPO5000 with the DPO4000B and MDO4000

It’s interesting to compare the DPO5000 oscilloscope with a second-gen DPO4000 (called “DPO4000B”-Series) or with the MDO4000. EEVBlog has a nice teardown of a MDO4000 here.
The obvious part is that the DPO4000-series uses a Linux-based firmware instead of a Windows-based firmware. The DPO5000 comes with an integrated PC that connects to the rest of the scope via a PCI-Express link to “Mia” (via a PLX PCI-Express bridge). The DPO4000 does not have this PC (nor the PCIe bridge) – instead, it has an on-board PowerPC processor that interfaces to Mia, and a few support peripherals (Ethernet Phy, Flash, RAM).

DPO4000 and DPO5000 share the same front-panel, though in slightly different configurations (the DPO4000 has a few buttons around the screen, whereas the DPO5000 has a touch-screen; the MDO4000 additionally has the numeric keypad on the right).

The lower-bandwidth (<1 GHz) DPO4000(B)-Series scopes only support 2.5 GS/s on all four channels - they only have one ADC chip (and two instead of four demuxes).
On the MDO4000-Series, which has the dedicated RF-Input additionally to the analog channels, 10 GS/s, i.e. half of the ADC power, is dedicated to the RF signal. That is why even the higher-bandwidth MDO4000-Models can only capture 5 GS/s on two channels - they have the same ADC configuration as the DPO5000, but already use half of them for RF.

“You get what you pay for”

The more high end a scope is, the more additional features can be enabled with purchased “Options”. This is not only true for Tektronix scopes, it’s also true for most other test instruments. The reversed logic of this is that the scope itself is more capable, at least in terms of what the hardware can do, than what’s exposed in the firmware.
For example, we figured out that this scope has 512 Mbyte of RAM per demux. If we assume “one channel is one demux” configuration (which is a bit too simplified, but not exactly wrong), that means that the scope could – in theory – have a capture depth of 512MSamples. By default, the scope does have a maximum of 12.5 Msamples. Even if we take into account that the user might display up to 4 reference waveforms and 4 math waveforms, and the demux may also store the rasterizer (display) data, that’s still more than 128 Mbyte per channel, a huge difference to the 12.5 Msamples that the scope offers.

The answer is easy – there’s an option, called “10RL”, which, according to a price list, goes for a whopping 7920 Euro, which bumps up the sample depth to 125 Msamples – without a hardware change, of course, just by entering a software key. I’d rather skip the discussion about how you pay to use the hardware that you already bought…
Ethically simpler is the discussion about protocol decoder options – for example the “SR-COMP” option that allows you to decode and trigger on RS232 signals that goes for 1480 Euro. That’s simply software that’s shipped with your scope, but not enabled – which I understand: development of this software costs money, so it makes sense to have only people pay for the development who are actually using the software (whether that price is appropriate though can be debated, but should not be an excuse for pirating that feature).

However, that’s something else from simply limiting the amount of capture memory – though even in that case you could argue that they may “subsidize” the cost of DRAM. But 7920 Euro for a roughly Gbyte worth of RAM? Last time I’ve checked a Gbyte of RAM was about 20 Euro – remember, we’re talking about standard DDR2 memory, not anything high-speed or custom.

I feel similarly about the “MSOE” option – which enables the use of the existing MSO feature. But either way, I don’t want to discuss Tektronix’s business model here. If I wouldn’t like it, I wouldn’t have bought their hardware.

Bandwidth

A much simpler topic then becomes the bandwidth limitation. Tektronix doesn’t sell a bandwidth upgrade for this scope (unlike for some other series, like the DPO3000), which indicates that bandwidth is indeed a physical limitation, not a software setting. We’ve seen scope bandwidth hacks before (http://www.instructables.com/id/Hacking-the-Rigol-DS1052E-Oscilloscope-with-Linux/), where the bandwidth limit was set by a software-controllable filter. Looking at the analog frontend again, we see a suspicious looking circuit:

Would this be a first-order differential low-pass filter? In fact, in bypassing this circuit (and thus removing the anti-alias filter – please know what you’re doing, and of course you will loose all warranties, and every time you do this an engineer will die in heaven), suddenly frequencies above 350 MHz become much happier and will make it to the ADCs: (left is an unmodified channel, right is a modified one)

(This is Gen1 SATA, hence a fundamental frequency of 750 MHz. With a bit of postprocessing, I could even capture Gen1 PCIe with its 1.25 GHz fundamental and decode the bits in software.)

This is of course not the same as an actual instrument with that bandwidth. As mentioned, the 1 GHz+ models have an additional pre-amplifier stage, and of course a well-defined bandwidth limitation. I’m betting that my hacked up channel doesn’t have a flat response up to the maximum anymore, but I lack the equipment to actually characterize the behavior.

Mysteries Left

There are a few mysteries left.

• What’s the unpopulated device at the top right on the mainboard?
• Why is the MSO acquisition RAM twice as big and twice as fast as required by the specs?
• What the hell did they think when they designed the user interface of the frontpanel? (I could rant about this for hours. The DPO4000′s UI is designed for this frontpanel, and “makes sense”. The DPO7000 (and all higher end models) have a slightly larger front panel, which for example allows directly changing the trigger source. The DPO5000, however, has the UI logic of the DPO7000, but the frontpanel of the DPO4000. This combination makes no sense. Barely a function can be achieved without using the touchscreen. On the other hand, there are countless buttons (when was the last time you – intentionally – pressed “Autoset”? Default setup? “R”? “Play/Pause”? Why are there two – lighted! – dedicated buttons for “Coarse” and “Fine”, but no dedicated button for switching between “offset” and “position”? Why is there a dedicated “intensity” button? This could go on for a while.) Please, Tektronix, either allow customization of Frontpanel button to UI mapping, or just have someone use this scope for a day and then reimplement the mapping.)

This is Paul Matti, born 2012-03-05 (07:01am). He turned one today, and his sister also thinks that he is awesome.

For OpenVizsla I wanted to get programming working from Impact. Programming the CPLD and FPGA is supported via an on-board FTDI chip, and usually done with urjtag. However, you can’t use – for example – Chipscope.

There are solutions like this neat hack, which basically LD_PRELOADs into ISE, pretends to be libusb, provides a virtualized platform cable, and then talks to some different back end.

But it turns out – there’s a much easier, albeit undocumented, solution. It’s called xilinx_xvc, or “Xilinx Virtual Cable”. It’s a plugin – the only one next to the Digilent plugin – that can be used as a cable. It opens a TCP connection to a specific host, and sends JTAG “shift” instructions over TCP. The protocol is really, really simple: There’s only one command that I ever saw being used, called shift:. After that, a 32-bit little endian word specifies the number of bits, and after that, two byte-padded strings are the bits to be shifted out on TMS and TDI (in that order). The response is a byte-padded string of the bits shifted out on TDO. That’s all – a nice, abstracted JTAG PHY.

I implemented a client for this for the awesome NeTV here (requires some hardware hacking though to get the JTAG pins connected), and a generic FTDI version (based on libftdi) here (feel free to merge and send me a pull request!).

The xvcd is a daemon that listens on port 2542, and allows multiple programs to access the JTAG chain at the same point (it switches between them only when it’s “safe”; it relies on the programs to idle the chain every once in a while by going through TLR and then staying in RTI). It also works around a weirdness where Impact, whenever an IR or DR is written, goes back to the Capture-IR/DR state before exiting back to RTI (which almost always screws up the register). xvcd follow the JTAG state machine and just ignores this these instructions.

A while ago I took apart a Fluke 411D – coincidentally with nearly identical results as this SparkFun tutorial: I disassembled it, found the serial port, found the “?\r\n”, tried sending all kind of data to the other “RX” pins – and didn’t receive any answer from the device.

Now I was able to take a look at a (much more expensive) Hilti PD-30 [PDF].

It has a much better build quality (which is kind of expected for a 4x expensive device) – for example it has a glass lens, and the transmit and receive parts are much better aligned and glued together:

On the Fluke 411D some misalignment had caused the distance range to be significantly impaired (to ~3m) – very well possible from 3 missing “shipping screws” (screws that are left over after you re-assemble a device) that apparently were much more important than I’ve thought…

Another interesting tidbit is the difference between the PD-30 and the PD-32: The Hilti PD32 feature two more measurement modes and have two more buttons. Turns out – the PD30 also has these features, and the buttons are… not quite… there.

So yes, if you press those “internal” buttons, they actually work! There’s even an unexposed (populated!) trigger button on the side.

The microcontroller is a NEC (now Renesas) “PD3X” – where PD3X probably just indicates that they are programmed with a Hilti-supplied Mask ROM for the PD-3X series. That’d also explain why the PD-32 features are easily available. There’s also a serial port, which is – as inverted TTL – available on the outside. And guess what – upon power on (and power off), exactly three bytes are transmitted: “?\r\n” (interestingly at 9600-7E1). This design seems to be at least related to the Fluke 411D (or the identical “Prexiso X2″).

(Click here for all photos)

Update:

Apart from RX and TX being inverted (which is easily fixable with a FT232RL which can be eeprom-programmed to use inverted UART signals) it “just works” – commands like ‘a’ (reset/online mode), ‘h’ (tracking) and ‘N00N’ (display firmware version) work. More commands can be found for example here, but not all of them work. The probably most important one, “tracking”, works just fine!

Unfortunately that also means that for the Fluke 411D (or the equivalent versions), the serial port really just doesn’t react to otherwise “valid” commands – people (including me) have definitely tried “a\r\n”. Maybe it requires some special activation sequence, or some special eeprom settings. Who knows…

Just to be clear: none of these exploits are rocket science. This is kind of the “low tech” hacking approach – no fancy oscilloscopes required, no DPA involved, no FIB to rent. There’s not even code to disassemble!

1. ext2 Symlink Directory Traversal

The first vulnerability is a classic oversight. It applies to many devices that are accepting a mass-storage device (for example USB or micro-SD) and are somehow exposing the contents of this to the outside world. This includes WLAN/3G access points with a “file share” ability, NAS and a lot of special purpose devices. Slightly linux-centric (but I’m sure it applies to many other operating systems as well), these devices usually try to support multiple filesystems by using the equivalent of the “mount -t auto”, automatically trying all filesystems from /proc/filesystems when mounting, until one filesystem handler succeeds in mounting.

While supporting multiple filesystems is normally meant to support FAT, NTFS and maybe HFS+, most kernels also have ext2/ext3 support compiled in; sometimes the rootfs of these devices also uses ext2. This means that if you attach an ext2 formatted storage device, it will be mounted as well. If the device exposes access to this filesystem, it gives you a lot of toys to play with: symlinks, device nodes and all the fancy features.

For example, if the device allows you to browse the attached mass storage, a simple symlink to / might allow you to browse the rootfs:

lrwxrwxrwx 1 root root 13 Oct 25 09:59 rootfs -> /


Certainly, you’re bound to the permissions of the process that does the access to the files. However, in embedded devices, designers rarely use user permissions (and instead only expose restricted functionality in the application), and since they probably never thought about ext2, restricting permissions and jailing (chroot etc.) wasn’t deemed useful. After all, vfat partitions (for example) can’t contain symlinks or useful multi-user permission bits (with HFS+ it’s a different story, of course).

On this particular device, a configuration file was copied on bootup from an insecure attached mass-storage device to an internal (but still insecure) storage. This allows to place a symlink on the mass-storage device pointing to any regular file in the root partition. It didn’t allow browsing in the root file system, but could be used to retrieve regular files (so no character devices) with a known filename.

2. Non-Appropriate Crypto Modes give you a Decryption Oracle

AES (or any other modern cryptographic standard) is considered “secure”. This fact is easy to remember, given that AES is still the recommendation for newly-designed crypto schemes. However, it’s much harder to understand what “secure” actually means. For block ciphers, one important property is that there is, given (even a large number of) ciphertext/plaintext pairs, no more efficient way to recover the key used in the encryption than to do a full brute-force attack over the key space. (There are a few other scenarios that block ciphers need to be “secure” against, but this is the most important one).

However, this is not the only property that’s required when encrypting data. Each usage model has a special requirements, and that’s why there are several so-called “modes” of operation. The simplest mode is ECB, replacing each plaintext block with an encrypted version of the block. Explaining why ECB is not sufficient in most cases is easy. That leads people to think that CBC would fix all their problems. Hint: It doesn’t.

One thing that apparently people sometimes expect CBC to provide, which it actually doesn’t provide, is integrity. Decryption without integrity means that you can replace encrypted content with other encrypted content, and it will produce the corresponding plaintext (assuming you can access parts of the decrypted data). In CBC, the chaining aspect will screw up the first block only, and even that can be manually fixed since the ciphertext is known. If you use AES-CBC for disk encryption, you’ll likely be screwed. The missing integrity aspect is one reason why proper disk encryption doesn’t use plain CBC.

Practically speaking, if you use plain CBC (maybe with a per-sector IV which doesn’t provide any security advantage), and the attacker can get the contents of a random file from your disk (for example using the symlink hole), all the attacker has to guess is the position of that file in the encrypted disk image. He can then inject arbitrary sectors into this file, dump the file, and recover plaintext. This might sound painful – and it is – but if a large-enough file can be found (that isn’t required to make the system run up to the point where you can read the file), you can extract quite a lot of data per run.

There are cryptographic modes (like XTS) which fix these problems. If you don’t understand the issue, go read why they’ve been invented.

3. Configuration String Sanitizing

Sigh. A general rule-of-thumb: If a parser acts on user-supplied data, and that parser isn’t exactly made for what the input file looks like (which would hopefully imply that the creator thought about security side-effects of any invalid user-supplied input string), don’t try to “sanitize” or filter as a frontend. You’ll miss something. This applies for sanitizing file names (think of the popular Unicode directory traversal bugs), SQL arguments and especially configuration files.

I’ve seen devices which allow putting an un-encrypted, un-authenticated configuration file on a user-accessible storage. The configuration file was an ASCII file with a number of

key=value\n

lines. This was then “sanitized” by removing all keys that are not in a whitelist (with some bash string parsing foo), and decorated into the following format:

export key=value\n

The resulting file is then sourced (“.”) as part of the init scripts. Needless to say how this can be exploited, leading to arbitrary code execution, for example a conveniently powerful busybox console on the serial port…

Lesson learned: Don’t sanitize and then let another parser do the job. Parse and sanitize at the same time.

4. /dev/mem

This (linux-centric) one is not really a security hole per se. However, it sometimes allows attackers to “reverse” the boot chain – for example to retrieve (parts of) the bootloader or initrd/initramfs used to boot the system, by creating a memory snapshot right after booting. This technique for example was used to retrieve the initrd of the ReadyNAS (which, back then, uncovered a nice little backdoor password).

The device node /dev/mem maps the physical address view of the kernel. Extracting contents can be as simple as using “dd” (with proper “skip” and “bs” arguments). Alternatively, using the mmap system call, any memory (including MMIO) can be mapped into a user process. If /dev/mem is opened with O_SYNC, the mapping is cache-inhibited (on most architectures, everything above the memory size is cache-inhibited, too), which allows you to talk to IO devices.

Reading (writing, and mmap’ing) /dev/mem requires proper access permissions and CAP_RAWIO.

And really, if there was no /dev/mem, you could just load a kernel module providing the same. Root access on an embedded machine equals device pwnage, unless great effort was taken (hint: which is usually not the case).

Again, the existance of /dev/mem isn’t the security hole – the security hole is allowing the attacker to operate on it. It just makes things much more convenient.

5. Write-Only Registers with Partial Override allow Key Recovery

This one is a classic as well. Some hardware implements cryptographic functions (for example AES decryption) in hardware. Some hardware designers cleverly make the registers that are used to configure the key used in the decryption write only – such as that they can be written with the key, and the key cannot be read back. The key can then only be used in actual AES operations.

This sounds clever at first, solving real-world problems – you can’t just dump the key out of memory. However, as usual, things are not that simple. Almost no CPUs or busses in embedded systems these days can handle atomic writes to key-sized (128 or 256 bit) registers. That means that a key register won’t be a single register, but consists of multiple registers that need to be written sequentially.

As long as they are written strictly sequential and completely, there is no problem. However, as soon as partial overwrites are allowed, the scheme breaks. For example, if the CPU can do 32-bit writes, and a 128-bit AES key consists of 4 registers with 32-bit each, this allows the attacker to modify the key. By then using the modified key, ciphertext/plaintext pairs can be generated that have known key bits, allowing a brute-force search on the remaining bits.

Practically, there are two possible ways to exploit this. Assume it’s a decrypt oracle (i.e. the internal key can be used to decrypt arbitrary ciphertext; it works similarly for non-arbitrary ciphertext or encrypt oracles). Now, either

• Take the reference plaintext by decrypting a constant, for example all-zero. Overwrite as few key material as possible. If the registers honor write masks, you might be able to overwrite as few as 8-bit of the key. If it doesn’t, it might be as much as 32-bit. In any case, simply loop through all of the 2⁸ (or 2³²) combinations, overwrite the key material partially, take a plaintext with the current key, and compare it with the reference. If it matches the reference, then you found a few bits of the key. Rinse, repeat with the rest.
• Overwrite as much key material as possible while still leaving a little bit of key material. Take a plaintext for a constant ciphertext. You can then (offline) run a brute-force attack on this, which is feasible because you reduced the entropy of the key before. Reboot (to restore the full key), Rinse, Repeat

The first method is useful if the write granularity is fine (for example 8-bit) – it will then require 16 * 2⁸=4096 (worst case) decryptions on the device. The second method is useful if the write granularity is larger (for example 32-bit), because the first approach would require 4 * 2³²=17179869184 (worst case) decryptions on the device, which can take quite a long time. These decryptions can be done offline and parallelized. A 32-bit brute force attack on a modern PC doesn’t take more than a few minutes, so after extracting the 4 possible plaintexts (keeping the first, second, third, fourth key word) the key can be recovered on a PC.

The disadvantage of the second method is that you need to restore the key material (for example by rebooting) before attacking the next key subset.

A similar method can be used (destructively) to dump OTP fuses that store a key, assuming that no redundant encoding is used (i.e. that you can burn more OTP bits to set bits in the key).

1. Start with the first bit. Take a plaintext. Burn the first fuse, re-sense (if required, to update the key register), take another plaintext.
2. If the plaintext changed, you know that the bit wasn’t set before. If the plaintext did not change, the bit was already set. Note that down.
3. Repeat with the next bit.

A somewhat inconvenient method, since it’ll destroy the OTP key (so you better be sure that you can still execute code even after the key has been partially destroyed – otherwise you need up to $keysize devices – which might still be a useful attack).

Some devices will not allow you to overwrite arbitrary parts of the key – some for example start the key schedule only after writing the last part of the key. However, unless they double-buffer or enforce sequential and complete access (which both involves additional state), this is vulnerable and can be exploited.

6. Relying on Success

Back in the d-Box 2 days (German link, sorry), the boot sequence would by default load into a GUI that didn’t provide any remote access. However, if the boot sequence failed, a remote shell daemon would open. This fact could be abused by short cutting a flash data line in the middle of the boot, causing the GUI binary to fail, eventually giving RSH access to the system. Then, a new, modified rootfs could be mounted (only the kernel was protected with a signature, the filesystem or any files within wasn’t), leading to arbitrary code execution.

The mistake they did was to assume that in a secure environment (arbitrary flash editing aside) everything would boot as expected. While it might be hard to change data meaningful, it’s often very easy to change data in a non-meaningful way – i.e. make something fail.

In a particular case, a kernel image was (securely) loaded into memory, and then launched. The problem is that there is no error checking. If the binary doesn’t load for some reason, the bootloader still tries to boot from that RAM location, even if it contains garbage. Usually, the bootloader would just abort with a CRC error.

To turn this denial-of-service attack into something useful, you can just pre-populate the memory (assuming you have code execution), reset the device and somehow make the load fail. The memory’s content will survive a few seconds without refresh, so it’ll execute your good code.

7. $USER

Cross-compiling sometimes leaks information from the host system into the generated binaries (or files). One example is the kernel’s LINUX_COMPILE_BY (that’ll end up in the linux_banner, which is output when the kernel starts and can also be read from /proc/version), but there are more such examples. If you don’t want people to know who you are (hey, there should be no reason for that, right?), be aware of this fact and better grep all your binaries (including your rootfs) to make sure that nothing leaked.

I recently bought a Metz 50 AF-1 N flash that I’m very happy with. One of the reason why I bought this one was that it has a USB port to upgrade the firmware. (Call me crazy, but that’s a valid reason for me.)

Looking at their firmware, we find a number of “.mtz” files that all look – weird. Their entropy is much too low for a real encryption scheme (plus they don’t seem to have any length alignment). One file, MB50AF1_NikonV12.mtz in my case, looks like it’s the actual firmware for the device.

Looking at a hexdump at the end of this file shows

0000029CE0: 64 64 64 64 64 13 73 D0 A0 A3 03 03 03 03 03 03
0000029CF0: 03 13 64 64 D0 A0

We could go ahead and try to find the “de-obfuscation” algorithm in the executable (or actually go and sniff the communication, with the hope that files are decrypted locally), but there is a thing that striked me: The files end with D0 A0. Other .mtz files also end with A0 or D0 A0.

Can you already spot the algorithm?

I have to admit that I didn’t spot it instantly, even though in retrospect, it’s obvious. I tried with the usual stuff (histogram to figure out a caesar or “XOR with constant” algorithm), and eventually failed. Looking at the ending again – not surprised if they would be ASCII files, we would expect them to end with 0D 0A, or 0A, depending on the encoding.

A quick python 3-liner later showed that this guess was indeed correct: They simply swap nibbles. Doing this on the largest of the files (MB50AF1_NikonV12.mtz) produces a nice Intel-Hex file.

Next step is to guess the architecture. AVR? Nope, looking at the binary it’s obvious that they have byte-aligned instructions. PIC? I didn’t even dare to try. ARM? No byte-aligned instructions either, and the code density was much too high. 8051? Nope. I tried a few more, but none of them produced sensible output. May I ask for an “heuristically identify me the architecture for this binary, please” project again?

I finally resorted to the brute-force approach: Opening up the device reveals: It’s a NEC (now Renesas) μPD78F0396! Here’s the datasheet! Happy hacking!

Some hackers say Sony wants to deter customers from modifying the PlayStation3. Is that true?
No, there’s a real misnomer there, we embrace independent game development; if you call that hacking, then we embrace that. We give people tools that let them create new experiences. What I don’t think we are in support of is someone trying to hack our device to pirate software and possibly collapse the platform.

No, you fucking don’t. Instead, you call them pirates and sue them:

MS. SACKS: Well, certainly one thing we might find is whether or not any of them are engaged in the hacking that we now know was a widespread effort.

Obviously, the people in this class are the people who downloaded, or claim they downloaded the Linux operating system onto their other OS. It is beyond dispute now that there in is an ongoing effort to hack the PS3. In fact, most recently, there was an effort to hack around for update 3.21.

And these people, as members of the class, are engaged in activity that is not only prohibited under Sony’s agreements, but is illegal. So if, in fact, some of these very sophisticated users, who are included in the five named plaintiffs, are engaged in the hacking, we certainly have the opportunity to find that out.

As a short summary, the new type triforce is probably a cost reduction of the old hardware. As part of this cost reduction, handling of the GDROM and security PIC, which was previously implemented in an SH-4 CPU, was “removed”. The network stuff was now handled separately on a MIPS cpu, but several strings that are proven to exist do not exist anymore in the flash rom, at least not as plaintext.

On a closer look, a mysterious file “firmware.asic” was introduced, 96k in size. Using the Dolphin emulator patches (which are finally integrated, by the way! Thanks to everyone involved!) I could change the emulated “INQUIRY” response. Depending on the first byte, which seems to be a version number, the emulated segaboot would either boot normally, or upload the very firmware.asic file. Apparently the Type-3 triforce needs this firmware before it can work.

As a final hint, segaboot displays, depending on the “version”, either “VxWorks” or “RX850″. While “VxWorks” makes sense – the old triforce’s NETDIMM is VxWorks based – a “RX850″ couldn’t be found anywhere. Searching for RX850 yields a NEC (now Renesas) embedded CPU. Would firmware.asic be code for this CPU?

But looking at firmware.asic yields code that looks encrypted. Again we see repeating 8 byte patterns, a strong sign for a non-chaining block cipher. But – this time there is no external storage (like the security PIC for games) that would store the key. The key is probably hardcoded and stored deep within the silicon. My guess is that it’s still DES, given that they use DES for the games.

Brute-forcing the key would be a theoretical solution. After all, we can guess the plaintext for the repeating patterns (usually either all-zero or all-ones). There is a possibility that 8 byte blocks have to be reversed again (like for games). That gives us 4 potential ciphertexts to look for (normal, reversed, inverted, reversed-and-inverted) when encrypting zeros. After all, we only want to walk the keyspace once…

Today, after only a few hours of parallel search on 9 Xilinx V2P50 FPGAs, I’d like to announce: 00 22 44 66 88 aa cc ee. Brute-forcing the key is a practical solution. Thanks for keeping the key so simple! The leading zero bits really helped finding the key so fast.

For more details on the brute-force hardware and software setup, see my upcoming 27C3 Talk.

I vote for removing crypto primitives from PHP altogether.

Oh wait, people would just code up their own ROT26 then and use CRC for hashing. Nevermind. Maybe also remove the xor operator then?