{"id":856,"date":"2014-02-16T11:33:13","date_gmt":"2014-02-16T10:33:13","guid":{"rendered":"http:\/\/blog.rewolf.pl\/blog\/?p=856"},"modified":"2015-06-01T22:35:56","modified_gmt":"2015-06-01T20:35:56","slug":"solving-warsaws-java-crackme-3","status":"publish","type":"post","link":"http:\/\/blog.rewolf.pl\/blog\/?p=856","title":{"rendered":"Solving warsaw’s Java Crackme 3"},"content":{"rendered":"

Every once in a while I’m posting solution to some crackme that I consider interesting. By interesting<\/em>, I mean the solution, so it is not exactly about key generation algorithm but also about technology and tricks that are utilized. Looking at the traffic statistics, it seems that this topic isn’t exactly the one that people would like to read (three posts – 5,63% of total unique page views), but I’m truly convinced that it has great potential for every single person that wants to learn something new. All in all, there is at least one person that benefits from those tutorials – ME :) Back to the topic, in this post I’ll describe warsaw’s Java Crackme 3<\/a>. Crackme was published on 14th October 2012<\/em> on crackmes.de<\/a>, I’ve picked it up around February 2013, so literally speaking, it took me one year to solve it (of course I had some huge breaks meanwhile). Difficulty of the crackme was set to 5 (Professional problem to solve<\/em>) in the crackmes.de scale and I must fully agree with it. It is Java <\/strong>crackme, but it wasn’t written in Java<\/strong>, I’m 99% sure that it was written in Jasmin <\/strong>or other assembler for Java Virtual Machine<\/strong> (JVM<\/strong>). Hand-crafted assembler and bunch of obfuscation tricks renders all existing decompilers pretty much useless, so it will not be yet another simple Java <\/strong>analysis.<\/p>\n

<\/p>\n

Table of Contents<\/h3>\n

\n

    \n
  1. First Blood (initial analysis)<\/a><\/li>\n
  2. First Blood Part II (second attempt)<\/a><\/li>\n
  3. Obfuscation tricks<\/a>\n
    \n
    Exception records<\/a><\/dd>\n
    JSR instruction<\/a><\/dd>\n
    GOTO instruction<\/a><\/dd>\n
    Anti-disasm trick<\/a><\/dd>\n
    Modifications applied before debug session<\/a><\/dd>\n<\/dl>\n<\/li>\n
  4. Algorithm analysis<\/a><\/li>\n
  5. Algorithm reversing<\/a><\/li>\n
  6. Final words<\/a><\/li>\n<\/ol>\n

    First Blood (initial analysis)<\/a><\/h3>\n

    Crackme is shipped as a JAR <\/strong>file, there is one .class file inside called CON.class<\/em>. I’m not sure how it looks on UNIX but on windows CON <\/strong>is forbidden name and CON.class<\/em> file cannot be easily created on disk, so to unpack this file, one need to change file name inside JAR <\/strong>archive (or use 7zip<\/strong>, it changes it to _CON.class<\/em> automatically). Such file with changed name will not run, as JVM <\/strong>treats file name as a class name. To get it working without jar file, class name inside a .class file needs to be changed to _CON<\/strong>, but I’ll get back to this topic later. JAR <\/strong>file with crackme is very small: 2620 bytes<\/em>, it doesn’t have any fancy GUI, just command line interface:<\/p>\n

    x:\\xxx>java -jar crackme3.jar\r\nPlease enter a key on the command line.\r\n\r\nx:\\xxx>java -jar crackme3.jar test\r\nIncorrect!\r\n<\/pre>\n
    As a first step, I’ve tried to use java decompiler, but results generated by JD-Gui<\/strong> and JAD <\/strong>are not even worth mentioning. My second try was dirtyJOE<\/strong>, as it is really nice tool to quickly check what is really inside a .class file. There is only one method defined: main<\/strong>, it has 22 exception records<\/strong> (it doesn’t look good, trust me) and the code is pretty much mind blowing. There are a lot of monitorenter<\/strong>\/monitorexit <\/strong>opcodes, some random goto<\/strong>, few jsr <\/strong>(jump subroutine<\/em>) and even one athrow<\/strong>. Level of complication is nicely visible on the screen-shot from IDA <\/strong>graph view:<\/p>\n
    \"crackme3_graph\"<\/a><\/p>\n
    As you can see, there are multiple entry points to the main<\/strong> method, there are even separate group of blocks not connected with the main execution path. I had an idea to manually rebuild proper code flow and recompile it so maybe some decompiler would work with this code, but I’ve realized rather quickly that it doesn’t make any sense, as I’ll not be able to properly rebuild all those peculiar links between so many exception handlers. That was the end of my first attempt at this crackme. What I knew, is that I need java bytecode debugger<\/strong> and it doesn’t exist…<\/p>\n
    First Blood Part II<\/a><\/h3>\n
    Second attempt was taken few months later, after researching java bytecode debugging stuff. You can read about it in my previous post: Java bytecode debugging<\/a>. As I’ve mentioned in that post, there was still something missing to fully experience java bytecode debugging<\/em> in a fashion similar to x86 debugging<\/em>:<\/p>\n
    (…) Java VM is a stack based virtual machine, which means that most of all opcodes operates on the operand stack. Having information about values pushed onto the stack sometimes can be crucial to understand what is really going on. Unfortunately neither JDB nor JSwat supports previewing of jvm operand stack. This is an unresolved problem for now.<\/p><\/blockquote>\n
    Well, recently I’ve resolved this problem and it enabled me to properly debug this crackme. I’ve wrote small tool called JVM Operand Stack Viewer<\/strong> (very original name!) – currently it’s private, because it wasn’t extensively tested – but I’ll be merging it with dirtyJOE <\/strong>very soon (or not), so stay tuned. Below you can find screen-shot of my java debugging environment, it is basically:<\/p>\n