Effects of Live Acq...
 
Notifications
Clear all

Effects of Live Acquisition Tools

13 Posts
5 Users
0 Reactions
789 Views
(@splak)
New Member
Joined: 16 years ago
Posts: 4
Topic starter  

Hi

I am 3rd Year undergraduate student investigating the effects of automated tools (GUIs) against combination of command line based tools (CLIs) in order to identify the tool that has the least effect of the resources on a compromised Windows machine being investigated.

I would appreciate it, if you could take the time to complete a short QUESTIONNAIRE (3minutes) to understand the types of tools used.

You can drop me a message with suggestions or your reasons for utilising particular tools in the questionnaire.


   
Quote
 96hz
(@96hz)
Estimable Member
Joined: 17 years ago
Posts: 143
 

Hi

I answered your questionnaire,

Do you understand the impact of utilising command line based tools on a compromised system? *

I only ctrl-c'ed that but there was also a question about cmd.exe

Its important to point out that when dealing with a compromised server most, if not all folks will be using there own trusted binaries if possible. You are probably aware of that, I was just expecting a question about it and it did nt come.

I'll be interested to see what you come up with, my understanding was, if you load a GUI based app to grab RAM you've just overwritten a large chunk of it.


   
ReplyQuote
keydet89
(@keydet89)
Famed Member
Joined: 21 years ago
Posts: 3568
 

I'll be interested to see what you come up with, my understanding was, if you load a GUI based app to grab RAM you've just overwritten a large chunk of it.

Really? How so?


   
ReplyQuote
 96hz
(@96hz)
Estimable Member
Joined: 17 years ago
Posts: 143
 

I assumed the graphic components that need to be rendered are first loaded into RAM, potentially pushing out other data to pagefile. I think 'large chunk' is an exaggeration but I was always under the impression that the footprint was considerably bigger. Mis-understood/guided ?


   
ReplyQuote
(@douglasbrush)
Prominent Member
Joined: 16 years ago
Posts: 812
 

I'll be interested to see what you come up with, my understanding was, if you load a GUI based app to grab RAM you've just overwritten a large chunk of it.

Really? How so?

Not sure if I understand that statement as well.

MS reference of the paging areas of RAM
http//support.microsoft.com/kb/555223


   
ReplyQuote
Wardy
(@wardy)
Estimable Member
Joined: 20 years ago
Posts: 149
 

Your question is to be honest a little too general.

It is possible to write a GUI app which actually has a very small footprint.

If assembly were used, it may be possible to create a GUI based memory imaging tool with an exceptionally small footprint…

I'd strongly suggest you read the link provided by Douglas and maybe revise your questionnaire - a few word changes could make it much more relevant.


   
ReplyQuote
keydet89
(@keydet89)
Famed Member
Joined: 21 years ago
Posts: 3568
 

I assumed the graphic components that need to be rendered are first loaded into RAM, potentially pushing out other data to pagefile. I think 'large chunk' is an exaggeration but I was always under the impression that the footprint was considerably bigger. Mis-understood/guided ?

Graphic "components" are maintained in DLLs like user32.dll, and many of these are already loaded into memory.

As to how much memory is consumed by a GUI vs CLI application, I haven't seen anything that specifically addresses this.


   
ReplyQuote
(@douglasbrush)
Prominent Member
Joined: 16 years ago
Posts: 812
 

I think there is a generally misunderstanding that a GUI application will occupy more RAM. The GUI is a function of an executable interacting/interfacing with parts of the OS and/or shell that display certain functions. An executable is an executable and the amount of RAM in uses in memory is due in large part to the coding and compiling of the program.

Command line instructions "generally" execute a process, load in to RAM, do their business and close - thus clearing out of memory. GUI based executions can stay open in the shell or OS occupying RAM areas and/or pagefile space indefinitely until closed by user or other application instruction/interaction. If you are still running Win 95 this might not apply because MS had a "feature" that would not clear RAM areas efficiently after a program closed. I digress…

The analogy off the top of my head would be a door to your house. You can have it close automatically after you open it with a hydraulic arm door close thing (the technical term) or just stay open. Which is better? Well what are you trying to do - what is the user's need? If I was trying to save on energy costs and had kids that stink at closing the door after they enter then this might be helpful to me. But if I was trying to take car full of groceries into the house with multiple trips and with each load had to stop my actions, put everything down and open the door then it would most likely not be the best application.

Define the need. Develop a process. Then pick the tools.


   
ReplyQuote
 96hz
(@96hz)
Estimable Member
Joined: 17 years ago
Posts: 143
 

As to how much memory is consumed by a GUI vs CLI application, I haven't seen anything that specifically addresses this.

Im not sure I have, I feel like it is something I was just told and in my mind it made sense, so did nt think to question it.

I think there is a generally misunderstanding that a GUI application will occupy more RAM.

Agreed.

Harlan, Douglas, thanks for putting me straight (started me thinking) I will have to have a look into this at some point now.


   
ReplyQuote
(@splak)
New Member
Joined: 16 years ago
Posts: 4
Topic starter  

I'd strongly suggest you read the link provided by Douglas and maybe revise your questionnaire - a few word changes could make it much more relevant.

Thank you for your input, I will rephrase the questionnaire. The project aims to identify the resources used up by certain processes while conduicting a remote acquisition of a complete image of a windows server (2003).

MS reference of the paging areas of RAM
http//support.microsoft.com/kb/555223

Thnaks for the link.

Can anyone recomend any tools or methods that could be used to measure the prcoesses, i.e something better then task manager, procexp or procmon, etc…


   
ReplyQuote
Page 1 / 2
Share: