Ronan,
Yeah, I guess your post confused me slightly as I thought you were talking about running the actual OS instead of running Helix boot CD.
I was. That's because that was the context of the original question.
I think what some people may be failing to realize is that the Helix CD consists of a bootable Linux side, and a Windows live response side. I can see where the confusion comes from due to Fab4's original question…
"In mounting Helix and running dd therefrom say, can you be certain that it will not swap out memory on a Win system to pagefile.sys?"
So…is he referring to booting the system with the bootable Linux side (at which point you're not running Windows and there is no pagefile.sys), or are you still running the original Windows OS and using tools from Windows live response side of the Helix CD? In order to answer Fab4's question, there needs to be a distinction…I can see where folks are confused by the use of the term "mounting"…in normal usage of the term, Windows doesn't "mount" drives, while the term is quite commonly (and accurately) used in Linux environments.
So if Helix Boot CD writes to memory, are the contents of memory written to the pagefile on the suspects HD?
Okay, you've used the term "Boot", so I'm going to assume you're referring to booting the suspect Windows system to Linux using Helix…at which point, there is no pagefile.sys any longer, b/c you're not working in Windows.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management. Set DisablePagingExecutive value to 1.
Ah, quick lookup shows this
"NT will page some portions of its own kernel to disk, such as the NT executive system drivers to disk when they have not recently been in use, as NT makes room in memory for other processes. This can be helpful for a system with a limited RAM supply. If your server has ample RAM (for example, at least 64 MB more RAM than is normally used by all of the process working sets on the server plus the RAM normally used by the file system cache), then change the following registry entry HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Control \Session Manager\Memory Management\DisablePagingExecutive from the default value of 0 to 1. This change will force NT to keep the NT executive (kernel) from paging any of its executive system drivers to disk and insure that they are immediately available."
So, it doesn't stop Windows from swapping out to the pagefile all together…rather it only applies to kernel system drivers.
"It boots from the CD media, while not touching the contents of your harddisk."
I think the implication that some may be missing is that if "it boots", then you're talking about the Linux side…Helix does NOT have a bootable Windows partition…therefore a Windows/Linux distinction would not be needed.
…it is my current understanding that if the prevailing state of the system is such that *any* application would force swapping to occur, the same will occur if that app happens to be Helix. We all understand that the pagefile can bring further context to memory contents, so this is an implication that examiners must account for.
A couple of things come into play here…
First, from the Windows perspective, Helix isn't *just* "an application"…it's a bunch of apps. Aside from the GUI, there is very little of the Helix Windows Live Response section that is native to Helix, as Helix is a UI that allows you to run a whole bunch of other tools.
Second, apps do not necessarily *force* swapping to occur…it's a function of the operating system memory manager.
Third, it's not so much an implication as a fact…it's what happens, regardless. And yes, it *is* something that folks…not just examiners, but more importantly first responders…need to be aware of.
Harlan, many thanks for your response.
I accept that my original question and another subsequent quote has absolutely fuelled the confusion relating to boot (linux) and live response (windows) - so to be crystal clear, yes my interest is in windows live response matters.
Thanks also for defining the reg key and the memory management a little better - it can be noted that one of us is more useful with our words, which is why one of writes decent books and the other doesn't lol
That said, I think we agree that an app run for windows live response purposes from the Helix distro *can* (at the will of the MMU) modify non-volatile contents in the shape of the pagefile, which was the (albeit ill-formed) suggestion in my original question.
I use stars around *can* for two reasons;
1. Cause I think you enjoyed them wink
2. Because the swapping decisions made by the MMU cannot be differentiated into (i) directly caused by an app run from Helix or (ii) taken as a result of the normal operation of the host OS.
One could say that attempting to differentiate the *true* memory/pagefile footprint of a live response app, (i.e. those modifications directly attributable to it) from those host memory modifications which would have occurred in any event is meaningless anyway. Whilst we absolutely should understand the implications of all tools in our kit, from a live response perspective they are more difficult to define.
An example - we'll all know what reg keys are created/modified by our tools but if I take, say, 17 seconds longer to deploy my live response tool than you do, the host system that I am investigating is highly likely to suffer greater memory (and thus perhaps pagefile) modifications. The reality therefore is that the tool's footprint, as occurred in the process of deploying it, is different. It will be diferent each time I deploy it even.
Could it also be that your deployment of a live response tool may not modify the pagefile, whilst mine will? And vice versa, for a plethora of potential reasons….
So, how does a first responder properly plan for the footprint (memory and pagefile) he will leave during windows live response? Is there really any need to worry about the issue i've (badly??) articulated above? If there is a need to worry, can greater control be introduced somehow?
*Thanks* lol
Thanks also for defining the reg key and the memory management a little better - it can be noted that one of us is more useful with our words, which is why one of writes decent books and the other doesn't lol
Thanks, but it really has nothing to do at all with that. It's simply a matter of taking the time, which anyone can choose to do.
That said, I think we agree that an app run for windows live response purposes from the Helix distro *can* (at the will of the MMU) modify non-volatile contents in the shape of the pagefile, which was the (albeit ill-formed) suggestion in my original question.
Yes, definitely…but I would change "*can*" to "will". Remember, with regards to a live system, changes will occur (processes will complete, sockets will time out, etc) even w/ no interaction from anyone.
2. Because the swapping decisions made by the MMU cannot be differentiated into (i) directly caused by an app run from Helix or (ii) taken as a result of the normal operation of the host OS.
True.
One could say that attempting to differentiate the *true* memory/pagefile footprint of a live response app, (i.e. those modifications directly attributable to it) from those host memory modifications which would have occurred in any event is meaningless anyway. Whilst we absolutely should understand the implications of all tools in our kit, from a live response perspective they are more difficult to define.
Not so much "more difficult to define", but I do agree with the statement that in a way, it may be meaningless.
The reason for this is twofold…first, Heisenberg's Uncertainty Principle and Locard's Exchange Principle both apply…in attempting to measure how much memory is swapped out to the pagefile, the very fact of our measurement and observation is going to affect the outcome.
Second, any measurement you obtain on one system isn't going to apply to another system…different patch levels, different OS versions, different hardware configs, etc., will all affect your measurements.
To be clear, I am only referring to any attempt to measure the swap activity on a live system.
An example - we'll all know what reg keys are created/modified by our tools but if I take, say, 17 seconds longer to deploy my live response tool than you do, the host system that I am investigating is highly likely to suffer greater memory (and thus perhaps pagefile) modifications. The reality therefore is that the tool's footprint, as occurred in the process of deploying it, is different. It will be diferent each time I deploy it even.
Well, I would say that the tool's footprint would be very similar when deployed on similar versions and software loads of the OS and applications, and would not necessarily be dependent upon time, in that regard.
Could it also be that your deployment of a live response tool may not modify the pagefile, whilst mine will?
Given what we've already talked about, I seriously doubt that. If one live response tool is run and as a result of that action, the Memory Manager swaps data from memory to the pagefile, then why would similar activity not occur for another tool, given the same system?
I can already see that responses that will come from that question, but please…before anyone responds, remember, I said "given the same system".
So, how does a first responder properly plan for the footprint (memory and pagefile) he will leave during windows live response?
I think that this has been covered time and time again…you control what you can (choice of tools to use, etc.) and thoroughly document everything else. I think maybe the reason why the question keeps getting asked again and again is that most folks simply do not want to accept that they have to document anything, that there isn't always a technical solution that you can put behind a button in a GUI that you click.
Well, I would say that the tool's footprint would be very similar when deployed on similar versions and software loads of the OS and applications, and would not necessarily be dependent upon time, in that regard.
Really? I did a test recently where a fresh install of XP SP2 was installed to a VM and left it running without human interaction for 5 mins - 12.6MB worth of memory was modified. Why would similar not apply to an underlying host OS during live response?
Given what we've already talked about, I seriously doubt that. If one live response tool is run and as a result of that action, the Memory Manager swaps data from memory to the pagefile, then why would similar activity not occur for another tool, given the same system?
Of course you're correct when referring to a linear deployment of tools during a live response to a single system. I was considering that you were deploying a tool on one system and I was deploying the same tool on another system. I didn't make that clear. But's it's why I added "for a plethora of reasons…." to my comment - a different system being one of them.
Yes, definitely…but I would change "*can*" to "will". Remember, with regards to a live system, changes will occur (processes will complete, sockets will time out, etc) even w/ no interaction from anyone.
Is it not accurate to say "can"? Is it not a possibility that a system with 4GB of RAM may not require to undertake swapping to execute a particular app?
I think that this has been covered time and time again…you control what you can (choice of tools to use, etc.) and thoroughly document everything else. I think maybe the reason why the question keeps getting asked again and again is that most folks simply do not want to accept that they have to document anything
That's something slightly different. It's more akin to activity during the process of live response. Anyone who doesn't want to document should find something else to do. I was referring more to a first responder considering the impacts beforehand, i.e. is the evidence likely to be in memory and therefore possibly the pagefile. But I think you allude to it anyway - "control what you can". How and when the MMU invokes swapping is not within the control of a first responder.
Thanks, but it really has nothing to do at all with that. It's simply a matter of taking the time, which anyone can choose to do.
A tad caustic, I feel….but I find your overall comments useful.
Cheers H,
Yeah it was the distinction that confused me. Appreciate you taking time to clarify.
Ronan
Thanks, but it really has nothing to do at all with that. It's simply a matter of taking the time, which anyone can choose to do.
A tad caustic, I feel….but I find your overall comments useful.
These things really have to be read in context…I was responding to your statement
t can be noted that one of us is more useful with our words, which is why one of writes decent books and the other doesn't.
I'm sorry, but that just comes across like an excuse to me, that's all. Sorry if it's caustic, but to say something like this when all it takes is some time…after all, have you *seen* some of the book out there??? 😉
No offense intended, really.
No offense intended, really.
None taken, seriously. Apologies for delay in replying.
Anyhow, how's about getting back to the discussion. I was finding it a useful one.