VX Heaven

Library Collection Sources Engines Constructors Simulators Utilities Links Forum

Java Class infection from PE32 files

Valhalla #4
September 2013

[Back to index] [Comments]

This is my second virus to target the Java platform (Java.Sojourner was the first one), and this is my first file infector for Java classes. It is a direct action infector of Class files in current directory. A new method containing the dropper code is inserted in the Class. It uses a new EPO technique. It is the world's first W32 virus to infect Class files.

What is it?

We all know Java Class files. They are binary files that contain the code that is executed by the Java Virtual Machine. Recently, I wrote new code that inserted a virus in the form of a Class in PE32 files. The virus was able to run inside PE32 files using the Java Native Interface. This was a very simple technique.

In my article "Infecting PE files with Java Bytecode", I wrote that future viruses might be polymorphic using different techniques at source level, but also, at low-level. That is, generating the actual Java Bytecode and rebuilding or creating a Class file. I also said that we need to explore further. So, I decided to write a W32 virus since there no Class infectors of this kind. And also use some new techniques. ;)

How can we do that

Java Class file format is a bit more complicated. But it is very well documented by many sources. Firstly, we must parse a variable length table known as constant_pool[], it contains many more structures in it. This is a very important table which contains symbolic information such as strings, descriptors of various types, numbers for variables and constants, etc. We need to know its size and where it ends.

Then we must parse the interfaces[], it is a table which contains an array of indices, each index points to some structure in the constant_pool[]. It may or may not be present in the Class file. We don't need to extract any meaningful information from it. Since every index is 2 bytes long, we can use interfaces_count field in order to skip it entirely.

Then we must parse the fields[], it is a table which contains structures (field_info structures) which might contain a number of attribute_info structures. It may or may not be present in the Class file. We don't need to extract any meaningful information from it.

Here is a simple example code of how to parse it:

        lods    word ptr [esi]          ;get fields_count
        xchg    al, ah                  ;convert it to little-endian
        xchg    ecx, eax
        jecxz   parse_methods           ;if no entries then skip it

parse_ginfo     label near
        push    ecx
        movzx   ecx, word ptr [esi + field_info.attributes_count]
        lods    dword ptr [esi]         ;skip access_flags and name_index
        lods    dword ptr [esi]         ;skip descriptor_index and attributes_count
        jecxz   parse_next1             ;if no attribute_info entries then move to next field_info
        xchg cl, ch

parse_gattrb    label near
        inc     esi
        inc     esi                     ;skip attribute_name_index
        lods    dword ptr [esi]         ;get attribute_length
        bswap   eax                     ;convert it to little-endian
        add     esi, eax                ;skip the whole attribute_info
        loop    parse_gattrb            ;next attribute_info

parse_next1 label near
        pop     ecx
        loop    parse_ginfo             ;next field_info

Now we are in the most important place, the methods[]. It is a table which contain structures (method_info structures), which might contain a number of attribute_info structures. It is just like fields[]. We are looking for an attribute_info structure with an attribute_name_index which contains a valid index to an UTF8 string in the constant_pool[]. If the string matches "Code", then the structure is a Code_attribute structure. It contains the Java Bytecode of the method, it describes the stack size, the variables and exception table information, and also contains even more attribute_info structures.

To infect the file is very simple. We append the constant_pool[] inserting our constant_pool[] structures, and we can insert a new method structure in the methods[] table. We must also parse our own Java Bytecode and the entries in our constant_pool[] table that contain indices. If we insert a new method then we need to alter the code of another method to insert an invoke to our method.

EntryPoint Obscuring

In my virus for Windows 64-bit W64/Haley, I demostrated a new EPO technique using the Exception Directory. We will use the same technique here but for Java Class files. :)

My code attempts to find the Code_attribute structure that contains an exception_table entry in exception_table[]. If one is found then it alters the handler_pc field to point to the invoke. Of course, if no exception happens our code has little to no chance to execute. But I don't care about that. You can force an exception to happen using ACONST_NULL and ATHROW. However, you must be careful where you choose to write code into another method's code. A method may or may not include other attribute_info that describes some pieces of the code and contain pointers to it, then you must fix all of them. StackMapTable is a special case, if you add code and don't properly update it, the table might be invalid and the Class won't run. If you choose to erase this table, for some methods it would also cause it to leave the Class not working (specially since Class files version 50 require it). Some methods require that table, some others don't, I don't know why.

There are other possible targets for EPO techniques: hijacking methods from their CONSTANT_MethodRef_info and CONSTANT_NameAndType_info in the constant_pool[] table. Another very old-school technique would be to parse the method's code to find invoke instructions and change the index to point to the index of the virus' CONSTANT_MethodRef_info.


In this document I presented new techniques for the gaining control of the execution (like a SEH, Exception Directory hooking in Windows viruses). And also presented some other possibilities. There are Java viruses to infect Class files (that is, Class to Class infection), there is a Java virus to infect PE32 files, and now there is a W32 (PE32) virus to infect Java Class files. What about a full W32/Java cross-infector? ;)

18 September 2013
By accessing, viewing, downloading or otherwise using this content you agree to be bound by the Terms of Use! aka