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...
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