There are a few possibilities here, which i will mention. Firstly though, you must have a firm grasp of which APIs are being used and the methodology of data comparison in tools like RootkitRevealer. Since the particular tool doesn't come with source code, you should work towards finding the relevant API calls it makes. This requires some reverse engineering skills, but at the simplest case a debugger that lists API imports (like OllyDbg) will suffice. After you have that you should work towards understanding the proccess, the interweaving of different layers of access, which in my opinion is the harder of the tasks.
If you can achieve the above, you can look at the first option, for "low-level" disk access, the Win32API::File standard module. You most likelly won't find the level of complexity desired there, so your next bet might be Win32::API. I quote from the author's description page "Win32::API is a perl extension to import and call functions from any 32-bit DLL (Dynamic Link Library); its main use is to perform "quick and dirty" calls to non otherwise implemented Win32 APIs or third-party or even homegrown DLLs.".
If that doesn't do it, i suppose you could always resort to writing an XS extension, but then we are somewhat moving away from Perl code... | [reply] |
Thanks. This helps a lot. As far as the "figuring out what RR does" we are on the same page. I actually have Ollydbg and know its usefulness. Currently however I am stuck at finding a proper unpacker for RR. I have had some success with less complicated executables in using Olly to dump the unpacked image from memory, but this particular executable seems to resist my efforts so far. (Which I kind of ecpected from a tool written by the sysinternals guys)
I have also found this article out on the web but the script is not able to read live hive files, or other file structures. But it may be a start in the direction I want to go. Thanks again for the help. I'll keep looking...
| [reply] |
I should have figured it is packed. I presume you used the ollydmp plugin? I have some experience with unpacking, namelly Vbox-style packers that obfuscate the IAT. If this is the case here, perhaps you should look into a tool like ImpRec?
To actually get back on Perl, i believe basic RR copycat functionality is possible. At the very least, for finding files that aren't shown as a result of API hooking, you can use the "remote view" trick. It is all about accessing regular resources (files) remotelly, like from a shared disk.
The idea is to use a local Perl script that generates an internal treeish representation of the filesystem structure, even NTFS metadata (File::Find and Win32::File possibly). Then, run from another machine in the LAN (or experiment with Perl from within a VM, YMMV) the same set of code, only now reading the initial machine's maped-over drive. Compare the results, and voila, every file found in the second run has possibly been hidden from view by a rootkit. I say possibly because Windows by default hides certain files either way from local view.
I hope it makes some sense.
| [reply] |
Depends on your OS. On some flavour of *NIX you'd just open up the raw (or block) device file with open() (presuming suitable privileges to do so, of course). Someone else will have to speak as to the situation on Wintendo . . .
| [reply]
[d/l] |
Should have been a little more clear...This is pertaining to windows. End goal is to create a script that lists discrepancies between a normal API file system scan and a the raw data from disk. Much like what RootKitRevealer does from sysinternals, but unlike that program written in beloved perl and able to be automated.
| [reply] |
