Some months ago we wrote a blog post about physical memory limits in all Microsoft Windows 32 bit builds along with a test application able to install a bootkit in the system. This bootkit enables the operating system to exploit all available memory above 4 GB (up to 64 GB, using PAE technology). However the previous application was just a test release. We have received many e-mails about it, so we’ve decided to release an improved build of this bootkit.

Compared to the previous build, this major release brings new features like:

 

  • UEFI Compatibility: build up from scratch, similar code to the x64 Windows 8 Bootkit project. Windows 8 x86 installations in UEFI environment share the same memory limitations of old x86 Windows versions. Now X86 Memory bootkit is able to work even in a UEFI environment and bypass 4 GB memory limit
  • VBR Setup type: Due to incompatibilities between memory bootkit and custom/branded MBR code, we have switched to a brand-new setup routine. Now the bootkit is installed to the system Volume Boot Record code (only NTFS partition type), in a less-intrusive way. VBR setup can fix many incompatibility issues as it leaves the boot manager code separated from the bootkit code
  • Compatible bootkit: We developed a new bootkit startup code with the aim to resolve Windows activators incompatibilities and to introduce multi-os support. The new bootkit is now able to start on each Windows version of a multi-OS workstation without the request to be reinstalled on each OS
  • System analysis and reports: New feature that analyzes system drive’s  startup areas before installing the bootkit. If some part of the boot code is unknown/unexpected to the tool, the setup routine stops the installation and warns users about potential compatibility issues. User can decide to turn off  this warning. Setup application can furthermore generate full system reports. You can even decide to provide us with a log report so that we can get back to you with a feedback
  • Improvements and Bug fixes: A lot of bugs are resolved. Noteworthy is real mode segment issue, that will lead to incompatibilities and slowdowns on some particular notebooks. Fixed USB keys and removable devices removing procedure bug, fixed boot disk device lookup (done starting from BCD data).
  • New graphical interface: A new modern graphical interface was (re)designed with the aim to be more handy and easier for users.
Screenshot of new Saferbytes X86 memory bootkit

Screenshot of new Saferbytes X86 memory bootkit

 

PHYSICAL MEMORY – ONE BRIEF CONSIDERATION

Physical memory in Microsoft Windows is being managed in a different way than virtual memory. VMM unit is a huge module in Windows and to describe it in a exhaustive way an entire book would note be enough.

In each Windows installtion, the total amount of physical memory is detected by calling the kernel function MmInitSystem called with first argument (phase number) set to 0. MmInitSystem, called from phase 0, calls MmInitNucleus. As we have already seen in the previous article, this procedure contains is the “core” of the memory management initialization (and even license checks). MmInitSystem obtains hardware-related data (like total amount of physical memory), initializes base VMM data and paging structures, and then calls MiCreatePfnDatabase. The last procedure creates and maps Page Frame Number database, used by the system to track physical memory pages usage.

Here is what we would like to investigate in this article: indeed Windows uses PFNs to successfully manage all physical memory. A process working set is defined as a subset of the physical memory pages used by that specific process.It is the part of memory of a process that is resident in physical memory. There are several processes running together in a live system. So Windows has to manage several process working sets relying in different address spaces. Furthermore VMM has to manage even memory paging, mapped section object and other critical routines.

In this analysis we don’t want to spend too much effort on them (the book “What Makes It Page?: The Windows 7 (x64) Virtual Memory Manager” written by Enrico Martignetti is definitely one of the best books about the topic), however keep in mind that all these features (together with many others) need to have a database of physical pages. Each PFN is linked to a particular list of pages. Indeed each page in physical memory could belong to one of the following 5 lists (honestly there are also at least 2 others subtype lists: modified-no write and transition, though we are not interested about them right now):

  • Active – An active page maps a valid virtual address (kernel or user, where the latter belongs to a working set, and the former not necessarily) and one or more PTEs points to it.
  • Modified – A page that previously belonged to a Working set, but now is removed from it (due to working set trimming or aged page). The content of the page has not been saved to external storage, so the page can’t be reused until this happens.
  • Standby – A page that was previously in modified list, but now has been successfully written to disk (paging file) by Modified Page Writer thread. The page can be reused if VMM needs it. However, as long as the page is in this state, its content is still valid and the PTE still points to it (even if is invalid), like in the modified case. Standby list is prioritized by Superfetch, in last Windows releases (starting from Windows Vista)
  • Free – Page contains dirty data in it but can be reused because no PTE points to it. When VMM have to reuse a page on this list, it must fill with zeroes (due to C2 security rating).
  • Zeroed – Page is free for use, no PTE points to it and is also already initialized with zeroes

 

Process explorer showing system PFN Database

Process explorer showing system PFN Database

Each PFN entry in the database contains different data for each different page list. For instance a PFN relative to an active page differs from a PFN of a modified page. Windows Internals book describe each PFN type. You could examine each PFN entry with a kernel debugger (!pfn command). Here an interesting thing: PFN database is always present in physical memory, actually Windows can’t page this database out. Its size can change and depends on:

  • Target platform architecture (x86, x86 with PAE, AMD64), whole hardware physical address lines, and virtual address size (8 bytes on AMD64 and x86 with PAE)
  • Size of total installed physical memory (more memory means more PFN in dataset)

An original x86 PFN entry is 24 bytes in size, an x86-PAE PFN is 28 bytes (due to increased PTE size), and an AMD64 PFN is 48 bytes.

Our test system was equipped with 24 GB of DDR3 RAM. After some tests we can say that our x86 PAE operating system needs 168 Mbytes of continuous memory to correctly map and use entire physical memory, to maintains only physical memory structures, not considering paging structures (24 GB / 4 Kbytes page size = 6’291’456 pages * 28 bytes per PFN entry = 144 MB). A 64 bit Microsoft system will use 288 Mbytes (24 GB / 4 Kbytes page size = 6’291’456 pages * 48 bytes per PFN entry = 288 MB).

PFN analysis done in x86 non-PAE Windows XP

PFN analysis done in x86 non-PAE Windows XP

We now know that more memory needs more data structures used to keep track of it, and this depends either on architecture, memory size, and either on memory related OS data structures (PFN database is a software concept needed by the OS to correctly manage processes, threads, and paging). Thus we demonstrated that 32 bit PAE operation systems 4 GB limit is entirely a software limit, because showing an x86 PAE PTE, (linked also in PFNs, in OriginalPte field) pinpoints that PFN software field bits are much more than 20 (as confirmed by Intel manual “System programming Guide”, chapter 4.4)

VMM component in an operating system is a very interesting topic, way worth some further investigation if you want to deeply understand how your OS is able to map and manage physical memory.

 

BOOTKIT USAGE

Let’s go back to our Memory bootkit. Here we describe some hints, tips and tricks for installation, uninstallation and issues handling

INSTALLATION

Install x86 memory bootkit in a classical way (option 1 – MBR Setup) only if there isn’t any boot manager installed in your system (like Acronis OS Selector, Yamsisoft, GRUB, etc..). Otherwise just use VBR Setup type (option 2). If you would like to enable bootkit for more than one Microsoft x86 operating system click on “Bootkit options” in File menu and enable “ONLY compatible” Bootkit program type. In this way bootkit should work on every installed Microsoft OS.

The “Ignore system MBR type analysis” setting is used if the MBR installation procedure is unable to detect standard Microsoft MBR code sector and stops the installation with an error like “Unable to find Original Windows Mbr on “.PhysicalDriveX“. I will stop installation procedure..”. If this setting is flagged, bootkit will be installed and will use sector 0 as standard MBR code. Don’t enable this unless you really know what you are doing, because it can break the system boot up routine.

UNINSTALL
For memory bootkit removing, just run again the installation tool. At the tool startup, it detects the bootkit presence, and shows proper options to remove it from the system. The same is for USB pen drive: ignore the always-present option “Make a bootable floppy or pendrive” as the tool will anyway detect that the bootkit has been installed on the USB pendrive and it’ll remove the code from there.

If for any reason the system doesn’t boot anymore, users can remove Memory bootkit using Windows installation DVD. After booted from the Windows Installation DVD, open a command prompt and write the following commands:

bootrec  /fixmbr – in case of a classical MBR installations  OR
bootrec  /fixboot – in case of VBR installation (option 2 when installed the bootkit)

Then just restart the system. The bootkit should be definitely gone

REPORT

Whether something goes wrong and user wants to investigate, Setup application can generate a system report that dumps system information, loaded drivers, Master boot record sectors, System boot partition Volume boot record, and other details. User can generate this report with “Generate System Report” command found in Help menu. When the generation routine ends, user will be asked whether he would like to send report to Safebytes for further analysis.

DISCLAIMER

This software and its documentation are free and come “as is” with absolutely no guarantee and no support. The software is just for research purposes and it must be used only on testing environment. This software could potentially break your operating system by overwriting the Master Boot Record and/or the Volume Boot Sector, thus preventing it from actually running. Don’t use this software unless you know exactly what you are doing. If you accept this, download the tool from the following link: DOWNLOAD