This is incredible. I’m curious how you did it considering the game had some kind of tamper protection against mods, at least it was the case when we tried to mod it via BepInEx.
Would you mind telling us why this mod has to remain close sourced? Asking because the dll was flagged by Windows Defender and several other anti-malware vendors, which made me mildly concerned. Though I know the way this mod operates can allude to malware and trigger false positive flags.
I did some malware analysis on the version.dll mod.
It does do some sketchy things like polling for keystrokes but this appears to be a part of the actual mod.
I saw the antivirus detections as well, but at the moment I honestly don’t know exactly what is triggering them. The mod interacts with an IL2CPP game at runtime and uses low-level/native game APIs, so it is possible that some antivirus engines are reacting to its behavior or to certain patterns in the compiled DLL. However, I don’t want to claim that this is definitely the reason without knowing which part of the binary is actually triggering the detection.
Regarding why the project was not open source:
The README currently says:
This game uses IL2CPP APIs and obfuscated/encrypted global-metadata.dat data.
To respect the author’s wishes, this project will not publicly release the source code.
That was the original reason. The decision was related to the game’s IL2CPP implementation, the encrypted/obfuscated metadata, and my intention to respect the game author’s wishes. It was not because I wanted to hide anything malicious in the DLL.
However, I understand that distributing only a compiled DLL becomes difficult to trust once antivirus software starts flagging it. Users have no practical way to verify what the DLL is doing themselves.
Because of that, I’ve decided to change my approach. I am going to open-source both of the related game mod projects, including the source code used to build the DLLs.
That way, anyone who is concerned about the detection can inspect the code, build the DLL themselves, and compare the result instead of having to simply trust a closed binary.
I understand and respect that intention. I wouldn’t have worried if antivirus didn’t throw a tantrum over the dll. Also deep respect on making it open-source. I think this could be helpful to the community when tackling similar games. o7
Thanks for the mod for this great! Not sure if it’s just me but it seems like the range sliders aren’t really working, nor is the orgasm syncer option, as each time there was one nothing happened (actually the motion would just stop entirely).
Some movements don’t seem to trigger any action but only seemed to be a couple (like the insertion movement in the first scene of the first episode and some blowjob options on the second).
And I guess it’s intentional but the shorter movement do a full stroke anyway (but they utilize the axis), not sure if it’d be possible but would be cool to have an option for those to be more accurate and use the axis more (like twisting, which I don’t think I really saw used anywhere).
For penetration, the game gives a pretty consistent depth value, so that part should usually sync quite accurately.
For multi-axis stuff though, I honestly don’t remember if I ever properly added it to this project. I finished most of this mod around July and only randomly decided to release it now, and I’ve made quite a few similar projects since then.But I still didn’t upload it, because while it’s fine for my own personal use, it’s not quite ready to be shared with everyone.
So the slider/orgasm sync issues you mentioned could definitely be bugs, and the missing reactions on some animations are also something I need to check.
I did mostly focus on penetration when making these kinds of mods, so things like oral, kissing, etc. might have sync support, or I might simply never have added it — I honestly don’t remember how far I went with this particular project.
I’m going to open the project again, look through how I set everything up, and see what’s actually broken or could be improved.
Also, the game mod projects I mentioned earlier have now been open-sourced, so anyone interested can check the code directly.
I may eventually set up a Patreon or something similar for this kind of work.
The idea would be that people could sponsor me to look into a specific game — for example, hooking an obfuscated game, finding a specific runtime value/variable related to motion or depth, or locating some reliable parameter that can be used for device sync.
That’s usually much better than manually making sync scripts from animations, and it can save a lot of time if the game already exposes useful values internally.
Some games are also difficult enough that device sync alone isn’t really enough. They may need additional gameplay/QoL value tweaks just to make the basic experience comfortable, and I’d be willing to handle that part too.
Just to be clear about the scope: when I say I hook a game, I mean basic modding for device synchronization and gameplay/value adjustments. I’m not interested in extracting or redistributing the game’s 2D assets or doing anything like that.
So yeah, I’m definitely interested in doing more of this in the future if there’s enough demand.
This is genius, i really should learn to code, as I was testing it seems the handjob was reversed, i’ll look into the other stuff of perhaps try to figure out how to fix this stuff.
I’ll def be following your progress if any, maybe the motivation i need to figure this stuff out myself to work on other IL2CPP content, i knew it was only a matter of time before some mad lad would figure something out
I think I am a bit confused by the different version numbers/dates I am seeing.
Your post says it is compatible with version 2026.7.19. I assume this is a date, 7/19/2026?
On the DLsite page, there aren’t any update dates that match:
On F95, it claims to be version 2.0.2.
If I open the readme.txt in my game files, it says version 2.0.1.
I might just be dumb here, but I legit cannot tell what the game version on the DLSite is supposed to be, and whether a version I find is compatible with your mod.
I just tried out the mod. I think it’s barely functional, as it appears to be tracking the incorrect live2d param during some scenes (penetration-grinding, handjob, paizuri-glans). To fix this one need to identify which one param to track, and if one param is enough. Which is what @ZeroScripts 's CubiLink made easy, if only it can be injected into these protected games…
Did some vibe coding with Claude and managed to make the mod working with Project Manami I brought up above. To get a useable dump.cs I used Sxitxma/Windows-IL2CPP-Runtime-Dumper with ExtremeInjector. Worked on my Windows machine.
Project-manami seems to be have more rigorous tamper protection and crashes when version.dll is detected on launch. Claude’s solution was to create an executable that launches the game + inject the dll. It did work and I have a barely functional mod on Project-Manami. I then logged bunch of param, plotted them on a graph and found the desired one being Param19.
I uploaded the mod. It is very bad due to AI slop and doesn’t produce smooth motion on BLE devices via Intiface.
What I am thinking now is if there is a way to make CubiLink work with these games. CubiLink already provides a complete tool set required to make this kind of intigration. It will be much more efficient than making a fork of the mod for every game.
Thanks for experimenting with Manami and sharing what you found. I agree that reusing CubiLink’s parameter picker, graphs and mapping tools would be much better than rebuilding those features for every game.
My concern is the amount of work needed underneath those tools. The current CubiLink release is still a Mono/BepInEx plugin, and its project page explicitly says IL2CPP is not supported yet. So even after getting a DLL into one of these games, there is still a separate runtime and plugin compatibility problem to solve.
My mods take a narrower approach: they hook specific native methods and read the values needed for that particular game. Getting a useful dump.cs, or successfully tracking Param19, is valuable progress, but it does not by itself provide the full environment CubiLink expects. Injection, IL2CPP API access, interop generation and reliable parameter discovery are separate pieces.
I would not call a reusable solution impossible, though. A native parameter collector feeding a shared mapping/output tool seems plausible, especially if it can work at the Live2D Cubism Core level. Games using compatible SDKs might then share a collector, with templates handling different parameters and scenes. Some protection schemes and game-specific behavior would still need individual adapters.
That would be a substantial architectural project. CubiLink already has a motion-source interface, which is a useful starting point, but it still depends on Unity components and rendering objects, so adding an external data source would require more work than simply forwarding a few values.
So I agree with the goal of sharing the tools. I’m just cautious about the porting and maintenance cost: a shared core with supported backends looks realistic, while a drop-in solution for arbitrary protected IL2CPP games would be much harder to promise.
