dirtyJOE v1.7 (c529)

New version of dirtyJOE is available for download at http://dirty-joe.com. 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: http://blog.rewolf.pl/blog/?p=1097#comment-51893. 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 crackmes.de, 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 crackmes.de 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

Java bytecode debugging

Java bytecode debugging was bugging me for quite some time, however I’ve never done anything to really solve this problem once and for all. Around February I was desperately trying to solve some java bytecode riddle (yup, it was crackme ;p, but shhh…) and the only straightforward solution that would help with analysis was java bytecode debugger. If you query google for java bytecode debugger or java bytecode debugging, it will show two promising entries:
»Read More

dirtyJOE v1.6 (c472)

It is over two years since the last update of dirtyJOE. Actually this project was pretty much dead between 10.2011 and 03.2013 (17 months!) but I’ve managed to brace myself and put some new features together (finally!). Basically there is one new, big functionality called Restore Debug Info and bunch of small usability improvements. New version is available for download at http://dirty-joe.com, below you can find detailed changelog (with some screenshots): »Read More

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.

»Read More

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.

»Read More