Hi George, Thanks for sharing this paper. I could not read the actual paper but found a cached version of the presentation. From my reading these guys simply broke some of the automatic functionality offered by the tools. Clearly if an investigator has no idea of what they are doing and want to just fire and forget the tool, this will stop them in their track but for people who actually know how to use the tool this is not really an obstacle. Certainly with volatility you can override many of these parameters (eg. --dtb --profile) and so this is kind of irrelevant. For example, the first step was to prevent the tool autodetecting the DTB by scanning for the idle process signature. The DTB should still be correct, but the scanner might get confused due to changing some of the header parameters. In reality scanning for any kernel process should be able to yield the DTB and even a statistical technique can be used by simply recovering all the DTBs of all the processes (the kernel DTB is found in more than one process, but a process DTB is pretty unique for each process). In addition, the volatility approach is to ask the user to specify the profile, since presumably the investigator already knows what OS they captured. The automatic guessing functionality in volatility is not really needed (it makes things easier) but ultimately it just offers a bunch of suggestions. (And currently it is actually implemented by recognizing the KDBG structure which is not actually critical to the running of the system so the rootkit can very easily change it). Of course the author could have done lots of antiforensic techniques, like change pool tags etc, and this has been known for a long time. In reading the presentation I didnt feel there was anything actually new here - perhaps we need better documentation, to help people to overcome these simple antiforensic efforts, but they have been known for ages and are not very effective. (I do not claim however that there are not other more effective anti forensic measures - which of course there are). Disappointingly the author did not add to any efforts with antiacquisition techniques, other than just talk about other efforts. For example, the shadow walking technique is easy to bypass simply by resetting CR3 (This flushes the TLBs essentially resyncing them). Despite this there is a lot of further work to be done in the antiacquisition space (For example its easy for a rootkit to exclude entire regions from acquisition tools by simply adding them to the DMA resource tree - which most acquisition tools avoid so as not to crash the system). Again thanks for sharing, Michael. On 30 April 2012 20:21, George M. Garner J.r (online) <ggarner_online(a)gmgsystemsinc.com> wrote: