ATM Tricks (Summer, 1995)
-------------------------
By Helen Gone

During college I alternated semesters as an electrical engineering co-op
student. This was for the pursuit of bucks to stay in school and some
experience. One co-op semester, I met a group of about ten computer science
students who were pretty much forced to work 50 to 60 hours a week "testing."
Testing was looking for errors in third-party PC software. Testing was
extremely dull, boring, tedious, monotonous, etc., and it made for a lot of
unhappy co-ops who wished they had other co-op jobs. This testing was comprised
entirely of doing repetitive keystrokes with the odd batch file now and again.
Repetitive keystrokes simply meant they took each menu tree out to its very
end, filled out some paperwork, then started at the next branch, and worked it
out to the end and so on. One guy had been working on Lotus 123 for his whole
co-op. He was the unhappiest of all.

Anyway, this technique seemed relevant to my ATM interests and I soon started
some testing of my own. With as many times as I hit the ole money machine, it
was pretty easy to work the menus over pretty well for anything that seemed
soft. The task led me to begin noticing the obvious differences between the
manufacturers of ATMs, then slowly, the subtle differences between different
hardware and software revs. I've never documented any of this. I simply started
remembering the differences, especially the differences in the similar machines
that were owned/leased by different banks.

Number 1

One rev of Diebold machines began to stand out as the one with the most
problems. Its most-notable feature and flaw is its cash delivery door. You all
have used it. It's the one where the door stays locked until your cash is
delivered (and while delivering, it makes that heartwarming chug-chug-chug "oh
I got bucks" sound) at which time it starts beeping, saying: "Please lift door
and remove cash" and then makes that wonderful "bang!" sound when you crash the
door to the top to see your well-earned money laying in a stack inside this
clear anodized box. This machine became my central interest because of the
door. The designers all (mechanical/electrical/software) made a bad assumption
concerning the door. I put the three designing disciplines in that order
because that is typically the order the BS slides. Good software can usually
save the screw-ups the others make usually. The other feature/problem, which I
found during my testing, was the use of (I'll guess) a watchdog timer to
recover from software bombs. If the software did not tickle the watchdog in
some allotted time, a hardware reset would occur. The reset typically resulted
in the loss of your card. These Diebolds seemed particularly sensitive to the
hitting of Cancel during different operations. Some revs would say thank you
and spit your card back, while other revs would begin not tickling the
watchdog, and of course, reset. I soon learned that trips to different branches
of my bank for extra/replacement cards became necessary. My bank was cool in
the fact that they could make cards in-house, and I did not have to wait a
couple of weeks for the card to come back in the mail, either usable or cut up
with an ever-so-sweet letter explaining who I should call should I not
understand how to use my ATM card. Also sweet-talking the people at the bank
where the card was "captured" the next day sometimes got the card back.

Going back to the main feature/flaw, the designers made the assumption
(Assumption #1) that if a cherry switch, located somewhere inside the door
mechanism, had made closure then this meant the user, the ATMee, had removed
the bucks. We'll guess some pseudo-code might look like (just because I've
always wanted some code in 2600):

   UnloadBucks(MaxBuck$) 
   DoorWithFlawIs(UnLocked)
   Print "PLEASE OPEN DOOR AND REMOVE CASH"
   While We'reWaiting 
       EverySoOftenTickle(The WatchDog)
       TellBeeperTo(BEEP) 
       If DoorSwitch == CLOSED  then
           MaxBuck$ = Removed
           We'reNotWaiting 
       endif 
   EndWhile 
   etc.

And, ta-da! The flaw is simply that the door could be open and cash removed
without the switch ever having made closure. The switch can be heard to click
(this varies of course) around the first 1/3 motion of the door. A small hand
or a Popsicle stick works just fine with an added bonus if the myth holds true
that the camera takes your photo once the door is opened. See Assumption #1.
For completion several more things must next occur. The first is waiting. With
cash in hand and switch never closed, the machine will just loop, beeping and
asking you to remove your already removed cash. The second is the Cancel. Most
revs spit your card back at you and correctly assume that you magically removed
the money. The target rev did not behave this way. At t >= 30 seconds and
Cancel key hit, the poles shift over to that imaginary side of the plane and
the machine resets. Money in hand, card in machine, but hopefully another card
in pocket! The final chapter shows up in your monthly statement.

   DATE     AMOUNT     DESCRIPTION
   7/11     -350.00    WITHDRAW 7/11 LOC-D 1972/2002 1000 MAIN STREET USABIGBANK
   7/11     +350.00    DEPOSIT 7/11 LOC-D 1972/2002 NET RES ERROR 
                       3R3-01312000342-809 TRANS AT LOC-D BIGBANK

Assumption #2: If the machine bombs during a transaction even past the point of
delivering money, a transaction error assigns you the cash back. This weekend,
the kegger's on me, huh! I've been out of college seven years now and can say
that these machines are today quite few and far between due mostly due to the
door/switch flaw. The replacement machines have any number of configurations,
most with no doors at all or a totally different door approach. I'm pretty sure
the laws concerning tampering with ATMs have also been replaced as well.

Number 2

This one I just saw the other day is pretty much the impetus for writing this
whole article. It's not so much of a hack other than observing the plain
stupidity of a company providing customers with an ATM-like service. This
nameless company provides a card reader/keypad/terminal/printer inside their
establishment. At the terminal you swipe your card (no card capture here!),
enter your PIN, and then the amount you want. The printer promptly shells out a
receipt and informs you to take it to the counter for the bucks. After you sign
it, the salesperson then takes the receipt and gives you the amount indicated.
Simple, with the single point cash idea, and life is just way easier with this
low maintenance machine. My transaction had one slight hang-up, which was pure
coincidence. The printer became somewhat jammed and my receipt had no place for
me to sign. The receipts are quite similar to those of any credit cards where
there is a white copy on top and a yellow one for the customer underneath. At
seeing the problem, the salesperson comes over and first opens the bottom up
and fixes the jammed printer. A key is needed here. Next, enter the shaky world
of high tech computer terminal security: a five-digit code is entered into the
terminal. No magic key card swipe then code combination, just a plain old five
digit shoulder surfable code. Five digits, press Enter, and the terminal
displays "Authorized Reprint - Press Enter for Reprint." Here comes my new
receipt and the machine is back in swipe-a-card mode. Looking over my new
authorized reprint I do find one small clue to indicate this is not the
original. Easily missed, it says "Reprinted' midway down amongst a slew of
other bank babble. Sign it, get the cash, and go. Now [nameless] is a large
nationwide chain with many locations even within the city; what are the odds
that the same code will work at another location? Sure enough. Walk in, five
digits, press Enter then enter again, tear off the print out, sign it with some
mess, take it to the counter and do the ole "Boy, that Brad Pitt sure is a
cutey, huh!" distracter, and ta-da! You just got handed the same amount of
money the last person got. Since it was a non-network function, [nameless] is
the loser, the reprinted account never knows the difference. As for how do you
get the chance to shoulder surf the code? Refeed the copy on to itself? Spill
coffee on it? You see it over and over how rules that apply to the user do not
for the administrator. The user is required to have a card and code while the
administrator needs just a code. The administrator usually means many
(salespeople, managers, etc.) and the policy to direct many appears to weigh
much heavier than any fear we install.

Special thanx to FlyCac Technologies and iBruiseEasily for some thoughts and
memories.