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

Solving RedBeanSoup’s 1st Crackme (IronPython)

I’ve solved this little crackme quite some time ago, but I haven’t had time to publish the results. Besides this, protection wasn’t too hard, so I wasn’t sure if there is really anything to publish. Crackme was published on 14 January 2010 on crackmes.de, difficulty was set to 3 (Getting harder). Honestly speaking, without IronPython I would say that difficulty of this crackme is 1 (Very easy, for newbies, in the terms of crackmes.de scale), but with IronPython… well, it proved to be hard enough for me. Below analysis will shed some light on IronPython internals, there will be also part about .NET (as IronPython is just .NET Python), I’ll also cover the protection part, but it will not take too much space.

Continue reading →

WoW64 internals: Tale of GetSystemFileCacheSize

Few days ago someone asked me if I can somehow add GetSystemFileCacheSize to wow64ext library. I’ve researched this topic a bit and the final answer is no, because it is not necessary. In today post I’ll try to describe internals of GetSystemFileCacheSize function and its limitations, I’ll also show the different way of obtaining the same information as original GetSystemFileCacheSize.

Continue reading →

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

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.

Continue reading →

__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 →