Security Ripcord


Large Memory Acquisitions

Here is a question for those of you collecting memory from systems:

What do you do when you need to acquire memory from a 32-bit operating system that is running on hardware with more than 4 GB of physical memory?

Well, if your experiences are like my experiences then you crash the system.  Of course it makes sense and I should have thought of it before trying to acquire the memory.  It sure is tough looking sheepishly at a system administrator and saying “Sorry about that.”  This is why I recommend acquiring systems during off hours or scheduled maintenance windows.  This makes the sheepish “Sorry” a little less bitter.

I can imagine that the reason for this is that  memory tools such as Memoryze, Fast Dump, F-Response (in combination with FTK Imager from a remote system), and others are programs that are running on the operating system, the 32-bit operating system.  Although you would think that they would only be able to see what the operating system is able to access, their functionality provides them with direct access to the physical memory.  So, once the program gets to memory locations beyond what a 32-bit operating system can understand it does what all good operating systems do when they don’t understand: BSOD.

Recent experiences that I have had with acquiring physical memory that breaks the 4 GB boundary have not been successful at all.  Even on 64-bit operating systems I have achieved the grand BSOD.  Not sure why yet, or if this is just user error, but time and experimentation will tell.

Now, I’m not proud of crashing a customer’s system.  Especially multiple systems muliple times, but if we are going to get the information we need for an incident response then sometimes that is just going to happen.  However, with a little knowledge and forthought some of these system crashes can be avoided.

For now, I will just have to avoid these systems and ask that system administrators don’t buy systems with lots of memory if they are not going to run 64-bit operating systems (call your application vendors before considering this!!!).  If you do have a method for overcoming these issues, please leave a comment.  We would all like to know.

Go forth and do good things,

Don C. Weber



Help support my training and travel to security conferences. Get your SANS Training and GIAC Certifications through the Security Ripcord.

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

6 Responses to “Large Memory Acquisitions”

  1. its definately not user error
    the tools vendors’ compiler vendor is to blame.
    32 pointers are all you can expect

  2. I had the same problem with the current production version of FDpro.exe on systems with more than 4GB of RAM, but that seems to be fixed in FDpro.exe version 1.0.4.0096. Have you had a chance to try that version of FDpro yet?

    david@sharpebusinesssolutions.com

  3. @David,

    I am aware the HBGary is testing new versions of FDPro. Although I did experience this problem with FDPro I also experienced it when using F-Response and FTK Imager. I have not experienced this behavior with mdd, Memoryze, Nigilant32 but that is basically because I don’t think I have used them in these situations. Right now I have limited resources (meaning none) with extra memory to test.

    Basically what I am trying to say is that I cannot be sure if these are experiences that are limited to FDPro or rather memory acquisition in general. I think time will tell and I also believe that most developers of these tools are looking into this issue specifically. Hopefully soon we will have some updates and new features.

    Go forth and do good things,
    Don C. Weber

  4. Understood. FDpro 1.0.4.0096 works in situations that bugchecked 100% of the time for me with 1.0.4.0072. I thought this worked fine before. Maybe a Microsoft patch or hotfix broke something somewhere along the way?

  5. @David,

    Well, that is the battle isn’t it. MS gets to change what they want when they want it. We just get to keep up. Now it is just getting other people to understand these dynamics.

    Thank you for the information about testing.

    Don

  6. It would appear some progress has been made on this front. It looks like HBGary Responder can read and process RAM dumps > 4GB now. I am looking at a 8GB dump from a Windows Server 2003 system now. I will try the same on Responder Field Edition when I get a chance.

    david@sharpebusinesssolutions.com

Leave a Reply