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

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 scratch, as the expected result was not met, so that is how years of research and self-reflection passed, before finally turning it into its current state...

A framework library 

After seeing the current state of VoidShell, I guess I can now feel satisfied with the final result. 
It is functional but still far from reaching its peak.
What's the future of this library then?

The library will be updated for a while whenever possible. 
These are the most relevant features expected to be implemented in future build versions:

[Improved Dynamic Portrait]
This is self-explanatory, but use options will be extended

[Preload Mode]
When loaded externally, the library's engine interface area will remain inactive until fully initialized, while creating its system threadworkers

[Auxesis Mode]
A special mode that will work in a very similar way to the Secretary/Anti-Malware methods when a host éxplicitly requests it

[Enhanced Thread Priority]
A special state where the character's thread workers will have their effectiveness enhanced to try overriding the enemy threads' effects

[Improved EIP Redirection]
A special state that can be triggered when the character is unable to reset their readiness timer, which will cause the engine's main thread to be halted before creating a threadworker that reloads the whole match

[1.1B Support]
Code support for this engine version will be implemented for an increased versatility

...

Lorewise, "VoidShell" is actually a foreign entity capable of granting their users a slice of its power while hiding their real form to go unnoticed, which has already been featured in my personal project.
More information will be revealed in my projects blog, and no, VoidShell is merely one of "her" alias

This blog entry is subject to updates, so stay tuned when possible.
Well, this is all for now, have a nice day.

Comments