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.


SHA-1 of Cemu.exe:


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.


So I started to work on something for myself.

Thought I was being productive. Since I wanted to do something for myself and since the idea of something like this looked reasonable and nice:

Then I had a cursory look at 4chan, of all places. Which I should have never done.

Lets get some things straight here. I’ll be using Steam Survey results in my justifications:

  • MSVC2017 can compile for & target XP. Though hardly anyone uses it. Question is though why bother considering the statistics. Stats don’t lie.
  • I could go down to Windows 7, I thought Win8 was reasonable. And no one seems to use Vista anymore. Granted, Windows 7 is a reasonable userbase size.
  • Windows Vista introduced DirectX10, which is on the same feature level as OpenGL 3.3. Considering the userbase using Windows 10 and Windows 7, I wonder why the heck are people complaining about. And catering for Direct3D9/OGL 1.5 is hardly worth it at all these days, considering the absence of users still on Windows XP. And most libretro cores require OpenGL 3.3 core support anyway, making OpenGL 3.3 support mandatory.

And since it:

I hardly care if it works on others or not. Its my own software. Don’t like it, you are free to do what I did and write something else. The libretro API ain’t that hard.

This now somewhat infamous rant sums it up:

Fuck these people.





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.

What happened:

  • Finished up my work on foo_dsp_effect. Just needs bugtesting. Once thats done, gonna work on the libretro stuff with the same motivation as I have been doing with the fb2k stuff for the past 2 weeks.
  • Cracked Cemu again. Used a patch instead of a keygen, thought it be pointless doing a kg if it will only have its algorithm modified in a week’s time.
  • In that regard, noticed some lamers are repackaging my cracked cemu.exe/serial.bin/settings.bin without crediting me, and to add insult to injury, profiting from content intended to be free by adding adlinks to the downloads.
  • This has been done on Youtube, and many, many other places. Maybe I should inject some watermark to tag any cemu stuff I do. Well, it already has the watermark of the HWID and the timestamp, and the 64bit hash…heh. Maybe something physical in the executable that people can see so that they know its mine.


So far the work is almost complete:

Did what I mainly wanted to. Wanted to rewrite access so that its easily keybindable and has easy access. The remaining issue is due to a audio buffer issue with librubberband and how samples vary depend on the pitch ratio. At the moment the code is quite brittle and won’t work for anything above 48khz. Which is a problem considering FB2K’s userbase (I only had sub 48k samples at the time of development and testing). So need to spend the next few days rewriting things to be more robust for the pitch/tempo DSPs.


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.

What happened:

  • Finished the tempo/pitch/playback rate portions of the rewrite of foo_dsp_effect. Works good now, might need more testing.
  • Started to work again on some libretro stuff. Mainly interested in my own debugging environment for cores. I am hoping that this then would be self motivation for me so I spend more time on VBA-M and other emulators.
  • Messed around with time stuff in Win32. Ended up writing a DLL that hooks some time functions so that it allows me to set times to specific Unix timestamps. Needs much more testing and work on it, since using version.dll is sometimes not exported in applications.
  • Cemu had a 1.7.3 release, seems they changed the DRM yet again.

Did more work on DSP effects in foobar2000.

Found an amusing bug when tinkering the pitch which caused sliders to completely break. Found that (was multiplying and dividing values wrong), so thats fixed. Now left to implement playback rate shift. Was pondering integrating PaulStretch for long tempo ratios, due to SoundTouch having artifacts at medium/long ratios of tempo stretching. Haven’t really messed around with librubberbands much.