This is a crack for:

[azucat] Milk Girl Sweet memories of summer
version 1.012
Dev site: 
https://www.dlsite.com/maniax/work/=/product_id/RJ387608.html
https://ci-en.dlsite.com/creator/763



Instructions:

1. Rename app.exe to app.exe.bak, UnityCrashHandler64.exe to
UnityCrashHandler64.exe.bak, as the first will get overwritten, and
the second is a privacy concern (uploads crash logs).  

2. Unpack the crack archive into your game directory. 
You need at least:
app.exe, GameAssembly.dll, milky.dll, settings.json, user.json.

3. You should block app.exe in your firewall, even if I took care
to disable all the analytics/crash reporters/telemetrics/online checks
Unity and the developers added. In my tests it does no longer send
anything anywhere, but as I may has missed something, you should
always firewall the game.

4. Play the game with app.exe. Do not launch startup.exe, that's just
the exe used to activate the game officially, it can be safely deleted
if you wish.

5. Enjoy!


Thanks/greetings: 

Game version 1.007 was provided by Craiger80, along with a serial, thanks!
This is the version I started cracking first time, until I realized there 
was a newer one.

Game version 1.012 was provided by HentaiCovid, along with a serial, thank you! 
This is the version that is used here in this crack!

Crack notes and extras:

This is an x64 il2cpp Unity game, protected with PlayDRM (Engima
Protector).

I started a partial unpack of the exe as I was provided with serials,
but it turned out the exe didn't match the official one for its
version, so a full unpack was done relatively quickly using EP tools
that I've improving throughout the year (but 64bit support was not as
solid until this game and the previous one), even if the exe is
nothing but a very simple loader that only calls UnityPlayer.UnityMain
using the exact same WinMain arguments.

The game would fail loading from official Unity exe, but worked with
the PlayDRM(Enigma Protector) protected one, eventually after the full
unpack of the exe was done, it still failed to load (blue screen,
"FATAL ERROR").

I suspected some sort of integrity check, but the game did not seem to
be reading the file, nor was it using any functions for checking the
wrapper presence (from EP), nor was it calling startup.exe's IPC.

So what was it doing? It was just checking if the size was over
1000000 bytes in GameAssembly.dll (game's script):
Game.Script.Sequence.AppInitialize.OOMALDLMNFF.OnEnter(..), some names
were obfuscated prior to il2cpp compilation.

Increasing the exe size or patching the check got me to the title
screen. Now it was showing the title screen with a background, but a
"FATAL ERROR" still appeared. The game was doing a lot of https
requests, a remote config loading request, lots of analytics,
telemetrics, crash reports and half of those were sending a lot of
juicy information about the user to Unity and backtrace.io servers,
information revealed included: CPU, GPU, RAM, username, path variables
and user environment, OS version, other paths, directx info, language,
a trackable user id, and in case of crashes game memory and more.
Of course none of that was revealed as the game was tested in a VM
that was isolated from the internet, but this seemed like a privacy
nightmare for the users and it had to be eradicated along with the
online checks.

I did a remote config request with fake information and it turned out
to be as I suspected, it was loading the game version and some news
from the developer (changelog) through that. If you use Fiddler or
some other https middleman, you can pass the config (and some other
user id request) and the game would load, and then display an error
about the version being toold (I was using 1.007), fixing the version
in the config to 1.007 made it load and play correctly. At that time
I switched to 1.012 game files from HentaiCovid and redid the
unpacking and crack so far.

However, making the users run a http server or Fiddler is not pleasant
and not very proper.

At first I patched backtrace.io's telemetrics and crash reporting that
was in GameAssembly.dll, but that was just one of too many online
calls, there seemed to be no end to them.

So I spent some days studying UnityPlayer.dll internals, the way
methods are exposed to GameAssembly.dll (il2cpp compiled scripts) as
well as interactions.

After studying them, I realized that internally all the http requests
go through a UnityWebRequest class (the C++ equivalent in
UnityPlayer.dll), of which an instance can be exposed to the .NET
(il2cpp) code, but some of it is still called by the internal crash
reporter and analytics, so patching the method/class exports in a
generic way would make you miss those.

Eventually I realized that UnityWebRequest supports 2 protocol
implementations, file:// (VFSTransport) and those provided by curl
(http, https).

I decided I would hook the code that decides which protocol to use and
replace the request URL there with a local file one. To do that, a dll
had to be made as this was beyond what is comfortable enough to patch
manually.

You can find the dll's source code in crack_source along with the
patches and hooks, milky.c is the source code, prologue2_mod.asm is
just the source code for a small piece of code that is injected into
app.exe to load milky.dll.

At first, that code was hooked via a vtable patch (no hooking library
was used), it would check some urls/url patterns and replace with a
fixed file:///file.json URL.

This was enough to stop all the requests going out, but even with it
the remote configuration wouldn't load. After looking if the file is
being read properly, I found out that it was not, it was actually
rejecting any non-GET http method in the file handler (like POST).

This was patched, however there was another check that was found at
the same time, this time it was in .net il2cpp code the
Unity.RemoteConfig.ConfigManagerImpl::ParseResponse checks if 
headers == null or body == null from response, and if so fails the
config. headers are null from the VFS/file handlers.

I had the option of patching that check or providing some headers. For
now I've opted to just patch that check, as providing the header would
require figuring out how the il2cpp garbage collector works and how to
allocate strings that il2cpp code can free without crashing.

So far I've avoided dealing with the gc by hooking after the gc
barrier, but I would have had to do this properly for the headers, and
maybe I will do it for the next Unity game that needs such extensive
patching, but for now I've added another patch for the headers == null
in the dll.

Figuring the allocator might be worth the while as the strings used in
the URL are C++ strings that are sometimes allocated into the object
(no malloc) or in the heap depending on the size. Almost all URLs are
long enough that the allocator is used and the sizes I've used for the
filenames should be under the limit even if the allocator was not
used. Maybe for a future version I will try to get the allocator
functions and study the gc enough to be able to work with it as the
game does, but for now this is enough.

Initially, I've done the patches manually on the dlls, but after
milky.dll was written, I've moved all the crack-related patches into it.

The files and their purposes:

app.exe - Unpacked app.exe, fully rebuilt as close as possible to the
original. I've had to add a small injection to load milky.dll at
entrypoint. 

app.exe.unpack.only - The pristine untouched unpacked exe, useful if
anyone wants to test without the dll in Fiddler or for debugging.
Beware: the game will very quickly send a lot of information that you
may consider private to Unity and backtrace.io. It will even resend
information that it gathered while you ran the game offline (anaytics)! 
If you wish to test, do it offline or carefully configure
Fiddler's AutoResponder to reject all requests from it except those
you provide!

GameAssembly.dll - The extracted game script (il2cpp) from the packed
app.exe Enigma Protector virtualbox. It is not modified, all the
patches to it (and UnityPlayer.dll) are done by milky.dll at runtime.

milky.dll - A small dll that patches UnityPlayer.dll and
GameAssembly.dll at runtime, it redirects almost all http(s) requests
this game does, making them be loaded locally, as well as patching
checks added by the game developers as well as some sanity checks in
Unity's engine that were preventing the redirect from working on POST
requests, as well as some header checks and some other required hooks.

settings.json - unity remote config, it contains the game version and
game news. If this is not provided the game will fail to load, if the
version in config is higher than the game's actual version, the game
will fail to load, if parsing fails in any way, the game will fail to
load. At the time of writing the latest version was 1.012 and this
config and the game files match that. These news are hardcoded, you
could redownload the latest by issuing the post request with some fake
info if the game ever updates, but why would you do that unless you
have new game files?

user.json - Another small config that decides the user's geolocation,
it seems to be needed by Unity before loading the remote config.

crack_source - A directory containing milky.dll's source code for
anyone that wants to see what the dll does or if they want to port the
crack for a future version. The build command line and the loader for
the exe are included.

As usual, you're free to use this crack as you see fit, reupload it or
adapt it for other games!

If anyone wants to provide other dlsite(PlayDRM) or 
Johren/Shiravune (shrinkwrap denuvo version) games to be cracked, you
may reach me at slimypettanko@protonmail.com or contact me on f95zone
by PM.

Enjoy!
