If you regularly download brand new programs from unknown developers then there’s an above-average chance you’ll find some malware. Antivirus software won’t necessarily pick up on the very latest threats, and so you’ll need further tools and strategies to identify potential dangers.
We recently wrote about "Easy Disk Drive Repair", and explained how we realised this promising-looking program was actually a trojan which turned off UAC and modified browser files. We used fairly simple and straightforward techniques, but if you want to get really technical, there’s a way to find out much more about how the program works.
We already know that "Easy Disk Drive Repair" is a Visual Basic 6 program (see PeStudio > "Imported Libraries"), and that’s not just some irrelevant technical detail. VB Decompiler is a commercial tool ($99+ with a free Lite version) which can open VB5/ VB6 executables and decompile them, recovering at least some of the source code from both native and P-Code applications.
Opening EasyDiskDriveRepair.exe in VB Decompiler displayed a tree showing the program structure, including forms, controls, modules and procedures. Some of these had their original names, too -- frmMain, Form_Load, cmdOK_Click -- which might immediately give you useful information.
We clicked frmMain’s Form_Load to find out more. As the source executable had been compiled to native code, the results can’t be as readable as they would have been originally, but some details are immediately clear. Here are four (non-consecutive) lines:
* var_4C = Global.App
* var_3C = Global.EXEName
* var_44 = var_5C & var_38 & &H454C58 & var_3C & “.exe” & Chr(34) & &H454C70 & var_24
* var_eax = call Proc_2_4_46B970(80000001h, "Software\Microsoft\Windows\CurrentVersion\Run", vbNullString)
When the program loads, it builds a text string representing its path and file name, then adds itself as one of your Windows startup programs.
That’s worth knowing, but it gets better when EasyDiskDriveRepair calls "Proc_2_0_4670D0". These two lines appear almost immediately.
* var_eax = call Proc_2_5_46BAC0(80000002h, "Software\Microsoft\Windows\CurrentVersion\Policies\System", Chr(69) & Chr(110) & Chr(97) & Chr(98) & Chr(108) & Chr(101) & Chr(76) & Chr(85) & Chr(65))
* Set var_58 = CreateObject("Scripting.FileSystemObject", 0)
The Registry key referenced here is used to tweak core system settings. The program is trying to obscure which one by representing the string as individual ASCII characters, so for example Chr(65) & Chr(66) & Chr(67) would become ABC, but once you see the code it’s easy to figure out. Chr(69) & Chr(110) & Chr(97)… ends up being "EnableLUA", the Registry UAC setting. On launch, EasyDiskDriveRepair always runs a Windows script to turn it off.
Glancing down the code shows lots of this kind of trickery:
* var_200 = var_84 & Chr(97) & Chr(109) & Chr(97) & Chr(122) & Chr(111) & Chr(110) & Chr(100) & Chr(111) & Chr(116) & Chr(99) & Chr(111)
* var_84 = var_200 & Chr(109) & Chr(46) & Chr(120) & Chr(109) & Chr(108)
Strings being obscured include "mozilla firefox\browser\searchplugins\amazondotcom.xml", "Mozilla\Firefoxsearch.json", and -- in many more steps -- "sqlite3.exe …update keywords set url = url || ‘&tag=chrome20-20′ where url like ‘%amazon%’ and url not like ‘%&tag=chrome20-20′". This program has plenty to hide.
What about Easy Disk Drive Repair’s supposed disk-fixing abilities? Does it actually do anything at all?
We headed off to picStart_Click, the starting point for any "checks". As an example, here are four consecutive lines of code.
* var_eax = call Proc_1_1_466590("Analysing SMART Data…", &H320, arg_8)
* :’Referenced from: 00460D61
* var_eax = call Proc_1_1_466590("Testing File System Integrity…", &HC8, arg_8)
* var_eax = call Proc_1_1_466590("Parsing ECC Records…", &HC8, var_F0)
The same procedure called for these very different functions? Yes, because it’s only carrying out the same few UI actions each time: displaying the status message provided ("Analysing" this, "Testing" that) and using the statement Sleep(arg_C) to pause execution for a defined period.
It’s a similar story as the routine progresses. There are pointless loops, the program fakes disk activity by opening and closing a "log", and uses more Sleep statements to make you think something significant is happening.
* var_E8 = "c:\windows\logs\" & CStr(var_0046E040)
* var_10C = var_E8 & ".dat"
It’s not clear how the program generates its “number of errors” and similar figures (there’s a "Randomize" statement early in the code, but no later references), but what we can say is nothing useful is going on here. EasyDiskDriveRepair is running lines like the following, but they only display the appropriate message on the interface -- absolutely nothing is happening on your drive.
* var_eax = call Proc_1_1_466590("Checksum re-calculated on " & CStr(call Proc_1_0_4664C0(2, 8, )) & " clusters", 0, )
* var_eax = call Proc_1_1_466590("Dynamically indexed " & CStr(call Proc_1_0_4664C0(2, 450, )) & " lost sectors", 0, )
* var_eax = call Proc_1_1_466590("Resyncing " & CStr(call Proc_1_0_4664C0(2, 512, )) & " bytes of ECC data", 0, )
There’s plenty more to explore here, but you’ve seen much of how this works. VB Decompiler can give you a great deal of information about a program’s functionality, without you ever having to run it -- particularly handy with malware. Its recovered code is fairly readable, too, even for difficult native code executables like EasyDiskDriveRepair.exe, and in many cases it’ll be significantly better.
If you’re not interested in the full commercial version, a VB Decompiler Lite option might appeal. You can open all the same programs, view project structure, properties, form/ control/ procedure names, string references, and more. You don’t get the "Decompile" view – there’s a Disassembler only -- but this expands some function and string references, and Windows/ PC experts may find it worth trying.