Can DREs Provide Long-Lasting Security?The Case of Return-Oriented Programming and the AVC Advantage

Stephen CheckowayUC San Diego

J. Alex HaldermanU Michigan

Ariel J. FeldmanPrinceton

Edward W. FeltenPrinceton

Brian KantorUC San Diego

Hovav ShachamUC San Diego

AbstractA secure voting machine design must withstand new at-tacks devised throughout its multi-decade service life-time. In this paper, we give a case study of the long-term security of a voting machine, the Sequoia AVCAdvantage, whose design dates back to the early 80s.The AVC Advantage was designed with promising secu-rity features: its software is stored entirely in read-onlymemory and the hardware refuses to execute instructionsfetched from RAM. Nevertheless, we demonstrate that anattacker can induce the AVC Advantage to misbehavein arbitrary ways — including changing the outcome ofan election — by means of a memory cartridge contain-ing a specially-formatted payload. Our attack makes es-sential use of a recently-invented exploitation techniquecalled return-oriented programming, adapted here to theZ80 processor. In return-oriented programming, shortsnippets of benign code already present in the systemare combined to yield malicious behavior. Our resultsdemonstrate the relevance of recent ideas from systemssecurity to voting machine research, and vice versa. Wehad no access either to source code or documentation be-yond that available on Sequoia’s web site. We have cre-ated a complete vote-stealing demonstration exploit andverified that it works correctly on the actual hardware.

1 IntroductionA secure voting machine design must withstand not onlythe attacks known when it is created but also those in-vented through the design’s service lifetime. Becausethe development, certification, and procurement cycle forvoting machines is unusually slow, the service lifetimecan be twenty or thirty years. It is unrealistic to hopethat any design, however good, will remain secure for solong.1

In this paper, we give a case study of the long-termsecurity of a voting machine, the Sequoia AVC Advan-tage. The hardware design of the AVC Advantage datesback to the early 80s; recent variants, whose hardwarediffers mainly in featuring a daughterboard enabling au-dio voting for the blind [3], are still used in New Jersey,Louisiana, and elsewhere. We study the 5.00D version

The AVC Advantage voting machine we studied.

(which does not include the daughterboard) in machinesdecommissioned by Buncombe County, North Carolina,and purchased by Andrew Appel through a governmentauction site [2].

The AVC Advantage appears, in some respects, to of-fer better security features than many of the other direct-recording electronic (DRE) voting machines that havebeen studied in recent years. The hardware and softwarewere custom-designed and are specialized for use in aDRE. The entire machine firmware (for version 5.00D)fits on three 64kB EPROMs. The interface to voterslacks the touchscreen and memory card reader commonin more recent designs. The software appears to con-tain fewer memory errors, such as buffer overflows, thansome competing systems. Most interestingly, the AVCAdvantage motherboard contains circuitry disallowinginstruction fetches from RAM, making the AVC Advan-tage a true Harvard-architecture machine.2

Nevertheless, we demonstrate that the AVC Advan-tage can be induced to undertake arbitrary, attacker-chosen behavior by means of a memory cartridge con-taining a specially-formatted payload. An attacker whohas access to the machine the night before an election canuse our techniques to affect the outcome of an election byreplacing the election program with another whose vis-ible behavior is nearly indistinguishable from the legiti-mate program but that adds, removes, or changes votesas the attacker wishes. Unlike those attacks described

1

in the (contemporaneous, independent) study by Appelet al. [3, 4] that allow arbitrary computation to be in-duced, our attack does not require replacing the systemROMs or processor and does not rely on the presence ofthe daughterboard added in later revisions.

Our attack makes essential use of return-oriented pro-gramming [24, 8], an exploitation technique that allowsan attacker who controls the stack to combine short in-struction sequences already present in the system ROMinto a Turing-complete set of combinators (called “gad-gets”), from which he can synthesize any desired behav-ior. (Our exploit gains control of the stack by means ofa buffer overflow in the AVC Advantage’s processing ofa type of auxiliary cartridge; see Section 5.) Defensesthat prevent code injection, such as the AVC Advan-tage’s instruction-fetch hardware, are ineffective againstreturn-oriented programming, since it allows an attackerto induce malicious behavior using only preëxisting, be-nign code. Return-oriented programming was introducedby Shacham at CCS 2007 [24], a full two decades afterthe AVC Advantage was designed. Originally believedto apply only to the x86, return-oriented programmingwas generalized to the SPARC, a RISC architecture, byBuchanan et al. [8]. In Section 4 we show that return-oriented programming is feasible on the Z80 as well,which may be of independent interest. In addition, weshow that it is possible starting with a corpus of code anorder of magnitude smaller than previous work.

Using return-oriented programming, we have devel-oped a full demonstration exploit for the AVC Advan-tage, by which an attacker can divert any desired frac-tion of votes from one candidate to another. We havetested that this exploit works on the actual hardware; butin developing our exploit we used a simulator for the ma-chine. See Sections 5 and 6 for more on the exploit andSection 2 for more on the simulator.

Our results demonstrate the relevance of recent ideasfrom systems security to voting machine research, andvice versa. Our attack on the AVC Advantage wouldhave been impossible without return-oriented program-ming. Conversely, the AVC Advantage provides an idealtest case for return-oriented programming. In contrast toLinux, Windows, and other desktop operating systems,in which the classification of a process’ memory intoexecutable and nonexecutable regions can be changedthrough system calls, the AVC Advantage is a true Har-vard architecture: ROM is executable, RAM is nonexe-cutable.3 The corpus of benign instruction on which wedraw is just 16kB, an order of magnitude smaller than inprevious attacks.

In designing our attack, we had access neither tosource code nor to usage documentation; through reverseengineering of the hardware and software, we have re-constructed the functioning of the device. This is in con-

trast to the Appel et al. report, whose authors did havethis access, as well as to most of the previous studies ofvoting machines (discussed in Section 1.1 below). Wehad access to an AVC Advantage legitimately purchasedfrom a government surplus site by Andrew Appel [2]and a memory cartridge similarly obtained by Daniel Lo-presti. Since voting machines are frequently left unat-tended (as Ed Felten has documented, e.g., at [12]), webelieve that ours represents a realistic attack scenario.We hope that our results go some way towards answeringthe objection, frequently raised by vendors, that votingsecurity researchers enjoy unrealistic access to the sys-tems they study.4

1.1 Related workMuch of the prior research on voting machine securityhas relied on access to source code. The first such workby Kohno et al. [18] analyzed the Diebold5 AccuVote-TS voting machine and found numerous problems. Theauthors had no access to the voting machine itself but thesource code had appeared on the Internet. Many of theissues identified were independently confirmed with realvoting machines [9, 21, 22].

Follow up work by Hursti examined the AccuVote-TS6 and AccuVote-TSx voting machines using “sourcecode excerpts” and by testing the actual machines. Back-doors were found that allowed the system to be exten-sively modified [17]. Hursti’s attacks were confirmedand additional security flaws were discovered by Wag-ner et al. [27].

In 2006, building on the previous work, Feldman et al.examined an AccuVote-TS they obtained. The authorsdid not have the source code, but they note that “the be-havior of [the] machine conformed almost exactly to thebehavior specified by the source code to BallotStationversion 4.3.1” which was examined by Kohno et al. Inaddition to confirming some of the security flaws foundin the previous works, they demonstrated vote stealingsoftware and a voting machine virus that spreads via thememory cards used to load the ballot definition files andcollect election results [11].

In 2007, California Secretary of State Debra Bowendecertified and then conditionally recertified the directrecording electronic voting machines used in Californiaas part of a top-to-bottom review. As part of the re-certification, voting machine vendors were required tomake available to independent reviewers documentation,source code, and several voting machines. In all cases,significant problems were reported with the procedures,code, and hardware reviewed [6].

Also in 2007, Ohio Secretary of State Jennifer Brunnerordered project EVEREST — Evaluation and Validationof Election Related Equipment, Standards and Testing —as a comprehensive review of Ohio’s electronic voting

2

machines. Similar to California’s top-to-bottom review,the reviewers had access to voting machines and sourcecode. Again, critical security flaws were discovered [7].

2 The road to exploitationIn 1997, Buncombe County, North Carolina, purchaseda number of AVC Advantage electronic voting machinesfor $5200 each. In January 2007, they retired these ma-chines and auctioned them off through a government-surplus web site. Andrew Appel purchased one lot offive machines for $82 in total [2].

Reverse-engineering the voting machine. Two mem-bers of our team immediately began reverse engineeringthe hardware and software. The machine we examinedis an AVC Advantage revision D. It contains ten cir-cuit boards, including the motherboard shown in Fig-ure 1, with an eleventh inside the removable memorycartridge — see below. Each is an ordinary two-sidedepoxy-glass type. Since these are somewhat translucent,with the use of a bright light, magnifying glass, low-voltage continuity tester, and data sheets for the compo-nents, we were able to trace and reconstruct the circuitschematic diagram, and from that deduce how the unitworked. We filled in remaining details by partially disas-sembling the machine’s software using IDA Pro.

After approximately six man-weeks of labor, we pro-duced a functional specification [14] describing the op-eration of the hardware from the perspective of softwarerunning on the machine. We documented 47 I/O func-tions that the processor can execute to control hardwarefunctions, such as mapping areas of ROM into the addressspace, interfacing with the voter panel and operator con-trols, and reading or writing to the memory cartridge.

Reverse-engineering the results cartridge. The AVCresults cartridge is a plastic box about the dimensions ofa paperback book with a common “ribbon-style” connec-tor on one end that mates to the voting machine. Inside,there is an ordinary circuit board containing static RAMchips — backed by two type AA batteries — and commonTTL 74-series integrated circuits. There is no microcon-troller; instead all control signals come directly from thevoting machine. Much of the internal circuitry appearsto have been designed to withstand hot-plugging and toprevent accidental glitching of the memory contents.

There is an additional 8bit of nonmemory data thatcan be read from the unit corresponding to the type andrevision of the memory cartridge. This data is set by etchjumpers on the circuit board. We were able to changethe type and revision of the cartridge by cutting the as-sociated trace on the circuit card and wiring alternatejumpers.

The contents of memory can be read or written bypowering the device and toggling the appropriate input

signals. We constructed a simple microcontroller cir-cuit to interface with the cartridge to perform reads andwrites. The microcontroller simply controls the appro-priate signals on the cartridge connector to perform theoperation indicated by a controlling program communi-cating with the microcontroller via a serial port. No ac-cess to the inside circuitry was necessary.

By disassembling the software and looking at the con-tents of a valid results cartridge, we were able to under-stand the format of the file system used on the memorycartridges (and also the internal file system of the 128kBSRAM described below) and many of the files used bythe voting machine.

Crafting the exploit. Joshua Herbach used the hard-ware functional specifications to develop a simulator forthe machine [15], which another member of our teamsubsequently improved.6 Our simulator now providescycle-accurate emulation of the Z80, and it executes theAVC election software without any apparent flaws.

We developed our exploit almost entirely in the sim-ulator, only returning to the actual voting machine hard-ware at the end to validate it. Remarkably, the exploitworked the first time we tried it on the real hardware.

Total cost. Starting with no source code or schemat-ics, we reverse engineered the AVC Advantage and de-veloped a working vote-stealing attack with less than 16man-months of labor. We estimate the cost of duplicatingour effort to be about $100,000, on the private market.

3 Description of the AVC AdvantageIn this section, we give a description of the hardware andsoftware that makes up the AVC Advantage in some de-tail. Readers not interested in such low-level details areencouraged to skip ahead to Section 4, referring back tothis section for details as needed.

3.1 SoftwareThe core of the version-5.00D AVC Advantage is aZ80 CPU and three 64kB erasable, programmable ROMs(EPROMs) which contain both code and data for the Ad-vantage. Each EPROM is divided into four 16kB seg-ments: BIOS, System Toolkit, Toolkit 2, Toolkit 3, Elec-tion Program, Election Toolkit, Reports Program, Con-solidation Program, Ballot Verify Program, Define BallotProgram, Maintenance Utilities, and Setup Diagnostics;see Figure 2.

When the Advantage is powered on, execution beginsin the BIOS at address 0x0000. The BIOS contains amixture of hand-coded assembly and compiler generatedcode for interrupt handling, remapping parts of the ad-dress space (see Section 3.2), function call prologues andepilogues, thunks for calling code in other segments, andcode for interacting with the peripherals.

3

Figure 1: We reverse engineered the AVC Advantage hardware. The motherboard, shown here, is composed mostly ofdiscrete logic and measures 14in×14in. Election software is stored in removable ROM chips (white labels). The results andauxiliary memory cartridges are plugged directly into the motherboard (upper right).

Apart from the BIOS, each EPROM segment contains a16B header followed by a mixture of (mostly) compiler-generated code and data. The segments with “Toolkit”in their name7 in addition to the Reports Program con-sist of the header followed immediately by a sequence ofjp addr instructions, each of which jumps to a globalfunction in the segment. For the entries in this sequencecorresponding to global functions, there is a correspond-ing thunk in the BIOS which causes the segment to bemapped into the address space before transferring controlto the function. Functions in one segment can call globalfunctions in another segment by way of the thunks.

Each of the remaining segments is a self-containedprogram with just a single entry point immediately af-ter the segment header. When a program is run, much ofthe state of the previous program — including the stackand the heap — is reset. In particular, any data written tothe stack during one program’s execution are lost duringa second program’s execution.

A typical sequence of events for an election wouldinclude the following. The machine is powered on andbegins executing in the BIOS. The BIOS performs someinitialization and tests before transitioning to a menu inMaintenance Utilities awaiting operator input. The op-

erator selects the Setup Diagnostics choice and the cor-responding Setup Diagnostics program is run. This per-forms various software and hardware tests before tran-sitioning to the Define Ballot Program. This programchecks the memory cartridge inserted into the machineand upon finding a ballot definition transitions to the Bal-lot Verify Program. The Ballot Verify Program checksthat the format of the ballot is correct and ensures thatthe files which hold the vote counts are empty. Afterthis, it illuminates the races and candidates so that thetechnician can verify that they are correct. Assuming ev-erything is correct, control transfers to the Election Pro-gram for the pre-election logic and accuracy testing. Thevoting machine is powered off at this point and shippedto the polling places. After it has been powered back on,control again passes to the Election Program, this timefor the official election.

The ZiLOG Z80 CPU is an 8bit accumulator machine.All 8bit arithmetic and logical operations use the accu-mulator register a as a source register and the destinationregister. Apart from the accumulator register, there aresix general purpose 8bit registers b, c, d, e, h, and lwhich can be paired to form three 16bit registers bc, de,and hl. These registers along with an 8bit flags regis-

4

BIOS

System Toolkit

Toolkit 2

Toolkit 3

EPROM 1

0x0000

0x4000

0x8000

0xC000

Election Program

Election Toolkit

Reports Program

ConsolidationProgram

EPROM 2

0x0000

0x4000

0x8000

0xC000

Ballot VerifyProgram

Define BallotProgram

MaintenanceUtilities

Setup Diagnostics

EPROM 3

0x0000

0x4000

0x8000

0xC000

Figure 2: EPROM segment layout.

ter f and 16bit stack pointer sp and program counter pcregisters are compatible with the Intel 8080. In addition,there are two 16bit index registers ix and iy, an inter-rupt vector register i, a DRAM refresh counter register r,and four shadow registers af’, bc’, de’, and hl’ whichcan be swapped with the corresponding nonshadow reg-isters. The Advantage uses the shadow registers for theinterrupt handler which obviates the need to save and re-store state in the interrupt handler. See [28] for moredetails.

Due to the limited ROM space for code and data,compiler-generated functions which take arguments orhave local variables use additional functions to imple-ment the function prologue and epilogue. The prologuepushes the iy and ix registers and decrements the stackpointer to reserve room for local variables. It then setsiy to point to the first argument and ix-80h to pointto the bottom of the local stack space. Finally, it pushesthe stack-address of the two saved index registers and theaddress of the epilogue function before jumping back tothe function that called the prologue. See Figure 3. Theepilogue function pops the saved pointer to the index reg-isters and loads sp with it. Then ix and iy are poppedand the epilogue returns to the original saved pc. It is thecaller’s responsibility to pop the arguments off the stackonce the callee has returned.

3.2 Address space layout

The AVC Advantage has a 16bit flat address space di-vided into four distinct regions. The bottom 16kBis mapped to the BIOS. The 16kB–32kB range canbe mapped to one of the 12 16kB aligned segmentson the three program EPROMs. This mapping is con-trolled by the software using the Z80’s out instruction.The 32kB–63kB range addresses the bottom 31kB of a32kB, battery-backed SRAM. Finally, the top 1kB of theaddress space can be mapped to either the top 1kB of

argn

...arg1

spcsp

(a) The state of thestack immediately af-ter calling the func-tion.

argn

...arg1

spc

siy

six

locals

sp

ix

iy

epilogue

(b) The state of the stack after re-turning from the prologue func-tion.

Figure 3: The state of the stack after calling a functionwith n arguments.

the 32kB SRAM or it can be mapped to any 1kB alignedregion of a 128kB, battery-backed SRAM. This mappingcan be changed by the software using the Z80’s out in-struction. For more detail, see [14].

The AVC Advantage’s stack starts at address 0x8FFEand grows down toward smaller addresses. The heap oc-cupies a region of memory starting from an address spec-ified by the currently active program to 0xEBFF. Scat-tered throughout the rest of 32kB main memory, thereare various global variables and space for the string tableof the active program. In addition, starting at 0x934Eand growing down, there is space for a module call stackwhich allows modules to make calls to functions in othermodules, such as printf or strcpy. See Figure 4.

As the lower 32kB of the address space correspondsto EPROMs, data cannot be written to those addressesand attempts to do so are silently ignored by the hard-

5

heap

0x0000

0x4000

0x8000

0xFC00RAM Segment

RAM

ROM Segment

BIOS

Figure 4: Address space layout of the AVC Advan-tage. The dashed line represents the start of the stack at0x8FFE. The ROM and RAM Segments are the portionsof the address space mappable to the 16kB aligned seg-ments of the EPROM and 1kB aligned segments of the128kB SRAM, respectively.

ware.8 Similarly, as the upper 32kB of the address spaceis for writable memory, not program code, any attemptto fetch an instruction from those addresses raises a non-maskable interrupt (NMI). The NMI causes the processorto load a known constant into the pc register and exe-cution resumes in the BIOS where the processor will behalted after displaying an error message on the operatorLCD. This design makes the AVC Advantage a Harvard-architecture computer.

4 Return-oriented programmingSince the AVC Advantage is a Harvard architecture com-puter, traditional code injection attacks cannot succeedbecause any attempt to read an instruction from datamemory causes an NMI which will halt the machine. Inpractice, given a large enough corpus of code, this isnot a barrier to executing arbitrary code using return-oriented programming — an extension of return-to-libcattacks where the attacker supplies a malicious stack con-taining pointers to short instruction sequences endingwith a ret [24, 8].

The Z80 instruction set is very dense. Every byte iseither a valid opcode or is a prefix byte. As there are noinvalid or privileged instructions, instruction decoding ofany sequence of data always succeeds. This density facil-itates return-oriented programming since we can exploitunintended instruction sequences to build gadgets — asequence of pointers to instruction sequences endingwith a ret. For a concrete example, the BIOS containsthe code fragment ld bc,2; ret— a potentially use-ful instruction sequence in its own right — which is 0102 00 c9 in hex where the first three bytes are theload and the last is the return. If we set the programcounter one byte into the load instruction, then we get theinstruction sequence 02 00 c9 corresponding to the

three instructions ld (bc),a; nop; ret which storesthe value of the accumulator into memory at the addresspointed to by the register bc.

Shacham [24] and later Buchanan et al. [8] had codecorpora on the order of a megabyte from which to con-struct gadgets. In contrast, Francillon and Castelluc-cia [13] had only 1978B of code with which to craft gad-gets; however, they did not construct a Turing-completeset of gadgets. This prompts the question: What is theminimal amount of code required to construct a Turing-complete set of gadgets? By constructing a Turing-complete set of gadgets using only the AVC Advantage’sBIOS — which consists of 16kB of code and data — wemake progress toward answering that question.

Following Shacham, we wrote a small program tofind sequences of instructions ending in ret. We ranthis program on the AVC Advantage’s BIOS. We thenmanually devised a Turing-complete set of gadgets fromthe instruction sequences found by our program, in-cluding gadgets to control the peripherals like the LCDsand memory cartridges. We build a collection of gad-gets that implement a 16bit memory-to-memory pseudo-assembly language. See Table 1 for a description of thepseudo-assembly language and Appendix A for the im-plementation of many of the gadgets and a precise expla-nation of the notation that will be used in the remainderof the paper.

(We stress that demonstrating return-oriented pro-gramming on the Z80 is a major contribution of this paperand of independent interest; we have moved the details toan appendix to improve the paper’s flow.)

Some of the gadgets in Table 1 are straightforward toconstruct; others require more finesse due to tricky in-teractions among the registers used in the instruction se-quences. For ease of implementation, no state is pre-sumed to be preserved between gadgets. That is, all ar-guments are loaded from memory into registers, operatedupon, and then stored back into memory.9 In this way,each gadget can be reasoned about independently. Theoperands to the gadgets are either global variables — de-clared with the .var directive — or immediate values;labels are resolved to offsets and thus are immediate val-ues.

Some of the instruction sequences described in Ap-pendix A contain NUL bytes which make them unsuitablefor use in stack smashing attacks using a string copy. Anearly implementation of the gadgets took great pains toavoid all zero bytes. However, using the multi-stage ex-ploit described below, avoiding zero bytes was unneces-sary except for in the first stage of the exploit which didnot use the gadgets presented in this section. As such,the simpler form of the gadgets is presented.

It has become traditional in papers on return-orientedprogramming to show a sorting algorithm implemented

6

Table 1: The return-oriented pseudo-assembly language for the AVC Advantage consists of seven directives and 39 mnemon-ics. An uppercase letter denotes a variable as defined by the .var directive and n denotes a 16bit literal.† Register bc is set to C and the least significant byte of A is used for the accumulator.‡ The AVC Advantage has a watchdog timer that raises a non-maskable interrupt if it is not reset often enough. See [14].

Mnemonic Description

.ascii "str" Inserts the bytes for str

.asciiz "str" .ascii "str"; .byte 0

.byte b,... Insert a byte for each argument

.data n Inserts n NUL bytes

.var A,n Define a new 16bit variable A atlocation n

.word n,... Insert a word for each argumentlabel: Define a new labeladd A,B,C A← B+Caddi A,B,n A← B+nand A,B,C A← B &Cb label Branch to labelbtr A,label Branch to label if A is truebfa A,label Branch to label if A is falsecall SP,label Push address of the next gadget

to stack at SP, jump to labelcpl A,B A←∼Bdec A A← A−1di Disable interruptsei Enable interruptshalt Halt the machinein A,C in a,(c)†

inc A A← A+1jr A Jump to address A

Mnemonic Description

la A,B Set A to the address of Bla A,label Set A to the address at labelld A,n(B) A← (B+n)ldx A,B,C A← (B+C)li A,n A← nmov A,B A← Bmul A,B,C A← B×Cneg A,B A←−Bnop Do nothingor A,B,C A← B |Cout C,A out (c),a†

pet Pet the watchdog timer‡

pop SP,A A← (SP); SP← SP+2push SP,A SP← SP−2; (SP)← Apushi SP,n SP← SP−2; (SP)← nret SP Pop from stack at SP, jump to valueseq A,B,C A← B = Cslt A,B,C A← B < Cslti A,B,n A← B < nsne A,B,C A← B 6= Csrl A,B,s A← B� sst A,n(B) (B+n)← Astx A,B,C (B+C)← Asub A,B,C A← B−C

as a return-oriented program [8, 16]. In Appendix B, wegive the listing for a return-oriented Quicksort. We haveverified that this sorting algorithm works on the actualAVC Advantage as part of a larger program that prints alist of numbers on the printer, sorts them, and prints thesorted list.

5 A multi-stage exploit for the AVC Advan-tage

Even though many parts of the code we reverse engi-neered appear to handle data from memory cartridgessafely, we have been able to find a stack buffer overflowvulnerability. In this section, we describe this vulnerabil-ity and discuss how an attacker can exploit it to overwritethe AVC Advantage’s stack and reliably induce the exe-cution of a return-oriented payload of his choice.

We stress that the buffer overflow that we have identi-fied appears to be unrelated to the one identified by Appelet al. in their report [3, Section II.26]. Our buffer over-flow occurs in cartridge processing whereas Appel et al.’soccurs in interaction with the daughterboard (which themachine we studied lacks); our overflow requires manualaction, whereas Appel et al.’s is triggered on boot; our

overflow is exploitable for diverting the machine’s con-trol flow, whereas Appel et al.’s appears to allow only adenial of service. We do not know whether the overflowthat we found persists in the more recent AVC Advantageversion that Appel et al. examined.

One of the programs not normally used in an election,but accessible from the main menu, contains a bufferoverflow while reading from an auxiliary cartridge of acertain type. (As described in Section 2, we physicallymodified a results cartridge so that the AVC Advantagewould recognize it as a cartridge of the type for which theappropriate menu item is enabled.) A maliciously craftedfield in one of the files allows roughly a dozen bytes tobe written at the location of the saved stack pointer. Inthe first stage of the exploit, the hl register is set andthe stack pointer is modified using the sp ← hl in-struction sequence, inducing a return-oriented jump toan attacker-controlled location in memory.

For stage two, a section of memory under attacker con-trol needs to contain gadgets. Fortunately (for the at-tacker), a file of fixed size but with several dozen unusedbytes is read from the memory cartridge into a buffer al-located by malloc. By the time of the overflow in stage

7

Figure 5: The machine has slots for two memory car-tridges. The first cartridge stores ballots and votes. Anattacker could install vote sealing code by inserting a pre-pared cartridge into the second slot.

one, this buffer has been deallocated but most of its con-tents remain in memory at a known location. This unusedspace can be changed to contain gadgets that make upthe second stage of the exploit. The first thing that stagetwo does is reallocate memory for the buffer so that ad-ditional allocations will not overlap and thus write overthe gadgets. At the same time, enough memory is allo-cated to hold the contents of an additional file from thememory cartridge. The data from this file — stage threeof the exploit — is read into the allocated buffer. Controlthen transfers to stage three which can perform arbitrarycode execution using the gadgets described in Section 4.

We have tested on an AVC Advantage that the exploitprocedure described in this section works, using it both torun the sorting program described in the previous sectionand the vote-stealing exploit described in the next.

6 Using the exploit to steal votesWe have designed and implemented a demonstrationvote-stealing exploit for the AVC Advantage, using thevulnerability described in the previous section to takeover the machine’s control flow. We have tested that ourexploit works on the actual AVC Advantage. (Althoughit was designed and debugged exclusively in our simula-

tor, the exploit worked on the real hardware on the firsttry.) In this section, we describe both the actions that anattacker will undertake to introduce the exploit payloadto the machine and the behavior of the payload itself.We also note several ways in which the exploit could bemade more resistant to detection by means of forensicinvestigation.

Our attacker accesses the AVC Advantage when it isleft unattended the night before the election. Ed Feltenhas described how such access is often possible (see, e.g.,[12]). At this point, the machine has been loaded withan election definition and has passed pre-LAT.10 The at-tacker picks the locks for the back cabinet, the voterpanel, and (later) the open/close polls switch. Appel et al.have shown that these locks are of a low-security kindthat is easily bypassed [3, Section I.9]. The attacker doesnot need to remove any tamper-evident seals; in particu-lar, he does not need to remove the circuit-board cover.

Having gained access to the back cabinet of the AVCAdvantage, the attacker uses the normal functions toopen the polls, cast a single vote, and close the polls.(The polls cannot be closed with no votes cast.11) Oncethe polls are closed, the attacker unseats the results car-tridge. The cartridge cannot be removed completely be-cause of the tamper-evident seal; however, the seal issmall enough compared to the holes through which itis inserted that the cartridge can be disconnected fromthe machine. With the polls closed and the cartridgeremoved, the attacker uses the two-key reset gesture(“print-more” and “test”) to gain access to the machine’spost-election menu. From this menu, he can reset the ma-chine; after the reset, the machine’s main menu is acces-sible. (Were the results cartridge not removed, the dataon it would be erased by the reset. The attacker mightbe able to recreate this data and rewrite it to the resultscartridge, but unseating the cartridge before the reset ob-viates this.)

To this point, the attacker is simply following the sameprocedures poll workers and election officials use in run-ning an election and resetting the AVC Advantage forthe next election. His goal is to gain access to the mainmenu, from which he can direct the machine toward thevulnerability described in Section 5.

The system reset appears to clear the audit logs on themachine. Our demonstration vote-stealing exploit doesnot undo this log-clearing, though a more stealthy attackmight wish to; otherwise, a post-election audit might dis-cover that log entries are missing. (Although, as Davtyanet al. have found in their audit of the AccuVote AV-OSsystem [10], discrepancies in logs are not uncommon andmay not be perceived as signs of an attack.) Even ifthe attack is detected, the original voter intent will notbe recoverable. The attacker can use the post-electionmenu to dump the contents of the logs either to a trans-

8

fer cartridge or to the printer and cause his exploit pay-load to restore them once the system is compromised.In addition, since a vote was cast, the protective counterhas been incremented; however, the protective counteris subject to software manipulation and could easily berolled back if the attacker desires. Traces of the phantomvote might also remain in the machine or operator logs; ifso, a stealthy exploit would have to remove these traces.

The attacker now reinserts the results cartridge and acartridge of the appropriate type into the auxiliary portand navigates the menus to trigger the vulnerability de-scribed in Section 5. Using a three-stage exploit as de-scribed in Section 5, he takes control of the AVC Advan-tage and can execute arbitrary (return-oriented) code.

Note that hardware miniaturization since the designof the AVC Advantage makes possible the creation ofcartridges much smaller than legitimate cartridges withorders of magnitude more storage. (Different parts ofmemory could be paged in using a “secret knock” proto-col.) A smaller cartridge may allow the attacker to by-pass tamper-evident loops placed on the auxiliary portguide rails that would prevent the insertion of a legiti-mate cartridge (although we are not aware of a jurisdic-tion that attempts to limit access to the auxiliary port inthis way); it may also allow him to leave an auxiliarycartridge in place during voting while avoiding detec-tion, which would be useful for exploit payloads largerthan can fit in main memory and unused portions of theresults cartridge. (As noted below, our exploit payloadeasily fits in main memory.)

The exploit first restores those parts of the machine’sstate necessary to allow the election to begin again.It copies the results cartridge’s post-LAT voting files(which are in their empty state) over the results car-tridge’s election files so that the single ballot that wascast in order to close the polls is erased. It then copies(most of) the contents of the results cartridge into the in-ternal memory. At this point, a message is displayed onthe operator LCD instructing the attacker to remove theauxiliary cartridge and turn off the power.

In order to convincingly simulate power off, we needthe power switch to be in the off position. Luckily, theAVC Advantage has a soft power switch, so turning thepower knob just sets a flag that can be polled by the pro-cessor at interrupt time to detect power off. So long as theexploit code disables interrupts (while petting the watch-dog timer to keep it from firing) it can keep the machinerunning; it can also detect when, later, the power switchis turned to the on position. (By contrast, were the ma-chine actually to power down, the stack would be reset ona subsequent power up and the attacker would lose con-trol.) The AVC Advantage features a large 110V batterydesigned for 16 hours of operation that we believe willallow it to remain overnight in this state [23]. Of all the

steps in our exploit, this is the one that most intimatelyrelies on the details of the AVC Advantage’s hardwareimplementation. We emphasize that we have tested onthe actual machine that our exploit code is able to sur-vive a power-down/power-up cycle in this way on batterypower alone.

When the exploit code detects that the power switchhas been turned to the off position, it simulates powerdown. It turns off the LEDs in the voter panel, clears theLCD displays, and turns off any status LEDs. In testingon an AVC Advantage, we have been able to disable (viareturn-oriented code) all indicators of power except theLCD backlight on the operator panel. This is the mostvisible sign of our attack; we are currently studying howthe backlight might be disabled.

The attacker now closes and locks the operator andvoter panels, removes the auxiliary cartridge, and leaves.The next morning, poll workers open the machine anduse the power switch to turn it on. The exploit codedetects the change and simulates the machine’s power-up behavior, followed by the official election mode mes-sages.

The exploit must now simulate the machine’s normalbehavior when poll workers open and close the polls andwhen voters cast votes. While it would be possible toreimplement this behavior entirely using return-orientedcode, the design of the AVC Advantage’s voting programmakes it possible for us to reuse large portions of the le-gitimate code, making the exploit smaller, simpler, andmore robust. This would be more difficult to do if theexploit modified votes as they were cast, but we haveinstead chosen to wait until polls are closed and onlythen change the cast votes retroactively. The absence ofa paper audit trail means that the vote modification willnot be detected. Other possible designs for vote-stealingsoftware are described by Appel et al. [3, Section I.5–6].

The main voting function is structured as a seriesof function calls that can be separated into three maingroups, each called a single time in order in the normalcase. The first group of functions waits for the “open/-close polls” switch to be set to open and prints the zerotape. The second group of functions handles all of thevoting, including waiting for the activate button to bepressed and handling all voter input. Once the polls areclosed, the third group of functions handles printing thefinal results tape and all post-election tasks.

Our demonstration exploit uses the high-level func-tions in the AVC Advantage’s legitimate voting programto handle all voting until the polls are closed. Then theexploit reads the vote totals, moves half of the votes forthe second candidate to the first candidate, and changesthe cast vote records (CVRs) to match the vote totals.(Obviously, any fraction of the votes could be modified.Furthermore, while our exploit processes the CVR log in

9

order, changing every CVR cast for the disfavored can-didate until the desired shift has been effected, more so-phisticated strategies are possible.) The exploit now re-linquishes control for good, handing control over to thelegitimate AVC Advantage program to handle all post-election behavior. When the “Official Election ResultsReport” is printed it will reflect the results as modifiedby the exploit.

The AVC Advantage contains routines to check theconsistency of its internal data structures. When the datais inconsistent, e.g., the vote totals do not match the CVRtotals, this is noted in the Results Report. The exploit en-sures that all data structures in memory and on the resultscartridge that are checked by these routines are consistentwhenever the routines are executed.

Even after it has relinquished control, our exploit re-mains in main memory until the machine is shut down.Forensic analysis of the contents of the AVC Advantage’sRAM would be a nontrivial task; nevertheless, a stealthierexploit would wipe itself from memory before returningcontrol to the legitimate program. If any portion of theexploit code is stored on a cartridge, this must be wipedas well. Because suspicious poll workers might removethe cartridge before it can be wiped, anything stored on acartridge should be kept encrypted, and the exploit codeshould scrub the key from RAM if it detects that the car-tridge has been removed.

Our vote-stealing demonstration exploit is just over3.2kB in size, including all of the code to copy the filesand the memory cart. It fits entirely in RAM, as wouldeven a substantially more sophisticated exploit: There isroughly an additional 10kB of unused heap space thatcould be used. In addition, any code that is executedonly while the attacker is present need not actually stayin the heap once it is finished and could be replaced withadditional code for modifying the election outcome.

7 ConclusionsA secure voting machine design must withstand attacksdevised throughout the machine’s service lifetime. Canreal designs, even ones with promising security features,provide such long-term security? In this paper, we haveanswered this question in the negative in the case ofthe Sequoia AVC Advantage (version 5.00D). We havedemonstrated that an attacker can exploit vulnerabilitiesin the AVC Advantage software to install vote-stealingmalware by using a maliciously-formatted memory car-tridge, without replacing the system ROMs. Starting withno source code, schematics, or nonpublic documenta-tion, we reverse engineered the AVC Advantage and de-veloped a working vote-stealing attack with less than 16man-months of labor. Our exploit relies in a fundamen-tal way on return-oriented programming, a technique in-troduced some two decades after the AVC Advantage

was designed. In mounting the attack, we have extendedreturn-oriented programming to the Z80 processor.

AcknowledgmentsWe thank Andrew Appel for allowing us to use his AVCAdvantage machines, and for helpful discussions aboutelection procedures. We thank Daniel Lopresti for lend-ing us an AVC Advantage results cartridge. We thankJoshua Herbach for developing the initial version of theAVC Advantage simulator [15]. We thank Eric Rescorlaand Stefan Savage for helpful discussions.

References[1] Alfred V. Aho, Ravi Sethi, and Jeffrey D. Ullman. Com-

pilers: Principles, Techniques, and Tools. Addison-Wesley Longman Publishing Co., Inc., Boston, MA,USA, 1986.

[2] Andrew W. Appel. How I bought used voting machineson the Internet, February 2007. http://www.cs.princeton.edu/~appel/avc/.

[3] Andrew W. Appel, Maia Ginsburg, Harri Hursti,Brian W. Kernighan, Christopher D. Richards,and Gang Tan. Insecurities and inaccuracies ofthe Sequoia AVC Advantage 9.00H DRE vot-ing machine, October 2008. Online: http://citp.princeton.edu/voting/advantage/advantage-insecurities-redacted.pdf.

[4] Andrew W. Appel, Maia Ginsburg, Harri Hursti, Brian W.Kernighan, Christopher D. Richards, Gang Tan, andPenny Venetis. The New Jersey voting-machine law-suit and the AVC Advantage DRE voting machine. InDavid Jefferson, Joseph Lorenzo Hall, and Tal Moran,editors, Proceedings of EVT/WOTE 2009. USENIX/AC-CURATE/IAVoSS, August 2009.

[5] Yonatan Aumann, Yan Zong Ding, and Michael Rabin.Everlasting security in the bounded storage model. IEEETrans. Info. Theory, 48(6):1668–80, June 2002.

[6] California Secretary of State Debra Bowen. “Top-to-Bottom” Review of voting machines certified for usein California. Technical report, California Secretary ofState, 2007. http://sos.ca.gov/elections/elections.vsr.htm.

[7] Ohio Secretary of State Jennifer Brunner. Evalua-tion & Validation of Election-Related Equipment, Stan-dards & Testing. Technical report, Ohio Secretaryof State, 2007. http://www.sos.state.oh.us/SOS/Text.aspx?page=4512.

[8] Erik Buchanan, Ryan Roemer, Hovav Shacham, and Ste-fan Savage. When good instructions go bad: Generalizingreturn-oriented programming to RISC. In Paul Syversonand Somesh Jha, editors, Proceedings of CCS 2008, pages27–38. ACM Press, October 2008.

[9] Compuware Corporation. Direct recording electronic(DRE) technical security assessment report, November2003.

10

[10] Seda Davtyan, Sotiris Kentros, Aggelos Kiayias, LaurentMichel, Nicolas Nicolaou, Alexander Russell, AndrewSee, Narasimha Shashidhar, and Alexander A. Shvarts-man. Pre-election testing and post-election audit of op-tical scan voting terminal memory cards. In David Dilland Tadayoshi Kohno, editors, Proceedings of EVT 2008.USENIX/ACCURATE, July 2008.

[11] Ariel J. Feldman, J. Alex Halderman, and Edward W. Fel-ten. Security analysis of the Diebold AccuVote-TS votingmachine. In Ray Martinez and David Wagner, editors,Proceedings of EVT 2007. USENIX/ACCURATE, Au-gust 2007. http://itpolicy.princeton.edu/voting/ts-paper.pdf.

[12] Edward W. Felten. NJ election day: Votingmachine status, June 2008. http://www.freedom-to-tinker.com/blog/felten/nj-election-day-voting-machine-status.

[13] Aurélien Francillon and Claude Castelluccia. Code in-jection attacks on Harvard-architecture devices. In PaulSyverson and Somesh Jha, editors, Proceedings of CCS2008, pages 15–26. ACM Press, October 2008.

[14] J. Alex Halderman and Ariel J. Feldman. AVC Ad-vantage: Hardware functional specifications. Techni-cal Report TR-816-08, Department of Computer Science,Princeton University, Princeton, New Jersey, March 2008.

[15] Joshua S. Herbach. Simulating the Sequoia AVCAdvantage DRE voting machine, May 2007.http://www.cs.princeton.edu/~herbach/SimulatingAVCAdvantage.pdf.

[16] Ralf Hund, Thorsten Holz, and Felix Freiling. Return-oriented rootkits: Bypassing kernel code integrity protec-tion mechanisms. In Fabian Monrose, editor, Proceedingsof Usenix Security 2009. USENIX, August 2009. To ap-pear.

[17] Harri Hursti. Critical security issues with Diebold TSx,May 2006.

[18] Tadayoshi Kohno, Adam Stubblefield, Aviel D. Rubin,and Dan S. Wallach. Analysis of an electronic voting sys-tem. In David A. Wagner and Michael Waidner, editors,Proceedings of Security and Privacy (“Oakland”) 2004,pages 27–40. IEEE Computer Society, May 2004.

[19] Sebastian Krahmer. x86-64 buffer overflow ex-ploits and the borrowed code chunks exploitation tech-nique, September 2005. http://www.suse.de/~krahmer/no-nx.pdf.

[20] Tal Moran and Moni Naor. Receipt-free universally-verifiable voting with everlasting privacy. In CynthiaDwork, editor, Proceedings of Crypto 2006, volume4117 of LNCS, pages 373–92. Springer-Verlag, Septem-ber 2006.

[21] RABA Innovative Solution Cell. Trusted agent report:Diebold AccuVote-TS voting system, January 2004.

[22] Science Applications International Corporation. Risk as-sessment report Diebold AccuVote-TS voting system andprocesses, September 2003.

[23] Sequoia Voting Systems. AVC Advantage.http://www.verifiedvotingfoundation.org/downloads/AVCAdvantage.pdf.

[24] Hovav Shacham. The geometry of innocent flesh onthe bone: Return-into-libc without function calls (on thex86). In Sabrina De Capitani di Vimercati and Paul Syver-son, editors, Proceedings of CCS 2007, pages 552–61.ACM Press, October 2007.

[25] Sequoia Voting Systems. Response from Sequoia Vot-ing Systems to the California Secretary of State’s officeon the Top-to-Bottom Review of Voting Systems, July2007. http://www.sequoiavote.com/press.php?ID=32.

[26] Sequoia Voting Systems. Response from Sequoia VotingSystems to the expert report of Andrew W. Appelevaluating the security and accuracy of the SequoiaAVC Advantage DRE voting computer, October 2008.http://www.sequoiavote.com/documents/SVS_Response_to_Appel_report_NJ.pdf.

[27] David Wagner, David Jefferson, and Matt Bishop. Secu-rity analysis of the Diebold AccuBasic interpreter, Febru-ary 2006.

[28] ZiLOG Inc., San Jose, CA, USA. Z80 Family CPU UserManual, 2004.

A Implementing the gadgetsThis appendix describes the construction of a number ofthe gadgets listed in Table 1. Many of the omitted onesare quite similar to those detailed below.

A.1 A note on notationIn what follows, typewriter font uppercase letters —e.g., A— are used to represent global variables which areliteral 16bit locations in memory. The value associatedwith a variable A is written in an italic font A. Literalnumbers are written with italic font lowercase letters —e.g., n. Z80 assembly is written in a typewriterfont with mnemonics and register names written withbold weight — e.g., ld b,FFh. Abbreviated instruc-tion sequence forms (see below) and the gadget pseudo-assembly language are written in typewriter font —e.g., b ← 0xFF and add A,B,C, respectively. In fig-ures, nonabbreviated instruction sequences are boxed. InZ80 assembly, hexadecimal numbers are written with atrailing h as is customary. Otherwise, the C notation isfollowed by prepending 0x.

Each box in the following figures of the gadgets rep-resents a two-byte stack slot. Each slot contains either aliteral value — either fixed for a particular gadget or theaddress of a global variable or code offset — or the ad-dress of an instruction sequence. The literal values arewritten as either hexadecimal numbers or symbolically.Addresses of instruction sequences are represented as ar-rows pointing to either the abbreviated form of an in-struction sequence or the boxed text of the sequence it-

11

self. Each gadget is entered by the processor executing aret with the stack pointer pointing to the bottom of thegadget. The instruction sequences are executed in orderfrom bottom to top.

A.2 Moving data aroundAny set of useful gadgets needs to contain gadgets tomove data between memory and registers as well as gad-gets for loading registers with constant values. At a mini-mum, this should include gadgets for loading immediatesto registers, loading from memory into registers, movingvalues between registers, and storing values from regis-ters into memory.

Loading immediate values is as simple as using in-struction sequences like

# pop hl, depop hlpop deret

which loads the next two stack slots into registers hland de. There are instruction sequences to load each in-dividual register as well as many combinations of regis-ters.

Loading values from memory — e.g., from a globalvariable — requires loading register hl with the addressof the variable and then using one of the two sequences

# bc ← (hl)ld c,(hl)inc hlld b,(hl)ret

# hl ← (hl)ld a,(hl)inc hlld h,(hl)ld l,aret

which load the 16bit value pointed to by hl into eitherbc or hl.

Once the operands are in registers, other instructionsequences can operate on them. After the computation iscomplete, the value needs to be stored back into memory.The most common way of storing values back to memoryis to place the result in register hl and the target addressin de. Then the sequence

# (de) ← hlex de,hl # swap de and hlld (hl),e # *inc hlld (hl),dret

will perform the store. Notice that if we use the sequencestarting at the instruction marked with * instead, we have

the instruction sequence (hl) ← de which is occa-sionally useful as well. To store a single byte into boththe high and low byte of a variable, the following se-quence can be used.

# (hl) ← a; (hl+1) ← ald (hl),ainc hlld (hl),aret

Two simple gadgets for loading an immediate valueinto a variable (li A,n) and moving the value of onevariable into another (mov A,B) are given in Figure 6.Rather than duplicate the full text of each instruction,common sequences are given in the abbreviated form thatappears in the comments above. The li gadget first popsthe address of variable A into register hl and the immedi-ate value into register de. Then the value in de is storedto the address pointed to by hl. The mov gadget is simi-lar except that de holds the target address — the addressof variable A— while hl gets the address of variable Band then the value B.

The three main 16bit registers bc, de, and hl are notinterchangeable as far as our set of instruction sequencesare concerned. Many operations can only be performedusing a single sequence and that sequence expects itsoperands to be in particular registers. As a result, weneed a way to move data among the three registers. Tothat end, we have the following three useful instructionsequences.

# bc ← hlld c,lld b,hret

# de ↔ hlex de,hlld bc,1ret

# hl ← bcld h,bld b,lld l,cld c,aret

The first simply copies hl to bc without disturbing any-thing else. The other two destroy the contents of bc inthe process. For hl ← bc, one could first use the se-quence a ← b, l ← a, and a ← c. In this way, thecontents of bc would be preserved. This is not necessaryfor the gadgets we construct.

In addition to immediate loads and moves, we imple-ment base plus offset and base plus index loads and storesfor moving data around. The base plus offset instruc-

12

A

n

pop hl, de

(hl) ← de

(a) li A,n

B

A

pop hl, de

hl ← (hl)

(de) ← hl

(b) mov A,B

Figure 6: Gadgets for loading a variable A with either an immediate value n or the value of another variable B.

tions ld (resp. st) take a base register and an immedi-ate offset which is added to the base to form the source(resp. target) address. The base plus index instructionsldx (resp. stx) take a base register and an index reg-ister which are summed to form the source (resp. target)address. The implementation is a straight-forward exten-sion of the mov gadget and the addition gadget describedin the next subsection.

A.3 ArithmeticWe show how to perform addition. The rest of the arith-metic and logic operations are similar, apart from themultiplication, which is discussed below.

Addition can be performed by loading the addendsinto registers, performing the addition, and storing theresult into the result variable. The following, more-generally useful instruction sequence can be used to per-form the last two steps, thus saving stack space.

# (de) ← hl + bcadd hl,bcex de,hlld (hl),einc hlld (hl),dret

The add gadget is given in Figure 7 (a).The Z80 does not contain a multiply instruction. In-

stead, this has to be computed in software. Because mul-tiplication is a common operation, the BIOS contains afunction which takes arguments — the multiplicands —in registers bc and de and returns with the product inregister bc. Since register hl is used in the computation,it is first pushed to the stack and then popped before thefunction exits. The address of the instruction just afterthe push hl, is the bc ← bc * de; pop hl se-quence. To use this sequence, we need only load bc andde with the appropriate values, taking care to load defirst since the de ↔ hl sequence sets bc as well. Themul A,B,C gadget is given in Figure 7 (b).

A.4 BranchingIn order to perform interesting and useful computationwith gadgets, they need to be able to effect a jump orbranch. Since it may not be possible to know exactlywhere the return-oriented-programming stack will be lo-cated in memory, it is preferable to write gadgets in a

position independent manner. The way to do this is toensure that all branching is done using relative offsets.The pop hl instruction sequence can be used to loadhl with a suitable displacement d to the desired location.Then the sequence

# sp ← sp + hladd hl,spld sp,hlret

can be used to change the stack pointer by d to point toanother gadget. In effect, changing control to the othergadget. These two instruction sequences are exactly howthe branch gadget b label is implemented.

Without conditional code execution, a set of gadgetscan only be used to execute essentially straight-line codeusing Krahmer’s borrowed code chunks technique [19]so we must have a way to do conditional branches. Fol-lowing a MIPS-like ISA, we implement a set less thangadget slt A,B,C that sets A to 0xFFFF if B < Cand 0x0000 otherwise. These values act as boolean trueand false. Similarly, we implement a set not equal gad-get sne A,B,C that sets A to 0xFFFF if B 6= C and0x0000 otherwise.

The slt gadget is given in Figure 8 (a). It works byfirst loading bc with the value C and hl with the value B.Then the accumulator a is cleared which has the effect ofclearing the carry flag. Next, B−C is computed whichsets the carry flag if B < C. The next sequence clears csince a is zero. The penultimate sequence has the effectof setting a to 0xFF if B < C otherwise a is set to 0x00.In addition, it loads hl with the variable A. Lastly, a isstored into both (hl) and (hl+1), effectively settingA to either 0xFFFF or 0x0000 depending on B < C ornot.

Similar to the set less than gadget, we implement a setnot equal gadget sne A,B,C that sets A to 0xFFFF ifB 6= C and 0x0000 if they are equal. The implementa-tion is given in Figure 8 (b). It is identical to the set lessthan up through the subtract. After that, it uses an in-struction sequence that does one of two things dependingon the state of the zero flag. If B = C, then the subtractwill set the zero flag. In this case, the jr z,(pc+4) willjump to the pop hl instruction causing hl to be loadedwith 0xFFFF and subsequently setting bc to 0x0000.If B 6= C, then the zero flag will be cleared and pop bc

13

C

A

B

pop hl, de

bc ← (hl)

pop hl

hl ← (hl)

(de) ← hl + bc

(a) add A,B,C

C

B

0xABCD

pop hl, de

hl ← (hl)

de ↔ hl

bc ← (hl)

bc ← bc * de; pop hl

hl ← bc

pop de

(de) ← hl

(b) mul A,B,C

Figure 7: Arithmetic gadgets.

C

B

A

pop hl

bc ← (hl)

pop hl

hl ← (hl)

a ← 0

hl ← hl - bc - carry

ld c,aret

sbc a,aadd a,cpop hlret

(hl) ← a, (hl+1) ← a

(a) slt A,B,C

C

B

0xFFFF

A

pop hl

bc ← (hl)

pop hl

hl ← (hl)

a ← 0

hl ← hl - bc - carry

jr z,(pc+4)pop bcretpop hlld bc,0ret

add a,cpop hlret

(hl) ← a, (hl+1) ← a

(b) sne A,B,C

Figure 8: Inequality tests.

will load 0xFFFF into bc. The next instruction se-quence will add c to the accumulator which was previ-ously set to zero, thus setting a to either 0xFF or 0x00and load hl with the variable A. The final sequence setsA appropriately.

While not strictly necessary, a set equal gadget is eas-ily constructed by adding the following sequence whichsets the accumulator to its one’s complement.

# a ← ~acplor aret

Once we have boolean values 0xFFFF and 0x0000,we can perform conditional branches by taking the bit-wise conjunction of our boolean value and the branchoffset. Due to the interactions between the registers in theavailable instruction sequences, performing the conjunc-tion is tricky since the only conjunction we have avail-able uses the accumulator and register c. Even worse, itmodifies register bc in the process. Once we have com-puted the conjunction of a single byte, we need to place itinto either register h or l depending on it being the highor low byte of the conjunction, respectively. The follow-ing three instruction sequences perform the the conjunc-tion and the loading of h and l.

# a ← a & c;# bc ← bc-1and cdec bcret

# l ← ald l,aret

# h ← a;# l ← l + 1ld h,ainc lret

Since the sequence for moving the value from the accu-mulator to h increments l, we need to load h before weload l.

The branch if true gadget btr A,label whichbranches to label if A = 0xFFFF is given in Figure 9.If the offset from the end of the gadget to label is d,then let d′ be the byte reversed value of d. The btr gad-get starts by loading d′ into bc. Since this value is byte-reversed, register c contains the high-order byte of theoffset d. The boolean variable A is also loaded into de.The low-order byte of A is loaded into the accumulator

14

d′A

pop bc, de

ld a,(de)ret

a ← a & c; bc ← bc - 1

bc ← bc + 1

h ← a; l ← l + 1

ld c,badd a,dret

ld a,(de)ret

a ← a & c; bc ← bc - 1

l ← a

sp ← sp + hl

Figure 9: btr A,label. The immediate value d′ isthe byte-reversed offset d from the end of the gadget tolabel.

and the bitwise conjunction with c is stored into the accu-mulator. Since bc was decremented, the next instructionsequence increments it. The accumulator is then storedinto h and b— the low-order byte of d — is moved intoc. The accumulator is again loaded with the low orderbyte of A, the conjunction is performed and the resultplaced in l. At this point, hl contains the bitwise con-junction d & A. If A = 0xFFFF, then the next sequencewill branch to the offset d. If A = 0x0000, then the nextsequence will do nothing.

By inserting two a ← ~a instruction sequences afterthe two a ← (de) sequences, a branch if false gadgetbfa A,label is constructed. Once we have the slt,sne, btr, and bfa gadgets, we can perform conditionalbranches using numerical equality and inequality. Wethus have a Turing-complete set of gadgets.

A.5 FunctionsTo support a more natural imperative style of program-ming, we implement return-oriented function calls. Thereturn-oriented nature of our program means that the callstack is unavailable for use with return-oriented func-tions since our code resides on the stack. Instead, weneed to designate a variable SP as a stack pointer for usewith the stack manipulation gadgets push, pop, call,and ret.

Following the convention of the Z80, a push SP,Agadget first decrements SP by 2 and then stores A to (SP).A pop SP,A gadget first sets A to (SP) and then incre-ments SP by 2. The call SP,label gadget computesthe address of the following gadget and pushes that ontothe stack pointed to by SP and then branches to label.Finally, the ret SP gadget pops a value off of the stackand branches to it. The call gadget uses the sp ←sp + hl instruction sequence with register hl set to0x0000 to move the value of sp into hl in order tocompute the address of the following gadget to push onthe stack. The rest of the call and ret gadgets arestraight-forward and given in Figure 10. The push andpop gadgets are similar.

B An example return-oriented program

.var sp,0xF000

.var array,0xF002 # saved

.var left,0xF004 # saved

.var right,0xF006 # saved

.var temp1,0xF00A # not saved

.var temp2,0xF00C # not saved

.var index,0xF00E # not saved

.var i,0xF010 # not saved

.var pivot,0xF012 # not savedqsort: # void qsort( array, left, right )

push arraypush leftpush rightpetld left,10(sp)ld right,12(sp)slt temp1,left,rightbfa temp1,cleanupld array,8(sp)ldx pivot,array,rightmov index,leftmov i,left

loop:slt temp1,i,rightbfa temp1,breakldx temp1,array,islt temp2,pivot,temp1btr temp2,continueldx temp2,array,indexstx temp2,array,istx temp1,array,indexaddi index,index,2

continue:addi i,i,2b loop

break:ldx temp1,array,indexldx temp2,array,rightstx temp2,array,indexstx temp1,array,rightaddi temp1,index,-2push temp1push leftaddi left,index,2push arraycall qsortaddi sp,sp,6push rightpush leftpush arraycall qsortaddi sp,sp,6

cleanup:pop rightpop leftpop arrayret

15

SP

SP

0xFFFE

0x0000

0x000C

d

pop hl, de

bc ← (hl)

pop hl

(de) ← hl + bc

pop hl

sp ← sp + hl

pop bc

(de) ← hl + bc

pop hl

sp ← sp + hl

(a) call SP,label. The im-mediate value d is the offset fromthe end of the gadget to label.

SP

SP

0x0002

pop hl, de

bc ← (hl)

pop hl

(de) ← hl + bc

hl ← bc

hl ← (hl)

ld sp,hlret

(b) ret SP

Figure 10: Function call and return gadgets.

As an example of performing general purpose compu-tation, the preceding return-oriented function performsthe Quicksort algorithm on its input using the gadgetsfrom Table 1. This example “pets” the watchdog timerto keep it from firing in the middle of computation andcausing a non-maskable interrupt.

Notes1A related notion to long-lasting security is Moran and

Naor’s “everlasting privacy” requirement for crypto-graphic voting schemes [20], itself based on Aumann,Ding, and Rabin’s “everlasting security” [5].

2A Harvard-architecture machine has separate data andinstruction memories, in contrast to a von Neumann-architecture machine, which has a single memory forboth instructions and data.

3Even in Francillon and Castelluccia’s attack on aMica sensor-network node [13], return-oriented pro-gramming — or, more properly, chunk borrowing à laKrahmer [19], since Turing-completeness is not neces-sary — is used only to fill a staging area with native codethat will be installed on reboot by the bootloader.

4See, e.g., Sequoia’s response to the Top-to-Bottom Re-view: “In short, the Red Team was able to, using a finan-cial institution as an example, take away the locked frontdoor of the bank branch, remove the security guard, re-move the bank tellers, remove the panic alarm that no-tifies law enforcement, and have only slightly limitedresources (particularly time and knowledge) to pick thelock on the bank vault” [25].

5Now Premier Election Solutions.6Following the “Chinese wall” protocol, the simulator

developers had no access to the actual hardware and re-lied exclusively on our published specifications.

7The name of a segment is contained within the seg-ment and there is a field in the segment header whichpoints to the name.

8It is possible to install a 32kB “Program” SRAM andmap the 16kB–32kB address range to either of the two16kB aligned regions of the SRAM, but no AVC Ad-vantage used in elections has such a Program SRAM in-stalled [26].

9The gadgets could be made more efficient by not writ-ing values back to memory except as needed. This wouldsignificantly complicate hand crafting return-orientedcode, but this sort of optimization is well-understood inthe compiler-writing community; for example, register-allocation algorithms [1]. This sort of optimization canlead to a drastic reduction in return-oriented code sizeand run time.10The AVC Advantage has two Logic and AccuracyTesting phases which are meant to test that the votingmachine is in working order. The pre-LAT phase alwayshappens prior to the election and a post-LAT phase mayoccur after the election, depending on policy.11This is actually a configuration option. Any machinesconfigured to allow the polls to be closed without anyvotes cast can skip the vote casting step. In this case,there is no need to modify the protective counter later,simplifying the exploit somewhat.

16