Posts

Newest Post: An Uncertain Future

Good evening, my readers. As some of you have already noticed, I am working on a personal project I had created several years ago lately, a space where my original creations would be featured. However, as my old self being was unable to deal with the workload and expectations back then, small progress was made before being put side and focusing on the engine instead. I certainly wonder why I did not give this project the attention it deserved, but well, time is irreversible, so I will have to work with the  bare-bones I had left... At present, I got heavily motivated and finally resumed my project after months of reworking the core parts, so this is going to be the main entry where the latest information will be posted. The main plot will not be the big deal, of course, but I will try making it different from the usual. The project has been divided into parts in order to fasten the release process, as I would be stuck in it for longer otherwise, so relevant content will be shown wh...
6

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

M.U.G.E.N Engine - VoidShell Library

Hello my fellow readers! Well, before starting to talk about VoidShell, I will try refreshing your memory... Does the word "Eikidankai" remind you of something? This portrait will definitively make you remember it then: Said word has been reserved for my personal projects from now on. Characters who  previously  used it were already given a new name, and  VoidShell  has come to replace t he namesake module , so let us get started! What is even VoidShell? It is a  general-purpose library for M.U.G.E.N Engine that allows  Void characters to  protect their main PlayerCache data while providing them a simple but vast toolkit  interface to use in said engine. Characters loaded through this library will have their primary data remotely  protected besides providing basic contingency plans against certain enemies. They are also granted the capability of remotely tampering with the enemy to weaken them further, called as "Player Arts", which can be a...
0

M.U.G.E.N Engine Researches: State Filepath Overflow

Good evening, readers.  It has been a while since the last blog entry was created, but well, life things. For this occassion, we are going to talk about the latest vulnerability discovered in M.U.G.E.N Engine, which has been used by SuperNull characters like " On The Verge of Death " or " Qvorda ",  so let's begin. State Filepath Overflow, also known as " STBOF " or " ST.Path ", is an engine vulnerability that allows for arbitrary code execution during character selection, making it a good alternative to use for SuperNull characters. The discovery of this vulnerability was born out of Nomi 's ideas about trying to overflow the ST Filepath textline in WinMUGEN, which was impossible to perform, as only 255 bytes can be used per text string. However, it could  feasibly be used on the 1.xx engine versions due to their increased textline size limit(4095 bytes), so I decided to investigate it further. "St" is the entry filepath the en...
0

M.U.G.E.N - Engine Patch Differences

Hello my fellow readers. You probably noticed new engine patches that combine the functionality of 3v3 and 4v4  simul matches have been released for WinMUGEN and MUGEN 1.xx , but before proceeding to download them, you decide to know what makes these engine patches worth it. Well, you are in the right place to know what improvements my engine patches feature, so let us begin! (> Adjustable Simul Team Limit <) Main feature of my engine patches is the adjustable team limit,  which allow you to create simultaneous  matches with a maximum of 4 characters, so 4v2 or 3v4 matches are now possible in this patch version. (> Corrected Versus Screen <) Versus screen is now capable of showing the characters' potraits, while a maximum of 4 player names can be displayed, depending on the engine version.  (> Position Adjustment <) The other 4 characters will have their position X adjusted to their nearest partners instead of appearing on random locations when a n...
0

M.U.G.E.N 1.xx: Engine Patches

Oh, hello, readers. I never thought I would end up creating a blog entry for this, as the latter was not even in my plans, but well... I have created these engine patches, which allow you to create simul matches with a maximum of 4 characters instead of 2, while some additional code fixes were implemented in said patches. Engine Version Download Links: (> 1.00 - 4v4/3v3 Simul <)  or  (> 1.1b - EX+ Type <) Warning:  As expected from engine patches, unpredictable results could occur if known exploits are triggered in this program version, so keep it in mind while selecting your characters. I am aware engine patches that implement this have already been released, but these patch versions also fix some primary code defects. Additionally, the 1.1b patch version has been updated to make it compatible with one of the most known add-ons, MUGENHook. ... There is also a  WinMUGEN  patch version in case you need it.

M.U.G.E.N 1.1b: EikiLoader.EX - Postman Reloader

Good evening, readers.  On this occassion, I have created a Reloader template from the EikiLoader.EX program for this engine version, that allows you to load a full version of your character while creating another instance of the process in a similar way to the Postman method. This exploit template uses the STBOF  vulnerability, which we have already talked about previously, to execute its shellcode. (> Download Here <) After downloading this exploit template, you will have to read the "ReadMe" text file to implement it in your character properly, before executing the Reloader shellcode.  You can use this to create your SuperNull/Reloader characters easily without the need of creating complex ROP chains to execute similar code. This is all for now. Have a nice day.

M.U.G.E.N 1.00: ST Filepath - Buffer Overflow Attack

Good evening, friends. It has been a while since I have not talked about engine vulnerabilities, but I think this is the right time to start talking about this new vulnerability. This research was born from Nomi 's ideas about trying to overflow the ST filepath line in WinMUGEN, which motivated me to investigate said insight in M.U.G.E.N 1.00; a nd as expected, it is possible to perform a buffer overflow attack from there by creating a very long filepath string that overwrites the character loader's buffer region including the return address, allowing us to execute our ROP chain. This exploit can be used on both M.U.G.E.N 1.00 and 1.1b, but the main downside is not default-processing reversible, which currently restricts its use to SuperNull:Reloader characters only. (> Full information about this engine vulnerability can be found here . <) Note: Due to nature of the ROP exploit technique, do not expect this exploit to work on all the computers, so beware of it. Well, tha...

M.U.G.E.N 1.00: Command Trigger - Buffer Overflow Attack

Good afternoon, friends. Hmm, I never thought I would be talking about this vulnerability again, but well, let us go straight to the point. As you can guess, this vulnerability also exists in M.U.G.E.N 1.00, but due to the NX Bit protection being active in the program, shellcodes cannot be directly executed, so it is required to use an exploit technique, known as Return-Oriented Programming , to circumvent said protection. I have recently made an exploit that takes advantage of such vulnerability, but as there are several pointer limitations to build a ROP chain that jumps the engine back to default processing, it is currently limited to SuperNull ~ Reloader characters. (> PoC can be downloaded here <) Note: As this exploit requires ROP chains to execute its shellcode, do not expect it to work on all the computers, so beware of it. Well, that is all for today, have a nice day.

Eikidankai EX

  Title is self explanatory, so let us go straight to the point. I have been programming in these days, an omed build for Eikidankai characters(stylish ones), capable of beating ZIP characters. I have thought about this concept some months ago, but packaging code stuff prevented me from progressing with it, until friends told me about a certain program to pack content into a single executable file... That was how a new Omed concept was born: Eikidankai EX There is no difference between the full Eikidankai build and the EX version but the way they are loaded in program data, as the latter is linked to the program, so it is instantly loaded when opening M.U.G.E.N. Eso Brad, as the first Eikidankai EX character I have made, will be released to the public after dealing with the last details. That is all for now, stay tuned for new content. Have a nice day. 
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

Eikidankai Development Log(1)

Eikidankai Development Log: Catching the WinMUGEN primary thread. The development of Eikidankai has been somewhat tedious to program, as when there is an interesting function to add into the coding, it mostly implies to modify the structure of all the code to implement it, or else I would not be able to perform that. That is why I am taking over 2 years or more to program that, well... One of the functions I had implemented some months ago was the ability to manipulate the primary thread of WinMUGEN, which in the previous versions of Eikidankai were not able to perform it. In this case, I used the SuspendThread function from an external thread to freeze the primary one. WinMUGEN before getting suspended by Eikidankai. Done!.. The suspend count has been increased by 1. That is all for now, have a nice day or night. Stay tuned for upcoming posts!
0