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:

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");
	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. Continue reading →

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: Continue reading →

Random thoughts about embedding python into your application

In this post I want to share some of my thoughts about embedding python into C/C++ applications. It will not be yet another python tutorial, but just my personal feelings about some of the mechanisms that I’ve encountered during my work on dirtyJOE. I’ll describe three completely different things:

  • Usage of FILE* structure by Python runtime
  • Small differences between different Python versions
  • Reference counting

Above three topics are just small part of the whole python embedding topic, but they attracted me enough to write about it. So let’s start. Continue reading →

Windows SuperFetch file format – partial specification

According to ForensicWiki (http://www.forensicswiki.org/wiki/SuperFetch):

SuperFetch is a performance enhancement introduced in Microsoft Windows Vista to reduce the time necessary to launch applications (…)
Data for SuperFetch is gathered by the %SystemRoot%\System32\Sysmain.dll, part of the Service Host process, %SystemRoot%\System32\Svchost.exe, and stored in a series of files in the %SystemRoot%\Prefetch directory. These files appear to start with the prefix Ag and have a .db extension. The format of these files is not known…

When I read above statement I just couldn’t resist and I’ve decided to take up a challenge. Below you can read what I’ve found, as a bonus I’ve also prepared simple dumper for SuperFetch .db files (attached at the end of this post).
Continue reading →

dirtyJOE v1.5 (c359) and some statistics

New version of dirtyJOE is available for download at http://dirty-joe.com

What’s new:

  • Opcodes Help – embedded detailed description of all Java bytecode instructions.
  • Active Help – short description of opcode directly in Code Editor window, updated automatically on opcode selection.
  • Improved Python scripting – added decrypter for Allatori obfuscator and added possibility to re-encrypt previously decrypted strings.
  • Active Search – search feature on Constant Pool tab

Continue reading →

dirtyJOE v1.4 (c334)

Small update for dirtyJOE, it addresses a problem related to font changing, it appears only on Widnows XP systems. New version is available for download from official www http://dirty-joe.com. You can also download it directly from this post:

MD5 implementation for GNU Assembler

Probably some of you may remember that over 6 years ago I’ve created MD5 implementation for MASM (there was also separate file for FASM adapted by Reverend). Few days ago I’ve received e-mail from Hannes Beinert, he found my old code and he adapted it for GNU Assembler. Moreover he also wrote comments for almost every line of algorithm, so it can be now used for some educational purposes. I’ve decided to put it all together online on code.google.com, so everyone can benefit from it:


You can also download it as a separate zip archive: