Kai Witte’s Blog

I recently came across a trojan, which is detected by common virus scanners, but not much documented. So I analysed it just a little.

Like many others it is located in the Windows directory (for example c:\winnt) and named svchost.exe (the real svchost.exe belongs to system32). It is set up to start with Windows.

These are its names according to jotti.org:

A-Squared  	
Found Win32.SuspectCrc!IK
AntiVir 	
Found TR/Downloader.Gen
ArcaVir 	
Found Trojan.Agent.Wo
Avast 	
Found Win32:Trojan-gen {Other}
AVG Antivirus 	
Found BackDoor.Agent.MEA
BitDefender 	
Found Backdoor.Agent.WO
ClamAV 	
Found Trojan.Agent-8319
CPsecure 	
Found nothing
Dr.Web 	
Found BackDoor.IRC.Spreader
F-Prot Antivirus 	
Found W32/IRCBot-based!Maximus (probable variant)
F-Secure Anti-Virus 	
Found Backdoor.Win32.Agent.wo
G DATA 	
Found Win32:Trojan-gen
Ikarus 	
Found Win32.SuspectCrc
Kaspersky Anti-Virus 	
Found Backdoor.Win32.Agent.wo
NOD32 	
Found probably unknown NewHeur_PE (probable variant)
Norman Virus Control 	
Found W32/Agent.CWBV
Panda Antivirus 	
Found Trj/Downloader.MDW
Sophos Antivirus 	
Found Mal/Generic-A
VirusBuster 	
Found nothing
VBA32 	
Found Backdoor.Win32.Agent.wo

The size is 86.016 bytes, MD5: 5ec89f1f189fc5af94aa9306d7df4b8b

What it does is this: It tries to connect to IRC.BENDOVER.BE (that server is no longer operational), then joins #spreader.crew (password: spreadmaster). In my case it used the name!id: oppqrrstc!oppqrrstc (probably generated individually). Then it stayed in the channel and did nothing more. It probably waited for a bot or real person to contact it with further instructions.

Any hints about this trojan or the creators (former owner of bendover.be? "spreader.crew"?) are appreciated.

In Heroes of Might and Magic IV (aka Heroes of Might and Magic 4, HOMM 4, HOMM IV) this error occurs when the name of the executable used to launch the program differs:

multiplayer_msg_general_failure

The content of the executable does not matter, it is the name. So both must use for example h4tour351.exe, even though in Equilibris 3.51 it has the same content as h4mod.exe.

How to fix UnsatisfiedLinkError in JNI

I have never had problems with JNI. In the few situations when I needed it, it just worked. But last week someone asked me for help with his problem. When I tried to reproduce it, I found out that it had spread even to my old JNI programs which worked until 2006!

When running a program that uses a native function the following error occured:

Exception in thread "main" java.lang.UnsatisfiedLinkError: Test.dll: Can't find dependent libraries

It’s obviously a linker problem related to the generation of the .dll file. I have no idea why it occurs now and didn’t occur in the past. Different OS, compiler version, something like that? For some reason both the linker of Visual Studio and the linker of GCC started to think that is was a good idea to replace all method names by some arbitrary name which then cannot be found at runtime.

Fix for GCC

To fix that with GCC, the linker opion --add-stdcall-alias can be used.

gcc -Wl,--add-stdcall-alias -mno-cygwin -shared -I/cygdrive/c/Program\ Files/Java/jdk1.6.0_05/include -I/cygdrive/c/Program\ Files/Java/jdk1.6.0_05/include/win32 -o HelloWorld.dll HelloWorld.c

Fix for Visual C

For Microsoft Visual C Compiler it should theoretically be possible with a linker option as well.

Find out the correct linker option

First compile and link in the usual way that didn’t work. This will create the .dll file which results in the error we are talking about. Then use the dumpbin tool to list the procedure names:

dumpbin HelloWorld.dll /EXPORTS

You will find your procedure name, something like _Java_HelloWorld_print@8. Now try to guess what the name should be. My guess in this case would be Java_HelloWorld_print. This would result in the linker option /EXPORT:Java_HelloWorld_print=_Java_HelloWorld_print@8

Supply the linker option

1. Use a #pragma comment in the source file:

   #pragma comment(linker, "/EXPORT:Java_HelloWorld_print=_Java_HelloWorld_print@8")

   OR

2. Split into linking and compiling and provide the option to the linker in the command line, OR
3. Supply it to the compiler at the end using /link:

   cl -I"C:\Program Files\Java\jdk1.6.0_05\include" -I"c:\Program Files\java\jdk1.6.0_05\include\win32" -MD -LD HelloWorld.c -FeHelloWorld.dll /link /EXPORT:Java_HelloWorld_print=_Java_HelloWorld_print@8

Option 3 is probably the easiest. After that dumpbin will show that now there is an additional procedure with the correct name:

dumpbin HelloWorld.dll /EXPORTS

I even compared it with the working .dll I created with GCC (see above), and it looks the same! But it doesn’t work, still getting the same error!

50 USD through PayPal for a solution and an explanation why the current way doesn’t work even though the procedure name is the same as in the working .dll created with GCC. (Only the first solution gets the price; only valid as long as this text is here.)