I wanted to practice some Java and Python and what better way for me than writing some RE tools. I decided on my SecuROM protected executable. While I was at it I loaded up the executable in Olly and even x64dbg and to my surprise it no longer ran under a debugger. 

It took me a while to figure out that I had fiddled with Scyllahide's settings a few years back. I found out the reason it didn't work no more. A hook of NtUserFindWindowEx caused SecuROM to detect the debugger somehow, whether intentionally or it's a byproduct of something

So far, no clue but after I finish up my tooling I may find out what it is, could end up being a good anti-debug check.

Some insight about Process Virtual Machines.

So, I understood more about Process VMs, simply last night, I was all of a sudden aware out of the blue of how it works, roughly.

I also found a sample VM implementation, the one which is supposedly used in packers/protectors, albeit probably not as advanced, but still worth the read. Here's the link http://syprog.blogspot.com/2011/12/simple-virtual-machine.html

Anyway, I guess it's sort of a misconception that a VM executes anything, it does not, the VM instructions are simply "interpreted" i.e if  the instruction is MOV REG_DEST, REG_SRC, you are the one that must handle this operation.

I might write my own VM implementation, just to learn more.

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.