Automated Reverse Engineering using Lego R Georg Chalupar1, Stefan Peherstorfer1, Erik Poll2, and Joeri de Ruiter2 1University of Applied Sciences Upper Austria 2Radboud University Nijmegen, The Netherlands Abstract his PIN code and buttons to cancel or confirm Internet banking transactions. A security vulnerability was dis- State machine learning is a useful technique for automat- covered in this device by a manual analysis of the USB ing reverse engineering. In essence, it involves fuzzing communication between the PC and the device and the different sequences of inputs for a system. We show that communication between the device and the smartcard. this technique can be successfully used to reverse engi- The vulnerability could be exploited by injecting mali- neer hand-held smartcard readers for Internet banking, cious USB traffic [6]. Goal of this research was to see if by using a Lego robot to operate these devices. In par- we could automate such an analysis. To be able to learn ticular, the state machines that are automatically inferred the behaviour of the reader, we therefore constructed a by the robot reveal a security vulnerability in one such Lego robot, controlled by a Raspberry Pi, that can oper- a device, the e.dentifier2, that was previously discovered ate this keyboard. Controlling all this from a laptop, we by manual analysis, and confirm the absence of this flaw then could use LearnLib [15], a software library for state in an updated version of this device. machine inference, to learn the behaviour of readers. We show that the state machine that can be learned using 1 Introduction Lego robot reveals the presence of the security flaw, and shows that the flaw is no longer present in the new ver- Finite state machines (a.k.a. finite automata) are a very sion of the device. useful formalism to model the behaviour of systems. For security-sensitive systems, they can be used to confirm 2 Background that actions can only be carried out in the correct order, e.g. that some security-sensitive action is only possible This section describes the Internet banking devices we after a successful PIN code check. Implementing a secu- analysed, and the state machine learning technique used rity protocol inevitably involves the implementation of for this. a state machine that checks that messages are only ac- cepted in the correct order. This makes state machine 2.1 The e.dentifier2 learning a very useful technique that can be used to au- tomatically reverse engineer implementations of security The e.dentifier2 is a hand-held smartcard reader with a protocols, with the view to find security flaws or confirm small display, a numeric keyboard, and OK and Cancel their absence. The vulnerabilities that can be discovered buttons (see Figure 1). It is used for Internet banking using this technique are the ones that occur when per- in combination with a bank card and a PIN code. The forming actions in an unexpected order, e.g. performing a device can be connected to a PC by USB or used without security sensitive operation before having entered a PIN USB connection. The analysis in this paper concerns the code. USB-connected mode. This paper discusses the use of state machine learn- Like most card readers used for online banking, both ing to reverse engineer smartcard readers for Internet the connected and unconnected modes of the e.dentifier2 banking, more in particular different versions of the appear to be based on EMV-CAP, a proprietary stan- e.dentifier2, a USB-connected smartcard reader that a dard by MasterCard, which in turn is based on the EMV customer operates using his bank card and PIN code. standard [10] implemented in most bank cards. The be- The smartcard reader has a keyboard for the user to enter haviour of EMV-CAP readers for Internet banking has 1 and the new version in order to see if such flaws can be automatically discovered. To be precise, we used e.dentifiers with version numbers F/W 01.02 H/W C Dec 19 2007 18:39:42 and F/W 01.05 H/W C Feb 7 2012A 14:54:39; this firmware version is shown on the display if the button 5 is pressed while a smartcard is inserted. 2.2 LearnLib The behaviour of our target – the e.dentifier2 device – can be modelled as a Mealy machine. Mealy machines are deterministic finite automata (DFAs), which produce an output on every state transition. Figure 1: The e.dentifier2 A Mealy machine M is specified by the tuple hI;O;S;s0;d;li, consisting of the input alphabet I, the output alphabet O, the states S, the initial state s0 2 S, the transition function d : S×I ! S, and the output func- been largely reverse engineered [9, 19]. In more detail, tion l : S × I ! O. We define input and output symbols during an EMV-CAP transaction, two MACs (Message as elements of I and O and input and output strings as Authentication Codes) are generated by the bank card elements of I∗ and O∗. using a secret key that is shared with the bank. Usu- We use LearnLib [15] to learn the Mealy machine im- ally, a bit filter is then applied on the first MAC and the plemented by the e.dentifier2. LearnLib uses a version Application Transaction Counter of the card to get an 8 of Angluin’s L∗ algorithm [4] optimised for Mealy ma- digit number used to confirm the transaction. However, chines. In the L∗ algorithm, a learner infers a Mealy the e.dentifier2 is slightly different from the devices dis- machine with the help of a teacher, who is assumed to cussed in [9, 19], as some additional transformation is know the Mealy machine we want to learn. performed in the device before the confirmation code is In essence, this is done by randomly trying different returned. sequences of inputs, and observing the output; if in- When the device is used without USB connection, the cluding an input makes a difference in subsequent in- user has to copy numeric challenges shown on the bank put/output responses, it is inferred that this input must web page onto the reader, after he inserted his bank card have caused an internal state change. and typed in his PIN code. The display then shows a In more detail, this is done by creating a hypothesis response, which is based on the response of the bank and iteratively refining it in a two-step process: card, that has to be entered in the web page to confirm the transaction. • First, the learner chooses input strings and obtains When the device is used with a USB connection, it is the output strings produced by the target from the controlled by the browser using JavaScript via a plugin. teacher using so called output queries. This way, it The user then does not need to manually copy numeric tries to discover different states using distinguish- challenges and responses, and more detailed (alphanu- ing strings, i.e. suffixes that produce different out- meric) information is given on the display of the device, puts for different states. For each discovered state, in particular details of any bank transfer being approved. the algorithm stores an access sequence, i.e. an in- In principle, this is more secure, as it provides WYSI- put string that reaches this state from the initial WYS (What-You-Sign-Is-What-You-See): the user can state. When every input symbol in every known understand what transaction he is approving. When the state results in a transition to another known state, user only sees meaningless random challenges, he can the model is consistent and a hypothesis automaton easily be misled by Man-in-the-Browser attacks. Unfor- is generated. tunately, a vulnerability in the device means that user ap- proval of transactions – by pressing the OK button on the • Next, the learner sends an equivalence query to the device – could actually be by-passed by malware send- teacher to check whether the hypothesis is equal to ing USB commands at unexpected stages of the protocol the target automaton. If this is not the case, the [6]. teacher replies with a counter example, i.e. an in- After discovery of the vulnerability, a new version put string which results in different outputs for the of the device was released. We used both the old target and the hypothesis automaton. 2 The learner takes a suffix of the counter example as 3 Setup additional distinguishing sequence, which will lead to a new state in the next round and updates the To learn the state machine of the e.dentifier2, as input model to produce the correct result for the counter alphabet we use the USB commands that are sent to the example. The learning process continues as long as e.dentifier2 from the PC, plus the keyboard actions of the teacher is able to find a difference between the pressing OK, pressing Cancel, or entering the PIN code. hypothesis and the target. The output alphabet is the set of USB responses that are sent back to the PC. We could also have included the output to the display We have to provide LearnLib with an input alphabet and the output to the smartcard as observable outputs of consisting of abstract input symbols. These input sym- the device, but it turns out that the USB responses are in- bols are translated by our software to real USB and robot formative enough to successfully infer the state machine commands, which we will discuss in more detail in Sec- of the device.