International Journal of Information Security

, Volume 18, Issue 1, pp 85–100 | Cite as

Reverse engineering Java Card and vulnerability exploitation: a shortcut to ROM

  • Abdelhak MesbahEmail author
  • Jean-Louis Lanet
  • Mohamed Mezghiche
Regular Contribution


Secure elements store and manipulate assets in a secure way. The most attractive assets are the cryptographic keys stored into the memory that can be used to provide secure services to a system. For this reason, secure elements are prone to attacks. But retrieving assets inside such a highly secure device is a challenging task. This paper presents the process we used to gain access to the assets in the particular case of Java Card secure element. In a Java Card, the assets are stored securely, i.e., respecting confidentiality and integrity attributes. Only the native layers can manipulate these sensitive objects. Thus, the Java interpreter, the API and the run time act as a firewall between the assets and the Java applications that one can load into the device. Finding a vulnerability into this piece of software is of a prime importance. Finding a vulnerability into a software is often not enough to develop a complete exploit. Here, we demonstrate at the end that a Java Card applet can call the hidden native functions used to decipher the secure container that encapsulates a key. Some previous attacks have shown the ability to get access to the application code area. But the Java Card intermediate byte code detected in the dumps has shown several differences with regard to the specification, which prevents the reverse engineering of the applicative code. Thus, to avoid the execution of shell code by a hostile applet, a part of the byte code stored into the card is unknown. The transformation is done on-the-fly during the upload of an application. We present in this article a new approach for reversing the unknown instruction set of the intermediate byte code which in turn has led to reverse engineering of the Java classes of the attacked card. We discovered during the reverse that some method calls have an unusual signature. Without having access to the native code, we have inferred the semantics of the called methods and their calling convention. These methods have access to the assets of the card without being restricted by security mechanisms like the firewall. We exploit this knowledge to set up a new attack that provides a full access to the cryptographic material and allows to reset the state of the card to the initial configuration. We demonstrate the ability to call these methods at the Java level in an application to retrieve sensitive assets whatever the protections are. Then, we suggest several possibilities to mitigate these attacks.


Smart card Java Card Reverse engineering Native calls Vulnerability exploitation 


  1. 1.
    Barbu, G.: On the security of Java Card\(^{\text{TM}}\) platforms against hardware attacks. PhD thesis, Grant-funded with Oberthur Technologies and Télécom ParisTech (2012)Google Scholar
  2. 2.
    Barbu, G., Thiebeauld, H., Guerin, V.: Attacks on Java Card 3.0 combining fault and logical attacks. In: Gollmann, D., Lanet, J.L., Iguchi-Cartigny J. (eds.) Smart Card Research and Advanced Application, Lecture Notes in Computer Science, vol. 6035, pp. 148–163. Springer, Berlin (2010).
  3. 3.
    Bizzotto, G., Grimaud, G.: Practical Java Card bytecode compression (2002)Google Scholar
  4. 4.
    Bouffard, G., Iguchi-Cartigny, J., Lanet, J.L.: Combined software and hardware attacks on the Java Card control flow. In: Prouff, E. (ed.) Smart Card Research and Advanced Applications, Lecture Notes in Computer Science, vol. 7079, pp. 283–296. Springer, Berlin (2011).
  5. 5.
    Bouffard, G., Lackner, M., Lanet, J.L., Loinig, J.: Heap... hop! heap is also vulnerable. In: Smart Card Research and Advanced Applications, pp. 18–31. Springer, Berlin (2014)Google Scholar
  6. 6.
    Bouffard, G., Lanet, J.: Reversing the operating system of a java based smart card. J. Comput. Virol. Hack. Tech. 10(4), 239–253 (2014).
  7. 7.
    Clausen, L.R., Schultz, U.P., Consel, C., Muller, G.: Java bytecode compression for low-end embedded systems. ACM Trans. Program. Lang. Syst. 22(3), 471–489 (2000). CrossRefGoogle Scholar
  8. 8.
    Courtois, N.T.: The dark side of security by obscurity and cloning Mifare Classic Rail and building passes, anywhere, anytime. IACR Cryptology ePrint Archive (2009)Google Scholar
  9. 9.
    EMV: EMV Testing and Certification White Paper (2013). Accessed 7 Feb 2018
  10. 10.
    Farhadi, M., Lanet, J.L.: Chronicle of a java card death. J. Comput. Virol. Hack. Tech. (2016).
  11. 11.
    Farhadi, M., Lanet, J.L.: Paper tigers: an endless fight. In: International Conference for Information Technology and Communications, pp. 40–62. Springer, Berlin (2016)Google Scholar
  12. 12.
    gemalto: Java Card and STK Applet Development Guidelines. Accessed 7 Feb 2018
  13. 13.
    GlobalPlatform, C.S.: Version 2.2. Mars (2006)Google Scholar
  14. 14.
    GSMA: Embedded UICC Protection Profile (2015). Accessed 7 Feb 2018
  15. 15.
    Hamadouche, S., Bouffard, G., Lanet, J.L., Dorsemaine, B., Nouhant, B., Magloire, A., Reygnaud, A.: Subverting byte code linker service to characterize Java Card API. In: Seventh Conference on Network and Information Systems Security (SAR-SSI), pp. 75–81 (2012)Google Scholar
  16. 16.
    Iguchi-Cartigny, J., Lanet, J.L.: Developing a Trojan applets in a smart card. J. Comput. Virol. 6(4), 343–351 (2010)CrossRefGoogle Scholar
  17. 17.
    Lancia, J., Bouffard, G.: Java Card virtual machine compromising from a bytecode verified applet. In: Smart Card Research and Advanced Applications, pp. 75–88. Springer, Berlin (2015)Google Scholar
  18. 18.
    Lanet, J.L., Bouffard, G., Lamrani, R., Chakra, R., Mestiri, A., Monsif, M., Fandi, A.: Memory forensics of a Java Card dump. In: Joye, M., Moradi, A. (eds.) Smart Card Research and Advanced Applications, Lecture Notes in Computer Science, vol. 8968, pp. 3–17. Springer, Berlin (2015).
  19. 19.
    Mesbah, A., Lanet, J.L., Mezghiche, M.: Reverse engineering a Java Card memory management algorithm. Comput. Secur. 66, 97–114 (2017)CrossRefGoogle Scholar
  20. 20.
    Mesbah, A., Regnaud, L., Lanet, J.L., Mezghiche, M.: The hell forgery, polymorphic codes shoot again. In: 15th Smart Card Research and Advanced Application Conference (2016)Google Scholar
  21. 21.
    Nohl, K.: Rooting SIM cards. In: BlackHat Conference, Las Vegas, July 31, 2013, Security Research Labs blog.
  22. 22.
    Oracle: Java Card 3 Platform, Virtual Machine Specification, Classic Edition. Version 3.0.4. Oracle, Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065 (2011)Google Scholar
  23. 23.
    oracle: Java Card Protection Profile Open Configuration (2012). Accessed 7 Feb 2018
  24. 24.
    Razafindralambo, T., Bouffard, G., Thampi, B.N., Lanet, J.L.: A dynamic syntax interpretation for java based smart card to mitigate logical attacks. In: International Conference on Security in Computer Networks and Distributed Systems, pp. 185–194. Springer, Berlin (2012)Google Scholar
  25. 25.
    Rolles, R.: Unpacking virtualization obfuscators. In: 3rd USENIX Workshop on Offensive Technologies.(WOOT) (2009)Google Scholar
  26. 26.
    Schwarz, B., Debray, S., Andrews, G.: Disassembly of executable code revisited. In: Proceedings of the Ninth Working Conference on Reverse Engineering, 2002. pp. 45–54 (2002)Google Scholar
  27. 27.
    Volokitin, S., Poll, E.: Logical attacks on secured containers of the Java Card platform. In: Smart Card Research and Advanced Applications. Springer, Berlin (2016)Google Scholar

Copyright information

© Springer-Verlag GmbH Germany, part of Springer Nature 2018

Authors and Affiliations

  • Abdelhak Mesbah
    • 1
    Email author
  • Jean-Louis Lanet
    • 2
  • Mohamed Mezghiche
    • 1
  1. 1.University of BoumerdesBoumerdesAlgeria
  2. 2.INRIA, LHS-PECRennesFrance

Personalised recommendations