> What did you think to the usb data recorder, if that could be modified to
> accept commands from an acquisition computer to read memory as is from
> the system?
My initial thoughts are that
(a) simply plugging the device into the system is going to modify the system; ie, on Windows systems, the PnP Manager loads the necessary drivers, etc.
(b) Once that's done, it's likely that an additional driver will need to be loaded.
Harlan
hmm, which brings us back to the original thing, of trying to prevent modifications, unless the device doesnt register itself with the bus, which in turn possibly prevents the whole thing working. I will have a think, and see if its possible to access the ram without the device registering, ie having any ID's or something similar to raw access, tho I am getting the sinking feeling that if it could be done it would have already been done unfortunately, but then again I like a challenge to see if I can figure it out. Ill go reading tomorrow and see what I can turn up, and email the author of the firewire device tomorrow morning.
DarkNeon
I see that this thread hasn't been updated in a while and think that the issue is important enough to continue. I commend Harlan for bringing it up here and in other forums. Likewise Farmerdude, whose instruction and advice on this issue have been inspiring. First, I take it that no one has seen a best practices guide to live acquisition, and developing one is likely more complex than what we have as the historical standard pull the plug, image the drive, etc. There hasn't been much discussion about this issue on the law enforcement (LE) lists, and I don’t believe the issue is being taught at the popular LE training programs. I do think, however, that most LE examiners are less apt to encounter a running system, making the point moot. There may come a day when that will change, by necessity, if Vista with bitlocker becomes prevalent, and we may have to go to extraordinary lengths to serve a warrant when we think the machine is running.
I tend to agree with the anonymous poster on Harlan's blog who said that the standard may have to change from "'cannot modify or disturb' to 'cannot materially modify or introduce new information,…'"[emphasis added] I recently did my first live acquisition in a case in which we believed the use of encryption tools was likely. The machine was found running and I drove 125 miles with my newest tool and 500GB USB drive in hand.
I chose X-Ways Capture (XWC), as I have quite a bit of respect for the author's tools and level of support. Every such tool is invasive, as are other steps we may take when we touch a running system. XWC dumps RAM as well as memory of all running processes. While running any tool will step on some memory, pulling the plug loses it all. XWC may then image physical devices and/or logically copy all objects if it detects certain encryption processes running or disk encryption.
In my case, BestCrypt (BC) was installed. Normally, XWC would then copy files from all logical volumes, to the extent that copying certain files is possible. By placing the mouse cursor over the little BC icon, which I recognized, I learned that no BC container was mounted and could abort logical copying. The point here is, if a container were mounted, I could have acquired its contents, a feat far less likely accomplished by trying to crack a BC passphrase. It’s a similar situation with EFS, barring access to rainbow tables to guarantee access to the files. Moreover, since I found no mounted BC container, I have the added advantage of finding potential passwords in memory.
While I have more testing to do, the footprint left on a running system will vary and be unique to a given system at a given time. My USB drive left a footprint. I opened My Computer to find my drive. (On another running machine, which also used BC, I logged on as a user who employed no password.) I made an entry in Prefetch and likely created and modified some registry keys. I don’t contemplate doing a live acquisition in every case in which it’s possible, but would consider it in most cases in which pulling the plug will render all or part of the stored data inaccessible. In the end, it’s a balancing act, and I believe that you have to consider whether you are confident that any evidence on the system will be as viable as it was before you did your live exam and that the object modifications or creations are explainable and really don’t affect what’s material to the case. At some point, a court will weigh a case and decide.
An interesting article in relation to the limitations of imaging physical memory (now and with Vista) together with a simple 'anti-forensics' method of preventing the live aquisition can be found
Quote
\Device\PhysicalMemory is a section object which enables us to access the physical memory from ordinary user mode applications in Windows. Fortunately, from a security viewpoint, the device can only be opened by members of the Administrators group. Unfortunately, from a forensics viewpoint, all user mode access to the device has been blocked in Windows XP 64-bit, Windows 2003 Server SP1, and Windows Vista. In the following discussions we will ignore that problem.
and
Blocking DD on Windows XP
To try my theories in practice I wrote a simple kernel driver with a call to MmAllocateContiguousMemorySpecifyCache, requesting a buffer of MmNonCached memory from the nonpaged pool. With the driver loaded i ran DD to dump the whole main memory. DD finished much too early (when hitting the buffer) and printed the warning "Attempt to access invalid address". You can think of it as a crude anti-forensics technique.
Whilst on the subject, something that is supposed to be for 'live response' is the unofficial Windows Online Forensics Tooklit (WOLF) from Microsoft. Esentially it will do a dump of phsyicaly memeory & a host of other dumsp of teh file system, security logs, etc.
Embedded within are tools such as DumpSec (previously DUMACL) and others - all outputing to several files - which in theory should then be sent to MS Premier Support for analysis after an intrusion/suspected instrusion.
Just a thought.
which in theory should then be sent to MS Premier Support for analysis after an intrusion/suspected instrusion
I feel uncomfortable sending anything to Microsoft !
I couldn't find any information about WOLF online, have you got a url or any further information regarding it?
Harlan et al., there's no getting away from doing Live Forensic Analysis but in doing so we should be seeking to minimise the chances to the system, I think the issues are-
1. Minimising the impact on the system under analysis from the tools deployed.
2. Documenting the changes on the system that is being analysed as a result of the analysis tools deployed.
3. Being able to explain the impact of the tools used to perform the analysis.
4. Validating the tools to be deployed appreciating the changes they may make to any system.
I've been unable to find any further information on using firewire for memory dumping, a link was available briefly on
I'm busy trying to catch up, I can see that some ppl have already started working on documenting much of this from using Helix for example.
> I couldn't find any information about WOLF online, have you got a url or
> any further information regarding it?
WOLF isn't publicly available, as the MS guys don't want rootkit authors getting access to their methodologies. If you're a premier support customer, you may get it.
> Harlan et al., there's no getting away from doing Live Forensic Analysis
> but in doing so we should be seeking to minimise the chances to the
> system, I think the issues are-
>
> 1. Minimising the impact on the system under analysis from the tools
> deployed.
> 2. Documenting the changes on the system that is being analysed as a
> result of the analysis tools deployed.
> 3. Being able to explain the impact of the tools used to perform the
> analysis.
> 4. Validating the tools to be deployed appreciating the changes they
> may make to any system.
I think that most of us involved in the discussion are pretty conversant with the issues. More appropriately, they are
1. Document the changes that your tools have on an exemplar system, so that they are better able to be understood. You should be able to explain the changes that are made to a system that you're examining…however, documenting the changes that you make to a live system can go against the edict of minimizing the impact on the system, as measuring the changes you've made will have additional effects on the system.
2. Document and follow your process. Clearly document and justify any changes you make to the process. Process is what gets hammered in court.
3. Of course, the process should minimize the impact your examination has on the affected system.
Harlan
Harlan, your points are right on, as usual. I think a good approach is to run a live acquisition with your tool of choice on a clean OS and see what happens. Of course, you can go back to a system after it's dead and find some of the changes, based simply on object date/time stamp data.
Echo6 raises a good question, concerning validation. It's easy to test whether your live tool accurately copied out a file. However, let's say that I copy out a file from a live, encrypted volume, and I can't crack the volume on the dead system. That makes it a little more difficult to prove that the file existed.
Memory, however, is dynamic and more difficult to validate. If I dump RAM now, and repeat the process in a few minutes, say with a different tool (which is loaded into memory), the results will be different. AFAIK, the issues have not been adjudicated. As you said, documenting and explaining are likely the keys to prevailing. Sure, I created a .pf file and a few registry keys/values, but I didn't change data in existing files. The other side may argue, however, that my .pf file overwrote exculpatory data that was in unallocated space. The field is wide open for devil's advocates. ?
> …let's say that I copy out a file from a live, encrypted volume…
Well, I see your point, but the issue of encrypted volumes raises other issues, such as live acquisitions. I'm not entirely sure which kind of encrypted volume you're referring to, but in most cases, the file of interested would be unencrypted if the system were still live.
> Memory, however, is dynamic and more difficult to validate.
It depends on what you mean by "validate". Is the _process_ that you're using generally accepted in the community?
> If I dump RAM now, and repeat the process in a few minutes, say with a
> different tool…
To be completely correct in that statement, you don't even need a different tool…the contents of RAM will change in a few minutes all by itself.
> AFAIK, the issues have not been adjudicated.
To my knowledge, they haven't, and I'm having some trouble understanding the paralysis I'm seeing in others…it hasn't been adjudicated so they don't do anything.
At one time, computer forensics wasn't used in court at all, because it wasn't understood. Then some folks did some hard work, and got it accepted…and now there are aspects of computer forensics that are generally accepted in court proceedings. Today, technology (larger storage capacity, drive encryption, etc.) is changing the face of computer forensics, and the age of "Nintendo" forensics is gone. More and more, the old methodology is becoming more of a hinderance. As responders, we have to adapt. If we all wait around for the acquisition of RAM as evidence to become commonplace in the courtroom, without doing anything, nothing will get done.
> …documenting and explaining are likely the keys …
And one (the analyist or responder) needs to understand, first. He or she is going to have to make that decision, and then justify it. However, the knowledge is out there and available…it's a matter of using it.
> he other side may argue, however, that my .pf file overwrote
> exculpatory data that was in unallocated space.
True, because that's their job. However, it's really not so much a matter of being a devil's advocate as much as it is a delaying tactic meant to confuse the jury.
Here's why. If you understands the structure of the Registry, you'll know that it's very unlikely that excuplatory data of any kind will be overwritten, even if in unallocated space, by the addition of a key. The same is true for a .pf file. Notice that I'm not saying that it isn't…I'm saying that it's very unlikely. I say this because if there is evidence that someone is guilty, that evidence usually occupies more than, say, 8 bytes, or even more than a single 4K page. The entirety of evidence against someone is not going to rest solely in an obscure 32 bytes in the middle of a sector in unallocated space. One has to look at the totality of the evidence.
But you do raise a good point…it's still incumbent upon the investigator to be knowledgeable in what they are doing, because ultimately what it all boils down to is, can you explain it to a jury? A purely technical wizard is completely useless if he is unable to explain his reasoning, methodology and findings to someone, including to a jury.
Remember, at one point in time, all sorts of what we consider "evidence" now wasn't accepted. Fingerprints, DNA, even current computer forensics…none of this was considered admissable. All I'm doing now is advocating against paralysis. Do something. Playing devil's advocate does nothing more at this point than act as an excuse for paralysis…because it's easier to do that than to do something to advance the concept.
Consider this a "call to arms". The age of "Nintendo" forensics is in it's twilight. Yes, we'll still use the techniques, but they will no longer be the totality of what we do.
Harlan
Thanks, Harlan, I appreciate the time you took to reply.
Well, I see your point, but the issue of encrypted volumes raises other issues, such as live acquisitions. I'm not entirely sure which kind of encrypted volume you're referring to, but in most cases, the file of interested would be unencrypted if the system were still live.
BestCrypt, for example. Those are exactly the types of situations that scream for qualified examiners to consider live acquisition. BC conveniently places a recognizable icon in the tray, and X-Ways Capture also looks for its process in memory. Although BC may close after a certain time elapses, pulling the plug certainly shuts it down
It depends on what you mean by "validate". Is the _process_ that you're using generally accepted in the community? . . . To be completely correct in that statement, you don't even need a different tool…the contents of RAM will change in a few minutes all by itself.
Good point. "Validate" our methods and also our tools. I was analogizing to validating dead system tools, which we often do by going after the same data with diferent tools. It's quite true that re-running the same tool will yield different results with RAM.
I'm unsure, however, if it would produce different reults if you capture memory associated with a specific process. Let's say MS Word is open and using 28.33MB of RAM. I capture Winword.exe's memory to a file, and do it again in five minutes. How likely is it, if at all, that the two captured files will be identical? I'll admit to needng a better understanding of memory and
paging. From your book, perhaps?
I couldn't agree more with the balance of your comments. Juror confusion is a tool of whatever side needs to use it for their client. The best strategy is to be prepared by, for exampe, explaining some of the points you raised about the registry and U/C. Thanks again!