Reverse engineering Might and Magic III compression

I’m not quite sure how I ended up deep inside DOSBox debugger, going through 16bit assembly and recovering decompression routine used to handle MM3.CC file, but it was definitely fun. I got the game from one of the recent humble bundles and somehow (this is the part that I’m missing) I’ve found Jeff Ludwig’s page. I’ve read about his approach to modding Might and Magic III and problems related to compressed/encrypted MM3.CC data file. One of the phrases sounded like an invitation:

“It turns out that this algorithm has been a particularly tough nut to crack, and no one has come up with a viable way of decrypting the data.”

I recommend reading the whole story as his method of dealing with this problem is also great. In this post I’ll describe how I’ve handled it, in the end there will be link to the open source utility that can not only decompress, but also compress valid MM3.CC file.

Continue reading →

Resolving VMware Workstation 10.0.6 crash

Two days ago VMware published new update for Workstation version 10 (release notes). According to the changelog it should fix some security issues reported in OpenSSL. That’s nice, however there is a small problem with this update. VMware.exe (the GUI part of VMmare) started crashing immediately after update. This was quite a learning experience, do not update critical software if you have something important to do, as the new version can be worse than the one you are using. Since I didn’t have the previous installer at hand, I had to somehow resolve this issue differently (yeah sure, I just wanted to debug it and see, why it is crashing).

Continue reading →

wow64ext v1.0.0.4 – bugfix release

Bugfix release, there was a problem with GetModuleHandle64 in the previous version of the library (only v1.0.0.3 was affected). Basically I’ve failed at InLoadOrderModuleList iteration and I was skipping the last element, which is (usually) wow64cpu.dll.

Link to library hosted on google code: http://code.google.com/p/rewolf-wow64ext/
Direct link to zip package: http://rewolf-wow64ext.googlecode.com/files/rewolf.wow64ext.v1.0.0.4.zip

wow64ext finally compatible with Windows 8

I’ve some good news for everyone who was complaining that wow64ext library doesn’t work on Windows 8. I’ve researched this topic a bit, and I’ve released fixed version of the library. Problem was very simple, but it couldn’t be fixed with just one line of code. On Windows 8/8.1 x64 version of NTDLL is loaded at address above 4GB, it wasn’t the case on previous versions of Windows, as x64 NTDLL was always loaded below 4GB. Also some of the system structures are mapped above 4GB (PEB_LDR_DATA64). To fix all the issues I had to introduce new memcpy-like function that can copy data from addresses above 4GB to addresses that are accessible by the standard x86 code. I’ve also fixed problem with case-sensitive GetModuleHandle64 that popped up recently. Below you can find direct link to the updated library:

Link to library hosted on google code: http://code.google.com/p/rewolf-wow64ext/
Direct link to zip package: http://rewolf-wow64ext.googlecode.com/files/rewolf.wow64ext.v1.0.0.3.zip

Evolution of Process Environment Block (PEB)

Update 2016.09.14: This post is a bit outdated, if you are interested in some more recent research in this topic check out Terminus Project

Over one year ago I’ve published unified definition of PEB for x86 and x64 Windows (PEB32 and PEB64 in one definition). It was based on PEB taken from Windows 7 NTDLL symbols, but I was pretty confident that it should work on other versions of Windows as well. Recently someone left a comment under mentioned post: “Good, but its only for Windows 7”. It made me curious if it is really ‘only for Win7’. I was expecting that there might be some small differences between some field names, or maybe some new fields added at the end, but the overall structure should be the same. I’ve no other choice but to check it myself. Continue reading →

Solving |sas0|’s “The Game” crackme (.NET)

Another approach to crackmes solving, this time it is .NET crackme written by |sas0|. I’ve found it on crackmes.de, it was published on 27 November 2012, difficulty was set to 3 – Getting harder. I’ve decided to give it a try as I don’t have much experience with .NET targets. It took me 3 days to solve it, but I consider those three days as a good time investment, because I had a chance to learn a few new things. So, here is my story:

Continue reading →

Debugging ring 3 part of PE/PE+ loader

Someone may ask what is the purpose of debugging PE loader, here are a few reasons:

  • checking why executable is not loaded properly (imports, TLS, other initialization related issues)
  • looking for some hidden features (e.g. LdrpCheckNXCompatibility)
  • plain curiosity

Of course debugging ring 3 part of PE/PE+ loader can reveal only part of the truth, for the second part (or rather first part if I want to be strict) there is MiCreateImageFileMap function inside ntoskrnl (source code of this function can be found in Windows Research Kernel: \base\ntos\mm\creasect.c, it is a bit old, but most of the stuff hasn’t changed much). In this short article I’ll cover only x86 and x64 of ring 3 part.

Continue reading →

wow64ext library update 2

There is available new update for wow64ext library, I’ve added two new functions:

  • SetThreadContext64()
  • GetThreadContext64()

There is also definition of _CONTEXT64 structure that is used by those functions. Sample usage:

1
2
3
4
5
6
7
8
9
        _CONTEXT64 ctx = { 0 };
        ctx.ContextFlags = CONTEXT64_ALL;
        GetThreadContext64(GetCurrentThread(), &ctx);
 
        printf("rsp: %016I64X\n", ctx.Rsp);
        printf("rip: %016I64X\n", ctx.Rip);
        printf("r8 : %016I64X\n", ctx.R8);
        printf("r9 : %016I64X\n", ctx.R9);
        printf("r12: %016I64X\n", ctx.R12);

Link to library hosted on google code: http://code.google.com/p/rewolf-wow64ext/
Direct link to zip package: https://rewolf-wow64ext.googlecode.com/files/rewolf.wow64ext.v1.0.2.zip

__sse2_available

Today one of my colleagues noticed that his C++ project compiled by Visual Studio is using SSE instructions even with Enable Enhanced Instruction Set set to Not Set in Code Generation options of the compiler. That was strange enough to spend a few minutes and figure out what’s happening under the hood. It is well known fact tat CRT can use SSE2 to speed up some memory related functions like memcpy or memset, but I was always thinking that this optimization is only used when /arch:SSE or /arch:SSE2 compiler options are set. Continue reading →

wow64ext library update

I’ve updated wow64ext library, there are two new functions:

  • VirtualAllocEx64
  • VirtualFreeEx64

Those are equivalent of standard VirtualAllocEx and VirtualFreeEx, but works with 64-bits addresses. There is additional source code provided in \sample\main.cpp that shows how to use those new functions:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
printf("Alloc/Free test:\nRequesting 0x1000 bytes of memory at 0x70000020000 ...\n");
DWORD64 mem = VirtualAllocEx64(hProcess, 0x70000020000, 0x1000, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);
if (0 == mem)
{
	printf("VirtualAllocEx64 failed.\n");
	CloseHandle(hProcess);
	return 0;
}
printf("Memory allocated at: %016I64X\n", mem);
 
VirtualQueryEx64(hProcess, mem, &mbi64, sizeof(mbi64));
printf("Query memory: %016I64X %016I64X %08X %08X %08X\n", mbi64.BaseAddress, mbi64.RegionSize, mbi64.Protect, mbi64.Type, mbi64.State);
printf("Freeing memory: %s\n", VirtualFreeEx64(hProcess, mem, 0, MEM_RELEASE) ? "success" : "failure");
VirtualQueryEx64(hProcess, mem, &mbi64, sizeof(mbi64));
printf("Query memory: %016I64X %016I64X %08X %08X %08X\n", mbi64.BaseAddress, mbi64.RegionSize, mbi64.Protect, mbi64.Type, mbi64.State);

After successful execution it will show that both new functions works perfectly:

Alloc/Free test:
Requesting 0x1000 bytes of memory at 0x70000020000 ...
Memory allocated at: 0000070000020000
Query memory: 0000070000020000 0000000000001000 00000004 00020000 00001000
Freeing memory: success
Query memory: 0000070000020000 000000FEF5050000 00000001 00000000 00010000

green values are memory protection flags:

  • 00000004 – PAGE_READWRITE
  • 00000001 – PAGE_NOACCESS

yellow values represents state of memory pages:

  • 00001000 – MEM_COMMIT
  • 00010000 – MEM_FREE

Link to library hosted on google code: http://code.google.com/p/rewolf-wow64ext/
Direct link to zip package: http://rewolf-wow64ext.googlecode.com/files/rewolf.wow64ext.zip