Windows 10 TH2 (build 10586) – new fields in PEB

Recent Windows 10 update brought three new fields in the Process Environment Block structure:

x86 Field Type Field Name x64
offset size offset size
0x250 0x004 uintptr_t TppWorkerpListLock 0x388 0x008
0x254 0x008 struct _LIST_ENTRY TppWorkerpList 0x390 0x010
0x25C 0x200 void*[128] WaitOnAddressHashTable 0x3A0 0x400

It seems that all three of them are not so new to the Windows itself, because previously (starting with the Windows 8) they were residing in the NTDLL .data section:

Name in .data setcion Name in PEB
TppWorkerpListLock TppWorkerpListLock
TppWorkerpList TppWorkerpList
RtlpWaitOnAddressHashTable WaitOnAddressHashTable

Moving those fields to the PEB means, that they’re now easily accessible from the other modules. I wonder if that was the reason. If any of you have some other theories behind this (or maybe you just know?), please share them in the comments. Thanks.

wow64ext v1.0.0.7

New version of wow64ext library is available for download:


  • All 64bit APIs are now properly setting last Win32 error, thanks goes to Dreg ( who implemented this feature.

This is actually unexpected benefit from hosting wow64ext on github (google code is dead, long live github), so if some of you want to add something to this library do not hesitate to do pull requests. I can’t promise that I’ll accept everything, but at least you may try :) Here is the address:

Java VM Operand Stack Viewer

Recently I’ve got asked about this quite an old unpublished project that I actually forgot about and I decided to finally do something with it. I’ve mentioned it once in this post: and I’ve shared below screen-shot with an annotation that it will be published soon as a part of dirtyJOE:


One and a half year passed and I did nothing regarding this integration. Even more, at some point I came to the conclusion that this project does not fit for dirtyJOE as it’s rather Proof of Concept than a proper solution to the problem (no matter if the proper solution even exists). I’m still not sure if I don’t change my mind and eventually make it a part of the dirtyJOE, but I’m 100% sure that JVM Operand Stack Viewer deserves a release. An open source release with the full description of the method used to obtain JVM operand stack.

»Read More

WoW64 internals: Unexpected behaviour of NtQueryDirectoryObject

Some time ago I was writing a small class that was supposed to list items from windows objects directory (like WinObj from Sysinternals). Given the fact that there are a lot of examples out there on the internet, it seemed like an easy task. I’ve started coding it without reading any documentation, except required functions definitions:

NTSTATUS WINAPI NtOpenDirectoryObject(
  _Out_ PHANDLE            DirectoryHandle,
  _In_  ACCESS_MASK        DesiredAccess,
  _In_  POBJECT_ATTRIBUTES ObjectAttributes
NTSTATUS WINAPI NtQueryDirectoryObject(
  _In_      HANDLE  DirectoryHandle,
  _Out_opt_ PVOID   Buffer,
  _In_      ULONG   Length,
  _In_      BOOLEAN ReturnSingleEntry,
  _In_      BOOLEAN RestartScan,
  _Inout_   PULONG  Context,
  _Out_opt_ PULONG  ReturnLength

»Read More

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.

»Read More

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).

»Read More

dirtyJOE v1.7 (c529)

New version of dirtyJOE is available for download at The main new feature is Java 8 class files support, as there were some minor changes to the file format that were breaking dirtyJOE. You can find full changelog below:

  • Java 8 support:
    • Added support for new constant pool types:
      • CONSTANT_MethodHandle
      • CONSTANT_MethodType
      • CONSTANT_InvokeDynamic
    • Added viewer for BootstrapMethod attribute
    • Added support for invokedynamic opcode
  • Added viewer for StackMap attribute
  • Added Copy and Copy all to the exception table list in Code Editor
  • Added /opcodes command line switch to start Opcodes Help only
  • Added demangling of Signature attribute
  • Opcodes Help window can now be stuck to the main application window or to Code Editor window
  • Added some more keyboard shortcuts

PS: It seems that dirtyJOE became a thing on Brazilian Minecraft modding scene (in the last few months over 50% of downloads were from Brazil). Greetings to You guys, if You have any special Minecraft related feature requests just send me a message and I’ll see what can I do for You :)

wow64ext v1.0.0.6

New version of wow64ext library is available for download:


  • Bugfix for improperly aligned stack. It was aligned to 8, and it was failing when some x64 SSE code was executed as it needs 0x10 alignment. Thanks goes to Vlad, who pointed it out in some recent comment under previous release: This bug was present since the first version of the library, thankfully now it’s gone.

wow64ext v1.0.0.5

New version of wow64ext library is available for download:


  • Added VirtualProtectEx64
  • Bugfix for ReadProcessMemory64 / WriteProcessMemory64 lpNumberOfBytesRead / lpNumberOfBytesWritten is declared as SIZE_T pointer. SIZE_T on x64 platforms is 64bit value, but wow64ext library is 32bit, so SIZE_T will be 32bit. Passing this pointer directly to the x64 version of NtReadVirtualMemory / NtWriteVirtualMemory would lead to a buffer overflow. To keep backward compatibility, I’ve introduced intermediate DWORD64 value that is used internally by ReadProcessMemory64 / WriteProcessMemory64, result is cropped to 32bit value, but it shouldn’t be a problem most cases.
    Link to described fix:

Solving warsaw’s Java Crackme 3

Every once in a while I’m posting solution to some crackme that I consider interesting. By interesting, I mean the solution, so it is not exactly about key generation algorithm but also about technology and tricks that are utilized. Looking at the traffic statistics, it seems that this topic isn’t exactly the one that people would like to read (three posts – 5,63% of total unique page views), but I’m truly convinced that it has great potential for every single person that wants to learn something new. All in all, there is at least one person that benefits from those tutorials – ME :) Back to the topic, in this post I’ll describe warsaw’s Java Crackme 3. Crackme was published on 14th October 2012 on, I’ve picked it up around February 2013, so literally speaking, it took me one year to solve it (of course I had some huge breaks meanwhile). Difficulty of the crackme was set to 5 (Professional problem to solve) in the scale and I must fully agree with it. It is Java crackme, but it wasn’t written in Java, I’m 99% sure that it was written in Jasmin or other assembler for Java Virtual Machine (JVM). Hand-crafted assembler and bunch of obfuscation tricks renders all existing decompilers pretty much useless, so it will not be yet another simple Java analysis.

»Read More