Re: raw file system and registry data

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...

Comment on Re: raw file system and registry data

Replies are listed 'Best First'.
Re^2: raw file system and registry data by ketema (Scribe) on Dec 01, 2005 at 22:00 UTC
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]
Re^3: raw file system and registry data by psychotic (Beadle) on Dec 01, 2005 at 22:49 UTC
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]
Re^4: raw file system and registry data by ketema (Scribe) on Dec 02, 2005 at 14:35 UTC
I'll give the tool a try. But as far as different methods of detecting a RK, I of course have done remote analyzation and in general for a decently adept computer guy finding them is not the issue, even without great tools such as RR. The trick is how to make a tool like RR that allows even a noveice to know whether or not they are compromised, and of course have that tool be free & open, and in perl!, or I'd even settle for being wrapped by perl. But i think first I need to learn about things I have not done before like accessing the disk directly	[reply]