mmap equivalent in Windows or How To Map Physical Memory to Userspace.

Windows unfortunately has no equivalent of mmap that can access physical memory e.g by mapping /dev/mem to some userspace address, however this can be achieved by a simple(not really) kernel-mode driver that I've personally used in Windows 7 x64, though there should be no reason why it wouldn't work in Windows 8/8.1/10

I found it in this article on CodeProject.

Now, even if you compile the driver, on x64 Windows systems the driver needs to be signed, this for development purposes can be disabled, follow the article on MSDN on how to do that.

But beware, fiddling with physical memory can lead to some very dangerous results if you aren't careful, e.g permanent hardware failure or data loss.

Disassembly of GPU-Z, I2C and GPUs

It's been a while since I've written anything, I wasn't going to but I did want to share some findings.

Now, I am not exactly versed in programming, I still struggle at the basics, linked lists let alone x86 assembly, but I delved into GPU-Z, a tool used to monitor vital sensors inside any modern graphics card. What sets it apart from other general purpose tools like AIDA64,HWMon,Open Hardware Monitor is that it specializes only in GPUs and is therefore very thorough, displaying information like VRM temperatures and currents. AIDA64 is the only one that also displays this data, but not all of the sensors.

When I first started disassembling GPU-Z with OllyDbg 2, I was greeted with a warning that it's likely packed, and indeed it was. As of version 0.7.5 the packer used is PECompact 2.x or 3.x, it's apparently easy to unpack a PECompact packed executable, but after trying it, I must have got it wrong somewhere and didn't get a multitude of functions imported correctly and after running the executable I got an error stating "floating point support not loaded". I gave up after a couple of more tries and used Nacho_dj's pecompact unpacker to unpack it, it worked.

How exactly does the Temperature component of GPU-Z work? It works by mapping physical memory to userspace and doing bit-banging on the I2C bus. Here is where it gets tricky, under Linux it's trivial to map physical memory to userspace(root and mmap roughly), but under Windows you need a driver, and not just any driver, but a kernel mode driver, and not just any kernel mode driver, a digitally signed driver to do this, usually only for x64 but may also apply to x86(32-bit Windows). Digital signatures cost a minimum of $100, may be cheaper somewhere but it costs money regardless. Lucky, it's possible to enable Test-mode in Windows and allow the running of unsigned drivers, but this makes your installation extremely vulnerable. But where do you get such a driver?

Luckily for you and me, an open source driver is available and it can be compiled to work with Windows 7 x64 as well. It's called PhyMem. I will not go into details how it works, because I myself have not yet figured that out.

Does GPU-Z use this driver? Probably not, GPU-Z predates this driver. It however uses it's own driver which is stored in the executable itself and is written in %temp% during runtime where it's executed from and removed.

Here is the GPU-Z(not source code) driver if you want it http://www.filedropper.com/gpu-z.

In part 2 I will try to explain what is being mapped, how much of it and explain more of what I found in GPU-Z.