Dolla dolla bill, y'all

Like Wu-Tang said: “C.R.E.A.M / Get the money, dolla dolla bill, y’all”. But how are these “dolla dolla bills” actually validated. Can you print your own money?

Going again deep on technology literally no one talks about. Banknote validators.

Introduction

We’ve all seen them, maybe even interfaced with them, sometimes without even acknowledging them.

Plastic money and mobile payments are ubiquitous today, but banknote validators are still present pretty much anywhere you use money. Counters in a grocery store, vending machines, parking kiosks, slot machines, ATMs… the list goes on.

To my own amazement, there is very little detailed information on how these things actually work. And more importantly, how easy or difficult it could be to bypass them.

As such, I took it up on myself to change that, as I feel the remarkably low-tech way used to validate extremely complex features deserves some applause and respect where due.

I didn’t search information available in Tor or shady forums, I’m sure there are places where these devices are discussed at length.

Detour, banknote security features

Let’s start with a detour, this is a topic that could easily be turned into a full length book. But it is important to understand some of the basic things so the latter chapters are a bit easier to follow.

I was surprised how much information there is available about the banknote security features and how banknote counterfeiting is combated. ECB, Danish national bank and Sweden central bank all have very nice, easy to follow, extremely thorough explanation of the various security features on the notes.

The banknote designers have an interesting set of problems they need to tackle. Some of which are conflicting. Like design security features that are easy to validate with just plain eye, but make them so, that they are extremely difficult to counterfeit. These are things that anyone can have on their hands and inspect as closely as they want, including people who might want to try and recreate them, for whatever purposes.

One of the prime ways the designers have gone about solving this problem is to create a lot of different features. And with lot I mean that there can be over 10 different security features in a single banknote.

Microprinting, UV ink, IR ink, holograms, colour shifting coatings, see-through pictures, watermarks, haptic features, magnetic stripes, speciality paper… the list goes on and on.

This is a classic way of approaching this type of a security problem. Defence-in-depth.

While any one of these features might be possible to achieve, trying to do all of them, or even half, will be extremely costly and require substantial investment. I’m not a counterfeiter so don’t really know or understand how that business works. But based on how legit businesses operate, you generally have to earn more money then an investment is worth to make it viable.

In addition to the financial viability, there is the limited access to some of the technology. Yes you can buy all sorts of stuff from Alibaba these days, but some of the security features require such a specialized equipment that I think it is not very likely you would be able to get your hands on them.

For the following chapters going in-depth how the validators work it is good to understand these security features.

• Metallic/magnetic print or security thread - Either ink fuzed with metallic/magnetic particles or a security thread that runs through the banknote with special properties
• IR properties - Modern banknotes have sections that have reflectivity and transmissivity in the IR part of the spectrum
• UV properties - Modern banknotes have sections or areas that have reflectivity and transmissivity in the UV part of the spectrum
• Holograms, emerald and colour shifting print - With more or less 100% reflectivity and spectral shift in the reflected colour
• See-through windows and watermarks - Fully transparent larger windows, like in Australian banknotes, or more typical patterns that block light and become visible when held up against a bright light source

Another thing to keep in mind is that we are talking about a physical process when printing the banknotes. And no physical process is ever perfect, it is exactly the same for printing of banknotes.

Yes their QC process must be absolutely outrageous, but still, even that process has acceptable tolerances. The banknotes might be slightly different in width or length, the colours might be a bit off, some of the security features might not be exactly in the place where they should be and so on. This obviously means the people building the banknote validators need to take these tolerances into account when designing the products.

Scavenger hunting

First step is always to scour the internet. There are some nice teardowns such as this thread that explain many of the features.

While you can sort of assume how it works under the hood based on the observed hardware and components, it wasn’t enough to satisfy my curiosity. Time for scavenger hunting. eBay.

As always, eBay is a reliable source for stuff like this. Just to complement my collection I also acquired few desktop banknote validators that are used for example at grocery stores.

Teardown time

Like a kid opening Christmas presents I set to tear apart all of the validators I had. And to my great dissappointment, they all looked pretty much the same from the inside. Main differences being whether they were using MCU, FPGA or CPLD as the “main DSP processor”, and the arrangement and type LEDs and photodetectors being used.

Everything looked very similar to photos and video clips of various teardowns. Rows and rows of LEDs and photodetectors. Ridiculous amount of passives and few ICs. One of the more unusual component that was present in all of the ones I took apart was this puzzling looking thing.

It wasn’t at all clear to me what this was at first as I just took the validators apart without paying much attention to details. What this thing is, is an optical encoder. Some of the devices used similar looking hall effect sensors. And they all had the same purpose, create pulses when the bill was moving inside the validator.

All of the devices employed some form of rubber runners, wheels or small rubber conveyers to move the notes underneath the detectors at predefined speed. And it is actually quite surprising how fast the notes travel through the validators. For the fastests ones I measured the validation taking roughly 1 second.

One of the more peculiar components I came across was this. People with enough miles on the clock will most likely recognize it.

Yes, it is a tape head. Glad to see this technology getting an after life. Although, cassettes seem to have made a second coming like some other retro tech.

What this is, for those who are unfamiliar with such advanced technology, is a tape head, or a transducer that converts magnetic fluctuations into electrical signals. And it is put on banknote validators to detect and validate the magnetic/metallic ink or the security thread.

While all of the vendors tout their device utilizing the “most advanced sensor techology”. Or 0,05€ LEDs and photodetectors. One device actually had some, a bit more advanced technology.

It was the only device that was actually, as far as I can tell, scanning the surface of the notes using some kind of linear CCD. Unfortunately, device also used an FPGA. And no I wasn’t planning on spending quality time attempting to reverse engineer the bitstream.

Instead, I focused my efforts on two candidates, one “professional” device meant to be embedded into a vending machine and a desktop version commonly seen at retail checkouts.

False hopes

After looking at the internals I was absolutely certain that fooling these would be an absolute child’s play. I even had an approach in my mind how to defeat them.

Hooking up oscilloscope channels on the photodetectors and one on the optical encoder it was easy to put one and one together. The optical encoder was used for two purposes, to calculate the length of the banknote. This could be calculated from the number of pulses. And to fire up the LEDs at specific intervals using most likely ISRs.

The approach I had in mind was not to try and print anything even remotely resembling a banknote. Instead, I focused my efforts in trying to get the oscilloscope traces from the photodetectors to match the reference traces I collected from the actual banknotes.

I printed a lot of various line patterns with the offsets between the lines calculated from the pulse period and diameter of the encoder wheel. This yielded some very promising results as I was able to very closely match some the traces I captured from an actual banknote. This was on the visible light spectrum sensor-pair, which is by far the easiest.

While, I was able to match some traces, this is where the defence-in-depth hit me pretty bad. It wasn’t just one or two sensor pairs I needed to match. It was five or six optical sensors, plus the tape head transducer.

To add one more dimension to this already three dimensional chess. The LED + photodetector pairs came in two forms. Pairs that look at trasmissivity through the banknote and pairs that look at reflectivity of the surface of the note. And to make matters worse the pairs operated at different areas of the spectrum. IR, UV and visible light.

The oscilloscope traces below give pretty good idea about the challenge. Just changing the paper stock has suprisingly large effect on the captured signal. The yellow trace is the pulses from the optical encoder and the blue trace is a raw signal captured from a single photodetector. These traces were captured from a sensor-pair that looks at reflectivity.

The thicker paper has better reflectivity which results in variation on the signal as the line patterns passing over the sensor reflect or absorb the emitted light. The thin paper stock on the other hand has very little reflectivity. This results in a flat trace where most of the light just travels through or is absorbed by the paper resulting in a uniform, diffused detection signal. For the thin stock, the printed line pattern isn’t picked up at all by the detector.

As there are multiple different properties, I thought it is easiest to put them all on a table and compare how various things affect on the properties. The table above attempts to cover that. For a banknote to pass the validation there would need to be green in columns for all the different properties. Yellow means it might work. As can be seen from the colours on the table. This wasn’t looking terribly good.

There were some surprising things though, like how well a paper sprayed with spray-on sunscreen actually seems to obtain similar properties than a banknote paper, namely that it doesn’t glow under UV. Banknotes are just less soggy and not as well lubricated. Spraying the sunscreen on the paper using a laser-cut stencil did actually end up showing changes in the UV photodetector trace. But not sure if it would be possible to get it to match the reference well enough.

Still, it puzzled me that how can this be precise, the photodetectors are not really that accurate nor fast. Especially, if you compare to something like a linear CCD that actually looks at what the banknote looks like. Even with all of the digging so far, I was still somewhat overly confident I would be able to fool these low-tech detectors.

So, to be able to understand how these values are actually validated and how such a seemingly low-tech approach could yield precise results, I decided to reverse engineer the firmwares. This should help me to figure out how the values are being captured, used and compared. There must be some kind of reference the values are being compared to.

Firmware reverse engineering

One of the reasons I chose the aforementioned two devices was that both of these devices handed over their firmware without much effort. One of them stored the firmware on an unencrypted SOIC-8 flash chip that was easy to dump.

The other one had the firmwares on the vendor website, in a proprietary format. Luckily, I had a tool, 7-zip, for cracking this extremely sophisticated proprietary compressed binary format known as Zip archive. Yes, they had gone as far as changing the extension from .zip to their own.

Both of the devices were using very commonly used MCUs, with all of the datasheets and reference manuals available on the chip vendors website.

As I was mainly interested in the processing of the sensor values, I started by tracing all of the photodetectors to their respective pins on the MCUs. Which in both devices, ended up being terminated to one of the GPIO blocks with ADC support. Because it takes time to reverse engineer firmware, I initially settled on the desktop one, purely because it was a bit nicer to work with and it was easier to test things and see the results on the built-in display of the device.

Knowing which channels the detectors connected to made it quite easy to start reverse engineering the firmware by first finding the functions that use the ADC registers and then go up from there to ultimately end up to the functions that use the values captured from the ADC.

Cold boot

When the device wakes after a cold boot it spends the first few hundred milliseconds teaching itself how bright its own emitters are. The firmware enables LEDs, takes sixteen ADC samples from the channel, runs them through a 256-entry normalization/gamma lookup table, averages the lot and checks whether that average sits inside a narrow window centred on a specific value.

If the resulting values from the tests are too low the LED-drive PWM is nudged up one step; if it is too high the PWM is nudged down. The process repeats, creeping a single step per iteration, until the average lands in the window - at which point the code backs the PWM off by five extra clicks to leave head-room for some drift. The results are stored on the flash to ensure the device starts from a sensible starting point at next power-up.

The same process is redone in a similar way but a bit faster prior to any banknote being inserted in the device. This is likely to detect any changes in the surrounding conditions. Take for example sun shining at low angle into the device.

Signal processing pipeline

The device seems to be using some kind of lookup table (LUT) to perform quantization and equalization. The LUT is almost linear at the low end, climbs with a gentle gamma curve in the middle and then hard-clips towards the end; it turns the raw 12-bit ADC values into 8-bit gamma corrected values.

How the ADC values flow through the processing pipeline

ADC 12-bit → LUT( ) → 0–255 ─┐
                             ├─ rolling Σx, Σy, Σxy  (histograms)
                             ├─ auto-trim            (averages)
                             └─ threshold tests      (instant values)

The ADC bytes that have travelled through the LUT feed three rolling sums that imitate different sized sliding windows over the accumulated data. Instead of pushing old samples out of a queue, the code simply subtracts a fixed constant from each accumulator before adding the new sample, so the totals always approximate the last N readings with very little math.

And all of this is wrapped neatly into a few fairly easy to follow state machines that exchange information using various status bytes on the SRAM.

The processing pipeline has three main analysis steps for each of the detectors.

• Threshold tests: Compare the instantaneous LUT value to window limits that were embedded in the flash and refreshed by the calibration.
• Auto-trim: Uses a smoothed average to close a software feedback loop that centres the signal without knowing the exact analogue transfer curve.
• Rolling histograms: Rolling sliding-window histograms feed higher-level DSP (a byte-wise cross-correlator). The rolling histograms are kept for all of the sensors and where two of the same sensors exist, these are cross-correlated in a similar manner.

Decision making

I was amazed with two things after reaching this far in the reverse engineering of the firmware.

1. The low-tech, simple sensor-emitter pairs, yield to surprisingly hard to mimic, unique “fingerprints”
2. Combining multiple sensor-emitter pairs and cleverly processing their data yields to pretty astonishing accuracy

So where does this leave us, is it possible or not?

With all of the information collected from my print tests and oscilloscope captures, as well as, the information on how the signal processing pipeline works. I had to admit a defeat.

While, I was able to closely mimic few of the sensor-pairs I don’t think even that will be good enough as I couldn’t get the whole traces to match.

The acceptance window is surprisingly small for each of the sensor-pairs and you will have to match the whole trace to ensure the histograms and auto-trim averages stay within the accepted limits. The histograms especially are surprisingly unforgiving if your print gives even partially incorrect readings.

So, credit where credit is due.

I’m not planning on changing my day job to a money printing business any time soon.