« Posts under source code

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. »Read More

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:

»Read More

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.

»Read More

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

Solving gim913’s KeygenMe#01

Due to permanent lack of time and really long personal TODO list I’m not frequent crackme-solver, but sometimes it is good to check if my skills didn’t get rusty. I’ve browsed through unsolved crackmes on crackmes.de and found quite new gim913’s crackme that was unsolved for almost 2 months (yup, I know that it’s not much :) ). Knowing reputation of the author I’ve decided to give it a try, as probably there will be something interesting inside. So, let’s start.

»Read More

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

Reading memory of x64 process from x86 process

Some of you probably know that there is no easy way to read, write or enumerate memory regions of native x64 processes from x86 process that is running under WOW64 layer. Probably the only way it can be done is to use hack that I’ve described few months ago (Mixing x86 with x64 code). In that case there will be need to get address of x64 version of NtReadVirtualMemory / NtWriteVirtualMemory / NtQueryVirtualMemory and call it through X64Call(). Including all those hacky lines of code into even very small project doesn’t sound good even for me :) So I’ve decided to wrap it into glossy, shiny library called WOW64Ext.dll. »Read More

PEB32 and PEB64 in one definition

Recently I was writing small piece of code that uses both versions of PEB structure (x86 and x64). Being tired of having two separate definitions I decided to look into the Windows Research Kernel (WRK) sources and check how Microsoft is handling this structure. Original definition is in “pebteb.h” file and it is pretty smart, everything is defined through a series of macros and then included in a very “specific” way: »Read More