Hi All,

I stumbled across this Java target recently and (to my untrained Java eye) it appears to be a bit unique. The target is called VisualRoute5.1c and it is available to be downloaded from:

http://download.cnet.com/downloads/0-10145-100-5197284.html?tag=st.dl.10145-106-1.lst-3-13.5197284

First off, I'll be upfront here and admit this is the very first Java protection I've attempted, but I think I can honestly say I've investigated it pretty thouroughly for someone who's never composed a Java bytecode in their life

Here are my findings so far:

The protection seems to consist of 3 main parts:

1) An .exe loader which loads the main .class file via the MS wjview commandline Java class loader.
2) The main class file named vr.class
3) An encrypted vr.bin file

Using JAD to decompile the vr.class file, I discovered that it functions as a loader itself, decrypting and dynamically loading a portion of the vr.bin file as a new class. This appears to be the sole purpose of vr.class and there are no other references to the protection at this point.

Realizing this, I inserted a couple of lines of code to write out the decrypted portion of the vr.bin to disk. Now, I have a new class file which is fully decompilable with JAD. Decompiling my new class, I soon discover that it too possesses loader functionality. Like the original class, it too appears to decrypt a part of that .bin file and dynamically load a new class. ...And here is where I've become stuck....

A couple of ideas have crossed my mind, but I haven't been able to successfully implement them yet (even assuming they would be worthwhile approaches)... Here they are anyway though:

1) First, I thought to rewrite the original class such that it would load the new class from my decrypted disk image. If it was reading the class from my decrypted version, I figured I could make another patch which would write out the next decrypted class to disk before it was loaded just like I did for the first one. So far I haven't managed to successfully rewrite the original loader - probably due to the fact that I've never coded in Java before and many of its "object oriented" intracicies seem to elude my "procedural programming" background.

2) Secondly, I thought to piggyback some of the code where it reads / decrypts the .bin in the second loader, into my original loader and recompile it. For this idea, all I can say is that it recompiled and wrote an empty file... Of course I could have easily done something wrong / overlooked something here too.

After having worked on this for some days now and read quite a few of the (quite scarce) Java Reversing tuts, I have to admit I'm stumped. I'm not sure what the next attack should be or indeed if I am even approaching this protection from the right direction. It would seem that the only tools at my disposal are my JAD decompiler and Filemon. I downloaded a *rudimentary* Java debugger, but it has proved all but worthless for these dynamically loaded classes.

At this point my brain is melting :'( and I'll REALLY appreciate any insight / help / tips anyone can provide.

BTW, in case you just want to take a quick look w/o downloading the target, I'm attaching my 2 decompiled .class files to this post. There is both the original class and my decrypted class within.
original class = vr.jad
decrypted class = vr1.jad

Thanks In Advance :-)

Regards,
Clandestiny

Hi Clandestiny,

Well, you tweaked my interest on this one. Before I started I knew dick-all about Java. Now I know only slightly more than dick-all but, undaunted by my ignorance, I press on ;p But I digress.

Looking at the Filemon output it looks like there are numerous classes decrypted from the original vr.bin file. None of these classes are written to disc however, so I figured they must be being run from memory. So I took a look at things from the more familiar confines of Softice.

Tracing into the original loader VisualRoute.exe shows it calling CreateProcessA with the executable name and command line parameters 'wjview /cp vr', which as you mentioned is loading the vr.class file in the MS Java loader. After this is a WaitForSingleObject call which apparently passes control to the loader.

To follow the code from this point I set a bpx on K32Thk1632Prolog, which sets up the stack frame for any system Calls that follow. F11 out of the break and F8 into the next Call (just before K32Thk1632Epilog) and you can trace into whatever program code is called next from Kernel32.

After a couple of calls to OLE32, progam flow led into Msjava.dll at:

0167:7A99691C PUSH EBP
0167:7A99691D MOV EBP,ESP
0167:7A99691F MOV EAX,[EBP+0C]
0167:7A996922 PUSH ESI
0167:7A996923 SUB EAX,00000439
0167:7A996928 JNZ 7A99694B (NO JUMP)
MSJAVA!.text+591A

It seems this is where the java classes in the vr.bin file are "unpacked". This code is called several times, (with a new value in eax) and each time it seems there is new java code in memory (I dumped a total of 46000 bytes of code, and that was only up to the nag box showing!) This code continues to be called once the main window begins to show. The memory address for me began at 1090000.

I haven't been able to disassemble any of the dump(s) with JAD yet, but it seems this is a parsing problem. I get the error message "JavaClassFileParseException: Not a class file (incorrect magic)". The ASCII in the dumps are clearly Java though.

Sooo, I'm wondering if you could patch Msjava.dll to write each class to disc as it's produced. You'd have to find exactly where in the code the class has been decrypted. Or maybe there's a table with all the class names with pointers to the rest of the Java code somewhere. Take a look at Msjava.dll in Exescope and maybe you can load it in winice.dat and break on some of the likely functions (Class_GetName perhaps?). If this works, Filemon shows that the program looks for Msjava.dll in its home directory first, so you could have a patched version just for Visual Routes.

I haven't gone any further with this, but I think the above address in Msjava.dll would definitely be a starting point to figure out how all the classes are decrypted from vr.bin.

BTW, what was the code you wrote to write out the decrypted portion of vr.bin?

Kayaker

Hiya Kayaker,

First let me say thanks for the reply . Your suggestion to include the msjava.dll in the winice exports really put things in back into perspective for me. From reading your post, it seems we approached the task on 2 different levels. I was trying to attack it from a strictly source code level, ie. decompiling the .class, injecting code to get it to write out the 'unpacked' class to disk, and then recompiling. Of course, I ran into trouble when I realized it was 'unpacking' another loader which it would use to decrypt and load another class... ad infinitum. Being as I don't know dick-all about Java either, I couldn't get a coding solution to work (ie. rewrite the loader to load the patched, 'unpacked' classes from disk). And every tut I've read on Java reversing lead me to believe SoftICE was useless with Java. Well, apparently that belief is a misconception (at least in this case). Stick with the tools you know, eh ? And who ever heard of Java unpacking anyway ?

Things are finally looking up over here though :-) Following your advice, I included the Msjava.dll into my winice.dat exports and then proceeded to disassemble it to get a listing of all of my bpx options.
And whaddya know ? I recognized the defineClass() function straight from the decompilation of the original vr.class and ClassLoader class its inherited from. Now, I've done more investigation that I want into that Java ClassLoader class and I knew I'd found the ticket right there. Indeed, defineClass is one of the ClassLoader class's very own functions.

***************************************************************

defineClass
protected final Class defineClass(byte data[],
int offset,
int length)

Converts an array of bytes to an instance of class Class. Before the Class can be used it must be resolved.

Parameters:
data - the bytes that make up the Class
offset - the start offset of the Class data
length - the length of the Class data

Returns:
the Class object which was created from the data

***************************************************************

Now, I had everything I needed. All I needed to do was fire up Visual Route in the Sice loader, set a bpx on java_lang_ClassLoader_defineClass0 and wait for Sice to break. Looking at the parameters pushed on the stack and my definition of the defineClass I had both the pointer to the location in memory of my 'unpacked' class and its size.

017F:014E0FFC 8B5508 MOV EDX,[EBP+08] 
017F:014E0FFF 897D04 MOV [EBP+04],EDI 
017F:014E1002 896E08 MOV [ESI+08],EBP
017F:014E1005 FF7510 PUSH DWORD PTR [EBP+10] //the size of the class in memory
017F:014E1008 FF7514 PUSH DWORD PTR [EBP+14] //the offset where the class begins (0)
017F:014E100B FF7518 PUSH DWORD PTR [EBP+18] //the pointer to the class image in memory
017F:014E100E FF751C PUSH DWORD PTR [EBP+1C]
017F:014E1011 FF7520 PUSH DWORD PTR [EBP+20]
017F:014E1014 FF5214 CALL [EDX+14] //call loadClass function here
017F:014E1017 81C414000000 ADD ESP,00000014
017F:014E101D 837DEC00 CMP DWORD PTR [EBP-14],00
017F:014E1021 64891D00000000 MOV FS:[00000000],EBX
017F:014E1028 7526 JNZ 014E1050
017F:014E102A F6460455 TEST BYTE PTR [ESI+04],55

Using IceDump I was now sucessfully able to dump the class from memory using the pointer and size from the defineClass parameters. In doing this though I noticed a pecularity (which may have been responsible for the Parse Errors you got from your dumps). It seems that the class pointer from the defineClass function is offset by 8 bytes. Indeed, there seems to be a signature sequence of bytes that defines the beginning of a class and enables you to tell where it begins. Having examined the structure of several other classes now, it seems to be :

CA FE BA BE 00 03 00 2D

By dumping with the pointer + 8 and class size, I was able to get a perfect JAD decompilation of my first 'unpacked' class (named Console.class, btw). And thats about where I am right now. I'm in the process of dumping all of the dynamically loaded classes. When I get them all dumped, I'm optomistic that the protection won't be too hard to find.

What a novelty, "unpacking" a Java app. And they tout Java as being a "secure" language... I guess we've just proved its vulnerable to the "tried an' true" after all

Thanks again for your help, Kayaker Let me know if you get your dumps working.

Cheers,
Clandestiny

hmmm.....using Sice on JAVA....I trust an essay will be coming eventually? ;-)

Hi All,

Did anyone say you couldn't use Softice with Java?

Here's my contribution, just for ?ferret. You handle the rest of it Clandestiny

Clandestiny, that was the spot alright! Just before the Call [edx+14] to java_lang_ClassLoader_defineClass0 in msjava.dll you can dump all the java classes just as you said. After doing a few of these I got bored with it and decided to try patching msjava.dll itself to do all the dumping.

BTW, that Call [edx+14] address just seems to be sitting in memory somewhere, no module name given in SI. Do you think that is the ASM for vr.class? And if it is, might you not also be able to code some java lines to dump each class as they come around? Not being able to code this in java myself, I did it with an inline patch.

It worked and I got 130 class files out of it. Then it was 1 line in JAD to decompile them all to readable .jad files. I was considering releasing a patcher for msjava.dll, but I'll just up a zipped copy of my dll. It may not work on everybodys system. It's a Win98SE version, v5.00.3167, File date Apr23 '99, File size 942,080 bytes. Let me know how it goes.

What I did was to set a bp on java_lang_ClassLoader_defineClass0 and immediately jump to the inline patch from there. The Virtual Size needs to be set to the Raw Size (D8000), and the characteristics to E0000020.

Here's the jump point:

------------------------------------------
msjava!com_ms_security_SecurityClassLoader_internalDefineClass
:7A9B7BF2 E9090F0B00 JMP 7AA68B00 ;jump to patch
:7A9B7BF7 90 NOP
:7A9B7BF8 8B4508 MOV EAX,[EBP+08] ;return point
------------------------------------------

The variables:

------------------------------------
000D8AB0 433A 5C4A 6176 6100 2E63 6C61 7373 0000 C:\Java..class..
000D8AC0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000D8AD0 2558 0000 0000 0000 0000 0000 0000 0000 %X..............
000D8AE0 0000 0000 0000 0000 0000 0000 0000 0000 ................

D8AB0 = 7AA68AB0 = "C:\Java"
D8AB8 = 7AA68AB8 = ".class"
D8AC0 = 7AA68AC0 = 3 full dwords for null terminated "dword to ascii" conversion. I used this to increment the filenames (i.e. Java1.class to JavaFFFFFFFF.class)
D8ACC = 7AA68ACC = filename incrementer
D8AD0 = 7AA68AD0 = wsprintfA format-control string (%X)
D8AD4 = 7AA68AD4 = store object handle for CreateFileA
D8AD8 = 7AA68AD8 = pointer to number of bytes written for WriteFile
D8AE0 = 7AA68AE0 = buffer for lstrcpy/lstrcat commands, and final filename
---------------------------------------

...continued...

And the patch:

--------------------------------------
:7AA68B00 60 PUSHAD ;save registers
:7AA68B01 FF05CC8AA67A INC DWORD PTR [7AA68ACC] ;increment filename counter
:7AA68B07 FF35CC8AA67A PUSH DWORD PTR [7AA68ACC]
:7AA68B0D 68D08AA67A PUSH 7AA68AD0
:7AA68B12 68C08AA67A PUSH 7AA68AC0
:7AA68B17 E875CA4E45 CALL USER32!wsprintfA ;converts incremented dword to ascii
:7AA68B1C 58 POP EAX ;silly non-conventional wsprintf
:7AA68B1D 58 POP EAX ;needs the 3 dwords that were pushed
:7AA68B1E 58 POP EAX ; popped off the stack!

:7AA68B1F 68B08AA67A PUSH 7AA68AB0
:7AA68B24 68E08AA67A PUSH 7AA68AE0 ;filename buffer
:7AA68B29 E8CAE75045 CALL KERNEL32!lstrcpy ;copy "C:\Java" to buffer
:7AA68B2E 68C08AA67A PUSH 7AA68AC0
:7AA68B33 68E08AA67A PUSH 7AA68AE0
:7AA68B38 E832E85045 CALL KERNEL32!lstrcat ;concatenate with incremented ascii
:7AA68B3D 68B88AA67A PUSH 7AA68AB8
:7AA68B42 68E08AA67A PUSH 7AA68AE0
:7AA68B47 E823E85045 CALL KERNEL32!lstrcat ;concatenate with ".class"

:7AA68B4C 6A00 PUSH 00
:7AA68B4E 6A20 PUSH 20
:7AA68B50 6A02 PUSH 02
:7AA68B52 6A00 PUSH 00
:7AA68B54 6A01 PUSH 01
:7AA68B56 6800000040 PUSH 40000000
:7AA68B5B 68E08AA67A PUSH 7AA68AE0 ; pointer to filename
:7AA68B60 E876EF5045 CALL KERNEL32!CreateFileA
:7AA68B65 A3D48AA67A MOV [7AA68AD4],EAX ;save object handle
:7AA68B6A 6A00 PUSH 00
:7AA68B6C 68D88AA67A PUSH 7AA68AD8 ;# bytes written
:7AA68B71 FF7510 PUSH DWORD PTR [EBP+10] ;size of class
:7AA68B74 8B4518 MOV EAX,[EBP+18] ;start of class signature
:7AA68B77 83C008 ADD EAX,08 ;8 bytes to the right is
:7AA68B7A 50 PUSH EAX ;start of class proper
:7AA68B7B FF35D48AA67A PUSH DWORD PTR [7AA68AD4] ;object handle
:7AA68B81 E84BE45045 CALL KERNEL32!WriteFile ;write the damn thing
:7AA68B86 FF35D48AA67A PUSH DWORD PTR [7AA68AD4]
:7AA68B8C E8DC545145 CALL KERNEL32!CloseHandle ;close its handle

:7AA68B91 FC CLD ;routine for zeroing out filename buffer
:7AA68B92 BFE08AA67A MOV EDI,7AA68AE0
:7AA68B97 B906000000 MOV ECX,00000006
:7AA68B9C 33C0 XOR EAX,EAX
:7AA68B9E AB STOSD
:7AA68B9F 49 DEC ECX
:7AA68BA0 83F900 CMP ECX,00
:7AA68BA3 75F9 JNZ 7AA68B9E

:7AA68BA5 61 POPAD ;restore registers
:7AA68BA6 55 PUSH EBP ;replace original code
:7AA68BA7 8BEC MOV EBP,ESP
:7AA68BA9 83EC24 SUB ESP,24
:7AA68BAC E947F0F4FF JMP 7A9B7BF8 ;jump back to program code
--------------------------------------

I haven't tried the patched msjava.dll with any other java apps. Might work. Might not. Usual disclaimer applies. Haven't found the protection in the decompiled class files either but KeyValueLine.jad looks interesting

This was fun! Regards,
Kayaker

Hi Kayaker,

GREAT job on the Java dumper I tried it out today and it works perfectly. One problem though... By any chance did you get a decompiled V.class ? I'm badly needing a copy of it and it does not show up in my listing of dumped classes which is strange given that Splash.class needs it loaded in order to run. If you've got a copy over there from your dump, please send it over to me. I'm getting ready to test my Java class reloader patch to MsJava.dll, but I need to get a recompilable version of my patched class. Right now I've *almost* got Splash.class to recompile for me, but I've had a big problem with the imports Damn Java compiler has *way* to much error checking I found out that I basically had to recreate the directory structure of the Java "package" of imported and referenced classes for Splash.class in order to get it to recompile. I've got em all but that V.class which I can't find to save my life.

Later,
Clandestiny

Sure Clandestiny, check your mail.

I tried it with another Java app, and it dumped its class files, but these weren't packed in a .bin file anyway, so all it did was duplicate the class files that were already present. At least it indicates that the patch should work as a class dumper in all cases.

Kayaker

Very Cool 8)

Very nice approach on this one, congratulations!

I've done this application myself in the past, but I coded a decrypter for vip.class, your approach is much clever. Will you be releasing the class dumper anytime soon? ;-)

Clandestiny, you can restore package directory structure by using "jad -d decompiled -r *.class", and you'll get everything in the place it should be. V.class is actually the class where the protection resides, as far as I remember.

Keep up the nice work. :-)

Thanks Duelist. Clandestiny did the hard work of ferreting out java_lang_ClassLoader_defineClass0 from the mess of import functions, I just whipped off a dumb dumper patch.

Ahh, but a stand-alone class dumper utility that will work on any system? Yes, that's the next logical step and I've already begun work on the idea. The 1st thing I'd like to do is parse each class in memory to get the original filename, instead of just saving them to a default name.

If anybody finds any more apps with these encrypted/packed class files, I think both of us would appreciate word of it just for testing purposes.

Cheers,
Kayaker

Hi guys!

I've came across this app some time ago. Few notes: it is pure (almost) java and no tampering with Windows native dlls is needed. The dll is just bootstrapper to run java VM - if you have JDK or runtime installed try to run 'java vr'. If you decompile vr.class found in the install dir - you'll see as you rightly mentioned that it functions as class loader to load from vr.bin. The vr.bin contains classes that are mangled - the vr.class does the loading and decoding. So I have taken the decompiled vr.class (using jad) and reworked it a bit to dumper - pure java...works on all platforms
Also if you look into data directories there are filesnames that end with '+' - those are crypted too. So I have taken a look and made the decryptor.
A small note: the included sources worked with older versions - in the last one I think they did this:
vr.class loads another vr.class from vr.bin - the values or algorithm is a bit different (uses other constants) - so you have to dump the vr.class from vr.bin and then use that as a base for dumper.

Hope this helps and brings a java approach to this...

Rex

As it seems there can only be 1 attachement I post source code to dumper here and as attachement will be the decoder for *.txt+ files....
---------------- file dumper.java starts here ----------------------------
// Dumps all classes from vr.bin and puts the .class files to appropriate dirs
// Made by Rex
// usage: java dumper

import java.io.*;
import java.util.Hashtable;
import java.util.Enumeration;
import java.util.StringTokenizer;

public class dumper
{

public dumper()
{
g_by = null;
g_cl = new Hashtable();
}

public static void main(String [] args)
{
(new dumper()).dumpAll();
}

private static String eName(String s)
{
char ac[] = s.toCharArray();
for(int i = 0; i < ac.length; i++)
ac[I] ^= 'Z';

return new String(ac);
}

public void dumpAll()
{
char c = File.separatorChar;
if(g_by == null)
{
g_by = new Hashtable();
long l = 0xea1255adaabefa07L;
RandomAccessFile randomaccessfile = null;
try
{
randomaccessfile = new RandomAccessFile("vr.bin", "r";
randomaccessfile.seek(randomaccessfile.readInt() != 0xdeadfeed ? 0 : randomaccessfile.readInt());
while(randomaccessfile.getFilePointer() < randomaccessfile.length() && l == randomaccessfile.readLong())
{
String s1 = randomaccessfile.readUTF();
byte abyte2[] = new byte[randomaccessfile.readInt()];
int k = randomaccessfile.readInt();
randomaccessfile.readFully(abyte2);
if(k == 1)
g_by.put(s1, abyte2);
}

}
catch(Exception exception)
{
System.out.println(exception.toString());
}
finally
{
try
{
randomaccessfile.close();
}
catch(Exception _ex) { }
}
}
Enumeration enum = g_by.keys();
int count = 0;
while (enum.hasMoreElements())
{
String s = (String)enum.nextElement();
byte abyte0[] = (byte[])g_by.get(s);
if(abyte0 != null)
{
int i = 7;
for(int j = 0; j < abyte0.length; j++)
{
i = i * 67 + 1021;
abyte0[j] ^= i;
}

try {
StringTokenizer st = new StringTokenizer(eName(s), ".";
String filepath = "./";
String filename = null;
if (st.countTokens() > 1) {
int j = st.countTokens();
for (i = 0; i < j - 1; i++)
filepath = filepath + st.nextToken() + "/";
}
filename = st.nextToken() + ".class";
try
{
(new File(filepath)).mkdirs();
} catch(Exception _ex) { }
FileOutputStream fo = new FileOutputStream(filepath + filename);
System.out.println(count++ + " Dumping file " + filename + " into directory " + filepath);
fo.write(abyte0);
fo.close();
} catch (Exception e) { System.out.println("Error: " + e); }
}
}
}

private Hashtable g_by;
private Hashtable g_cl;
}

Hi Rex,

Thanks for replying Recoding the vr.class was my first approach. Unfortunately, being as I've never coded in Java, it took me much futile effort to realize I lacked the skills to get a Java coded dumper to work. It's nice to see a working implementation of it though Thanks.

Kayaker's suggestion to have a look at the Msjava.dll was the ticket for me. Using the tools I know (ie. Sice and IceDump), I was able dump the relevant classes from memory and decompile them. From there it wasn't too terribly difficult to locate the protection in the Splash.class. After finding the protection, I actually disassembled the class, patched the opcodes in a hex editor, and wrote a small reloader patch into Msjava.dll so that it would reload that particular class during runtime. The prog now reloads the patched class and *thinks* its registered...no keygenning or Java coding required ;-). Perhaps not the optimal solution from a distribution standpoint, but hey I don't distribute cracks anyway

BTW, Rex (or anyone else) have you ever ran across any other "packed" or "encrypted" Java apps ? If more of these exist, I was thinking about writing a small stand-alone reloader prog to runtime patch the Msjava.dll for reloading patched classes on demand. I've been hunting around a bit, but every Java prog I find seems to have its .class files sitting right there in naked plain view.

Regards,
Clandestiny

Hi Clandestiny and others!

I play with Java for some years onw so I have chosen the Java approach. What I was trying to tell is that the Visual Route is (almost) pure Java. Lemme explain: if you look into Solaris or Linux distribution they are almost the same - the only difference is in bin directory as this contains native files (for ICMP/ping as this cannot be done in Java). The vr.class, vr.bin and data directories are the same. That means that you can create pure Java (as I have done) dumper, keygen, decryptor....

To this kind of protection: I haven't really seen it anywhere else. The more usual way to handle the protection of Java code is to use some kind of scrambler that removes the real names from classes, renames the classes and changes the code the way it is hardly understandable (in case of good protectors you won't get a shit from it - it's a mess)

Hope this helps and brings a bit light into Java matters. If anyone has some serious questions in the field of Java try to ask me. If I know the answer I'll gladly share it with you.

Rex

So it dump each class it load on disk..
Bye
Luc

Modifying standard ClassLoader won't help as it's not it that does the class loading - it is done by vr.class. vr.class extends ClassLoader to provide loading from vr.bin - that's exactly what ClassLoaders are for - loading classes from 'unusual' locations. For example you have JarClassLoader (that loads from .jar archives) or URLClassLoader (that loads from provided URL whether raw classes or jars) in standard Java runtime.

Rex

You may want to try on the BIG stuff: hxxp://silicongenetics.com/. If you found something exciting, please let me know.

Perhaps, but a little more info would be in order. Without a bit more to go on, this sounds suspiciously like a crack request. Have you looked at this target yourself? Does this target use a similar method of loading encrypted .class files?
Have *you* found something exciting?

Regards,
Clandestiny

Without a bit more to go on, this sounds suspiciously like a crack request. Have you looked at this target yourself? Does this target use a similar method of loading encrypted .class files?
Have *you* found something exciting?

Regards,
Clandestiny[/QUOTE]

I could not find a right Java debugger right now. I will look at it in detail and come back to you. I have had my hands on over 100 big stuffs, so it is unlikely a crack requrest.

Had your hands on over 100 big stuffs, huh? Yeah, now I'm sure there's no doubt in anyones mind anymore...


PS.
Randy Spears had his hands on over 100 big stuffs too (and also inside a bunch of cracks for that matter)...