command line tool over GUI? and ADS question

Hi, if you dont have a copy I recommend you get a copy of Harlen Carveys book - Windows Forensic Analysis, very good.

You can test changes and system touches made yourself with tools such as Process Explorer from Microsoft/Sysinternals (http//technet.microsoft.com/en-us/sysinternals/bb896653.aspx), you will see that running a self-contained binary in a command shell will usually make less changes than a GUI. If you think about it, to load up images, buttons and the like and run it in the Windows GUI means many DLL's, reg keys are the like are touched, as well as the effect on RAM. A command line tool (depending on what it does of course) will usually have less integration with the OS and hence less changes are made.

If you have a tool that does the same job and one is command line and one is GUI, in a live situation I'd always go command line. Best to test in advance though. Also remember that malware, hacker activity etc can affect the results you get from using the systems own command shell.

All the best with your paper.

Nick
www.csitech.co.uk
nickfurneaux.blogspot.com

A very helpful reply Nickfx, thanks.

Does anybody know the answer to the NTFS to HFS question?

Cheers guys

Firstly i know, or at least think that the difference won't be massive, but say i was carrying out analysis on a live system, say analysis where an Alternate Data Stream had to be analyzed and i used a command line tool to view data in an ADS, would the changes that i am making to the system be less than if i used a GUI tool?

This is always something that is just full of speculation by folks; whether of not using a GUI tool over a CLI has a greater "impact" on a system, particularly RAM.

What most folks don't realize is that the components of the GUI are usually already loaded in RAM by the OS anyway. Most (albeit not all) graphical components find their roots in user32.dll, which is already loaded into memory when the system is booted, so nothing additional needs to be loaded when using most GUI-based tools.

The real impact comes in the actual size of the executable code loaded into memory and any processing required by the application. GUI tools may have more impact due to the fact that they offer greater ranges of functionality and would therefore consume more memory pages when initially loaded into memory.

I prefer CLI tools as they give me one small piece of functionality, and their output can be easily redirected to a file (and in most cases, if necessary, UNC paths are "understood"). My general methodology is to collect information and then analyze later, so finding a suspicious ADS would likely include my use of a tool to determine the size, then possibly the 'type' command to get a copy of it…if there were many more ADSs, or if the size of the ADS went over a certain threshold, I'd likely decide to wait and just image the drive/partition for analysis.

Oh and also, does anybody know if it is true or not that if i create an ADS on a Windows system formatted with NTFS and then copy that to another volume formatted with Macintosh HFS that the ADS will still exist?

ADSs are a construct designed to support HFS. A couple of things come into play here…whether HFS 'understands' what an ADS is, and whether the transport mechanism 'understands' ADSs.

Of course, there's always your own testing…

HTH,

h

Thanks for the further info keydet, not in a position to conduct my own experiments at the minute though, but will. Are the pros and cons of command and GUI tools mentioned in Windows forensic analyis?

yeah, but I gave you a freebie and they're listed in my previous post above…