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 program its arbitrary code, but the results were worth, so...

(> Click here to download this character <) 

As a conclusion, I can say this method is really less versatile than the SuperNull one, but if you manage to put all your shellcode into command slices, the execution may be interesting to see...

Well, that is all for today, stay tuned for new content!
Have a nice day.

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 were but good.

The address for it is at 0x0A424B70

That is how the primary memory bank looks like

That is all for today, stay tuned for more content.

Have a nice day.

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 file's intergrity, making use of certain parameters to perform a better execution from the CFL file.

That is all, stay tuned for more updates.

Have a nice day...