Posts

Newest Post: VoidShell Library: Destiny Notes

Good afternoon, readers. Oh yeah, this is going to be the first blog entry of 2026, so let us begin by talking about the VoidShell library's future. As many of you can guess, this library initially started as an ASM x86 program inside a ST file, which was loaded by the engine through a SuperNull exploit (The StateDef Overflow engine vulnerability was used as main vector back then), and despite you could expect, it was simpler than the current version. "Eikidankai" was the first name given to said library and early build versions were used on a few known characters (such as x00x00x or Void.Schmelze) to withstand most SuperNull enemies from the past decade. However, there was no real defense behind it, as it just seals most of the engine vulnerabilities while hooking some primary functions, causing their exploits to be effectively blocked but also rendering them unstable. They were eventually left as PoC characters while the Eikidankai program had to be reworked from scrat...
0

WinMUGEN Exploits: Command Trigger Buffer Overflow

Good evening, my friends. Well, today we are going to talk about a new exploit, found in WinMUGEN. Information provided by ydccdy, a Chinese MUGEN author, has revealed the existence of an exploit found in the CMD processor,  the command expressions to be exact. , whose main function is to trigger determined actions from the commands written in StateDef -1. After having taken a look at the exploit, I have noticed the command name length is fixed to 64 bytes, giving the chance to execute arbitrary code from a CMD expression by surpassing this length, basically a buffer overflow. What M.U.G.E.N authors put in their state controllers to make use of the commands, either it can be used to execute arbitrary code, for example, these 2 pictures: Command = "Insert all your shellcode here, it is less versatile, but well. 1234" Note: The 1234 characters are used as a return address for the exploit. I have made this character after spending a few hours to pr...
0

Eikidankai Development Log(3)

Eikidankai Development Log: Primary memory bank Hmmm... I think I am posting more content about Eikidankai than usual, but well. In this thread, we are going to talk about the primary memory bank, used in the current version of Eikidankai. We have to take into account this feature did not even exist in the first beta versions of Eikidankai, as the main code was quite different, compared to the current one, making each other incompatible. This image shows how the old stack frame of Eikidankai looked like, the function set was quite limited, due to the most of the slots had been reserved for the CF subroutine. The next image shows the stack frame was updated to separate the functions of the CFL subroutine from the loader, making it optimal for several circumstances, besides the fact Eikidankai can now make use of all the slots, greatly extending its function set  Although this implementation required a new code structure to work efficiently, the results wer...
0

Eikidankai Development Log(2)

Eikidankai Development Log: CFL Subroutine Huh, it has been a long while since I do not post anything, but well... This time we are going to talk about the CFL subroutine, and the file as well. This subroutine had been recoded to improve its performance in Eikidankai, which used to be antiquated, due to the lack of security checks. Additionally, this file contained all the primary functions of Eikidankai, making the main loader quite basic. Fixed in the new beta version, by putting all the functions into the loader, instead of the CFL file. First version of the CFL loader. After Eikidankai has loaded all the required stuff in the stack frame, it will look for a file, called as "Eikidankai.Cfl" to load it in memory, this file contains custom code, allowing a MUGEN author to implement its own content, having chances to exploit all the capabilities of the engine. Improved version of the CFL loader Last, but not least, the loader will check the fi...
0