Category / reverse engineering

by ReWolf

Reverse engineering Mortal Kombat GRA file format (part 2)

Disclaimer: This post is aimed at retro-gaming preservation and code-archeology. All product names, trademarks, and registered trademarks are the property of their respective owners.

933 days, this is the amount of time that passed since part 1 of that blog post. I had almost all work done back in 2018, I was just missing one small detail about the palette applied to the rendered frames. Then life happened and I pretty much abandoned not only this blog but all of my side projects. Around the beginning of February  2021, I felt a sudden urge to finish that project and I dug up all of my notes and source codes and started moving forward. The sources, obviously,  didn’t meet my quality bar after all these years, but I took the time to modernize them a bit, so it is less of a shame to make them public.

Before I start, I encourage old and new readers to take a look at part 1, as this post is a continuation and it may be easier to follow along being familiar with the prior research.

One more thing that is worth mentioning that I didn’t know in 2018 is that MK1 and MK2 executables have embedded Watcom compiler symbols. I learned about it just recently when I was looking for some recent development with regard to MK reverse engineering efforts:

I didn’t use the wcdctool as the list of steps to make it work is quite long and I have most of the executable described in IDA anyway. The most important learning I took from wcdctool is the existence of wdump utility (Open Watcom Executable Image Dump Utility) that can dump all available symbols. I used that tool to apply original functions/symbols names in IDA (on top of my own naming), so I may sometimes refer to those original names, provided they are better than the one I came up with.

Continue reading →

by ReWolf

Reverse engineering Mortal Kombat GRA file format (part 1)

Disclaimer: This post is aimed at retro-gaming preservation and code-archeology. All product names, trademarks and registered trademarks are property of their respective owners.

GRA files are used by the PC DOS version of Mortal Kombat 1 and 2 (available on GOG) to store all kinds of graphics. There are two different types of GRA files:

  • compressed static images or animations – this is a well-defined self-contained file format that can be easily converted to the PNG/APNG/GIF, the only obstacle is compression which has to be reverse-engineered first. I’ll refer to it as cGRA and cover that format today.
  • not compressed sprites/fonts/graphic objects/UI elements – this format is kind of a mess, it just contains encoded pixel data without any metadata. All necessary information has to be scavenged from the Mortal Kombat executable (sprites offsets, width, height, palette). I’ll refer to it as uGRA and cover that format in part 2 of this blog post (still have to figure out a few things).

Continue reading →

by ReWolf

PCAUSA Rawether for Windows local privilege escalation

Rawether for Windows is a framework that facilitates communication between an application and the NDIS miniport driver. It’s produced by a company named Printing Communications Assoc., Inc. (PCAUSA), which seems to be no longer operating. Company websites can be still reached through web.archive.org:

http://web.archive.org/web/20151017034756/http://www.pcausa.com/
http://web.archive.org/web/20151128171809/http://www.rawether.net/

Rawether framework provides NDIS Protocol Driver similar to the NPF.SYS (part of the WinPcap). This framework is used by many different hardware vendors in their WiFi and router control applications. Exploit attached to this advisory targets 64bit version of PcaSp60.sys driver which is part of ASUS PCE-AC56 WLAN Card Utilities.

Identifying other affected vendors is quite problematic, since Rawether is just a framework it is possible that the driver name, device name or driver version info were changed. Additionally, verifying if the particular software is really vulnerable is sometimes not feasible, because installation package won’t install without specific hardware.

Continue reading →

by ReWolf

Leaking EPROCESS address of the specific SYSTEM processes

Today I would like to briefly describe a simple method of obtaining the EPROCESS addresses of some specific system processes, which can be later used as a part of the Local Privilege Escalation exploit. This is an extension to the well known NtQuerySystemInformation (SystemExtendedHandleInformation) EPROCESSes leak. In the typical scenario SystemExtendedHandleInformation class can be used to map all processes of the currently logged in user to the correct EPROCESS address (plus a few more processes that allow OpenProcess with the SYNCHRONIZE flag, but I’ll get to this point later). Implementation of this approach is quite straightforward (some details omitted for the sake of readability):

Continue reading →

by ReWolf

MSI ntiolib.sys/winio.sys local privilege escalation

So, it seems that not only ASUS drivers allows unprivileged reading and writing to physical memory. Just a few months ago I was looking at the drivers that are loaded on my machine, and I found small MSI driver called NTIOLib_X64.sys. Out of curiosity I’ve looked at it in IDA and it turned out that it has almost the same functionality as the ASMMAP/ASMMAP64 ASUS drivers. I’ve tried to contact MSI through various different channels, but I haven’t really get past their customer support, so I’m not sure if anyone from the development team is aware of this design flaw. After almost 4 months I decided to publish my findings here.

Continue reading →

by ReWolf

IceCTF 2016 Slickserver/Slickerserver pwn writeup

It’s almost 6 months since the last post, so to keep some good yearly average it’s finally time to write something here. For the last couple of months, most of my spare time went into various CTF challenges. Since I’m very new to CTFs, usually I’m not able to solve top scoring tasks and people familiar with CTFs probably know that challenges with lower score are not really interesting enough to write anything more than a few lines writeup (and there is usually dozens of writeups already published, before I even think about writing something). So this time it might be a bit different since the IceCTF was 2 weeks long, and I could prepare some good writeup before competition ends. I did two pwn tasks, which are actually very similar to each other. First one was initially for 300 points, but the organizers figured out, that it’s easier than they thought, so they lowered score to 140pts and published improved version of the task for 300pts. Description for both tasks was pretty straight forward Continue reading →

by ReWolf

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: http://blog.rewolf.pl/blog/?p=856 and I’ve shared below screen-shot with an annotation that it will be published soon as a part of dirtyJOE:

java_debug

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.

Continue reading →

by ReWolf

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

Continue reading →

by ReWolf

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.

Continue reading →