LogStack

LogStack is a format string vulnerability discovered in WinMUGEN's log output system file (mugenw.log) by Japanese author Take in 2023. This exploit allows execution of shellcodes upon selecting a character, making this flaw part of the SuperNull exploit series, exploiting how character filenames are handled during logging.

However, this technique is currently impractical for general use due to major limitations: it's highly unstable, and to execute shellcode reliably, it requires sacrificing around ~1GB of disk space.

So far, there is only one known character that implements a "working" proof-of-concept of this exploit: a character named _kogasa, released by the same author. A second version of the exploit was released in 2024, significantly improving stability, but it could not be used by a character, since the files had to be directly put in the chars folder.

Note: This vulnerability has been patched in modern versions of MUGEN. (1.x)

Exploit Details

The vulnerability stems from improper handling of format specifiers in WinMUGEN’s log system. When the engine logs character information to mugenw.log, it improperly parses the path string of the character’s DEF path file as a format string; meaning that special sequences like %x, %e, or %n are not treated as literal characters, but interpreted as format specifiers in a printf-like manner!

This allows an attacker to manipulate memory, depending on how the format string is constructed.

For instance, if the character's DEF filename is named:

%x.def

the log output will interpret %x as a format specifier and attempt to read values from the stack, rather than writing %x.def as a literal string. With a carefully crafted name, this behavior can be escalated to shellcode execution. In the %x.def case, it will only print chars/<name of the character>/6973550a.def. 0x6973550A represents the first four bytes of the string \nUsing original loader on %s.

In his proof of concept, Take crafted a character with a DEF filename containing a long chain of format specifiers. These were used to force the logger to read memory in a specific way, eventually allowing execution to jump to his shellcode. But to reliably reach the shellcode's address, the exploit relies on around 1GB of padding data.