Emulation

Update: The original developer noticed my IL level hacks and made them official in the next Monochrome version (and current private beta), with a configurable and hidden blacklist. Thanks to Piotr Pawlowski (foobar2000/ex official Winamp plugin dev) for this!

The following tutorial shows the very basics of .NET hacking.

This time, a practical real world application is used: modifying IL to self-censor content that is said and received on IRC. This was done by me to help eradicate possible sources of drama in my life (thus saving myself from an early death). Plus it gives people a possible relief from my ranting.

This tutorial will go through the basics of editing a .NET executable on a IL level using code decompilation/recompilation.

First of all, acquire dnSpy. It is a excellent debugger for .NET with extra capabilities for recompilation of CLR code.

The target used is Monochrome : I am well aware its GPL, but its good for a tutorial such as this, plus where is the fun in just recompiling the app?

Secondly, load up Monochrome in dnSpy:

You can see the various namespaces in use by Monochrome, thankfully its not protected. Various .NET based protections will scramble code making it harder to debug such applications, just like Denuvo and VMProtect with native C/C++ apps.

Next will take some time, to find some code that relates to what we want: basically we want to just limit what we can say and what we can receive. I did some looking around and funnily enough there is a C# class called “InputBox” in the code…

Suspiciously, there is some methods in there that look, well, suspicious :). sendinput() looks like a dead giveaway for something, so lets find out….

Press “Start” and click “OK” to start the debugging process.

To debug a class method, simply double click on the method. You can select breakpoints by double clicking the code line in the decompile.

To check if this method is responsible, I just typed into monochrome’s inputbox “test test test”. Instantly, the breakpoint is hit and….

We found our line. Now lets try editing the code of Monochrome so that it filters out what we type according to a filter list. Right click the code listing in dnSpy and click “Edit Class (C#)”

Here we see a decompiled listing of the code in the InputBox class. From here we can do edits to the source code.

Here I added a line so we can use the regular expression namespace and classes in .NET, which could be useful for text filtering.

In the sendInput method, I did some extra code which will be appended. The code basically looks for any mention of keywords in a list that are in the entered text. If they exist, they are rejected, otherwise, the sentences are rejected. Then click “Compile” to recompile the code. You may need to clean up any code errors the recompiler picks up, which are listed in the log.

To test our code injection, we save the module by going to File -> “Save Module”.

Then we just run the debugging process again, with the patched executable to test.

As you can see, the new code is in the executable, now time to test…..

No matter how hard I try, I cannot enter anything with the word “byuu” in it. It is not registered in the log, and thus, never sent.

Next is finding the code responsible for recieving entries in the channel view, ironically there is a class called “ChannelView” with the “addline” entries.

Which seems to fit the format of the text in the main log box shown earlier. Now is just a matter of adding code to filter lines based on content.

To make the job easier, just right click the code and click “Edit Method (C#)”. This will allow editing of just the code relevant for that particular function.

From there….

Make your alterations and then click “Compile”. Don’t forget to save the module again to save your patched code changes.

One thing I wasn’t sure of, is whether dnSpy allows realtime code editing and then rerunning of recompiled code. Feel free to correct me if it can, which will make imo, a great .NET assembly editor even better.

 

 

A while back I did some work with GlideN64 to perform noise emulation entirely on the GPU.

I stopped working on it. As usual, certain groups of people said this is due to “people being mean”.

So, today, figured I relook at it and see if I could improve on the implementation as last time and see if I can optimize the current implementation.

The implementation this time around is rather simple:

  • Use one line of GLSL for the actual noise generation
  • Scale the coordinates used for the noise seeding according to N64 resolution *properly*
  • Use prime numbers to seed the PRNG more.

This results in *8* lines of GLSL compared to *183* lines of C++.

The shader is as follows:

 

This will be a basic primer in the bypassing of Cemu 1.74x/1.75 DRM. This is subject to change in future versions as Exzap fixes these vulnerabilities.

Tools used:

  • x64dbg with the SwissArmyKnife plugin.
  • MSVC2017 using MinHook (though I tried using libudis86 in the past)

 

1) Start by finding the 64bit hash, you can find it by finding out where the cpuid and harddrive hash meet, as well as the timestamp.

2) Make it always return 0

The function prototype for the hardware hash was found out through basic RE, not using a decompiler.

3) Using hardware breakpoints in the calls that use the 64bit hash method, try to find where the unregistered bytes are flipped and reset them back to known registered state. As in, trace when the 64bit hash fails.

 

4) Kill server calls. Plain killing all network related code is not enough. I found hooking some Wininet calls is enough to do it, though Exzap could detect hooks using some off the shelf protector or some own code.

I found redirecting to localhost is enough for the other network code to succeed.

The full sourcecode for this primer is here: https://github.com/mudlord/cemuhack

No, I wasn’t paid off.

Some of the reasons I stopped developing it are:

  • In my personal life, I recently found things that actually have more meaning than just repeatedly cracking the same thing over and over again. I rather focus on those things. I rather spend the time I have on things now I actually enjoy instead of cracking something I hardly use. Plus, I rather spend time doing things I actually enjoy with the time I have these days, like a normal person would.
  • I cannot fight Exzap, its clear pirating Cemu hardly made a dent in his profit base.
  • I learnt what I wanted to know from Cemu’s DRM system. I learnt a great deal about x64 reversing in the process and worked out some new ways for myself on cracking things.

Just from a traffic report for the month/week.

  • VBA-M is explained due to my avatars.
  • cs.rin.ru is fine, since I know there is a presence of some people who use Cemu there.
  • Yandex is probably some Russian forum, so, again, fine.
  • 4chan is, as expected.

What I don’t expect nor like is the adfly or zytpirwai links. Personally I wish those would go the heck away since I would rather they link to my blog like Reddit and cs.rin does. I wish there was a way to starve adfly links of oxygen.

Cemu 1.7.4c

Note: I’ll crack it when I feel like it and if I feel like it, if at all. Plus, if I am motivated enough to deal with Exzap’s constant DRM changes each single version, and not feel that cracking each successive version is turning into a mindless boring job.

http://mudlord.info/trashheap/cemu174c.zip

SHA-1 of Cemu.exe:

5a194a0e6a9c216ba43dc23e35581b40e526e82b

Used a more thorough and shotgun approach this time, to make it easier for noobs to deal with.

Seems there was the usual bag of crap. Plus some new stuff. Like….

Protection triggers inside HLE handlers.

I find it odd they didn’t amp it up to eleven, but without saying much, doing more could eat HLE handler performance… Ew.

I did it this way just for mental masturbation, since thats how you get better at RE, by pushing yourself in how you do things and what you do. I have zero interest in Cemu as a emulator, and people I know know how I feel about the Cemu team’s “ethics”.

Apparently someone on Discord tried Zelda and it works? All I did was boot the usual suspect MK8 to see if it runs.

 

EDIT: Updated to 1.7.4.b

EDIT2: Updated to 1.7.4c. You will need to use the files in the zip for this rls, especially settings.bin (but feel free to change your settings), serial.bin and Cemu.exe. They seemed to have upped the security for the DRM it seems.

Credit to AceofZeroz for supplying the original uncracked thing and the idea.

Added a special serial.bin for use for this version:

EDIT3: Had a quick look at 1.7.4d, seems its changed a fair bit, yet again. Instead of triggers in GX2 HLE functions, there was a unknown at this point slowdown whenever a cracked version is used, just like when the interpreter is used. Which I admit is proving a great pain to debug. Exzap is finally doing a good job with the DRM it seems.

 

One of the things I wanted for a while is a small libretro core loader, so I can debug cores, since my personal goal this year is to be productive again somewhat in emulation, since I admit I did enjoy that. Over the course of two weeks I have started to work on it again, since its based on some old emulator code I was working on. Eventually I got the loader to the stage until it manages to properly boot something:

The loader is written in MSVC2017 and is intended for Windows 8 and up. It uses a OpenGL 3.3 forward compatible core context (yet to be tested) as well as a generic OpenGL 2.0 context with extension usage. I worked on it this week however to the point I got something salvagable:

Needs work on audio, mainly with dynamic rate control and working on buffer underruns.

There is a couple of things needed to be added yet before it is remotely usable:

  • Core variables/configuration
  • Input with proper rebindable keys.
  • Dynamic audio rate control
  • Savestates/save files
  • Proper OpenGL core support

User desirable features like pixel shaders, rewind and video recording will not be supported. Any public versions, if at all, will have DRM on them.

http://mudlord.info/trashheap/cemu173d_crk.rar

http://mudlord.info/trashheap/cemu_patcher.exe (for those that don’t want to download the above package and just wanna use the uncracked 1.7.3d build running around on 4chan.org). Nukes settings.bin though since some values are in it that are needed for the crack to work.

Use the included files. Should be obvious what executable is used to run the cracked version.

Backup settings.bin if you want to mess with the uncracked version in x64dbg. I included the x64dbg patch database if you want to mess with the uncracked version some more, to find a more efficient way to patch, etc.

 

Technical details:

  • Just does the bare minimum to crack it. Did this purely to have something out as thoroughly reversing and keygenning the target would take significantly more time than just plain stupid shooting holes in the DRM.
  • Forces HWIDs and timestamps calculated in Cemu.exe to match the ones in settings.bin, so you need that file.
  • The 64bit fingerprint was done by plain serial fishing, anyone who wants to know how that works can just read the many documents on reading values and things in a debugger.
  • You also need the serial.bin included to pass the serial.bin checks. Didn’t patch the serial.bin check out.

In the interests of being concise, I figured I post the following, because a certain reddit moderator did want precise proof of what I know:

SuperRetro16 violates Snes9x’s non-commercial license. I know this because of slight obscuring of functions as well as the number of matches of code compared to the various Android libretro ports of Snes9x. The following forensic pictures illustrate this: