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 →
Category / programming
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 →
rep movsb isn’t memcpy()
Some of you probably noticed that HexRays translates rep movsb opcode to memcpy() function from standard C library. In most cases this is perfectly correct behaviour, but there is at least one example when it will not work as it should.
Continue reading →
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:
http://code.google.com/p/rewolf-md5/
You can also download it as a separate zip archive:
Mixing x86 with x64 code
Few months ago I was doing some small research about possibility of running native x64 code in 32-bits processes under the WoW64 layer. I was also checking it the other way round: run native x86 code inside 64-bits processes. Both things are possible and as far as I googled some people used it already:
- http://vx.netlux.org/lib/vrg02.html
- http://www.corsix.org/content/dll-injection-and-wow64
- http://int0h.wordpress.com/2009/12/24/the-power-of-wow64/
- http://int0h.wordpress.com/2011/02/22/anti-anti-debugging-via-wow64/
Unfortunately I wasn’t aware of any of above results when I was doing my research, so I’ll just present my independent insights ;)
UPX “accidentally” increments LoadCount for DLLs
When I was preparing last dirtyJOE update I’ve noticed that under some circumstances python DLLs are not freed from memory. What was even more interesting, this behaviour was occurring only in ready to release version of application. I’ve tested few scenarios and I figured out that the problem lays in UPX loader.
I’ll try to explain what exactly happens.