OK - you can inspect a whole bunch of things here, but you can also just download everything. That's what I did. In the downloaded zip, there is the decompiled machine code, the call graphs and decompiled C code.
Looking a the callgraph, I didn't see anything that got my alarm bells going or anything. Again, an attempt was made to mess with the applications .dll files.
So let's see if I can make anything from the C code:
At the bottom of the file - the external function calls are listed. Turns out the application calls into the Windows API, seems to be messing with some files and things, but nothing really surprising. OK, let's see what this looks like in code:
I found code that I didn't really grasp and had to start Googling. The code tries to get a handle for the running process and then starts looking for dlls. That's remarkable since the patch application is just one .exe file. There are no dlls with the application - let alone something called 'dup2dispatcher.dll'.
Inspecting the application with the ExeInfo tool, reveals the dup2patcher.dll, which is packed inside the EXE:
So - the patch logic or malicous code could be in there. It seems like that .rsrc section holds the actual dll source and you can save it off to your disk. Insepecting the bytecode revealed this XML section at the bottom, which is an assembly manfiest:
I can read this, which makes me think that none of the obfuscation techniques were applied as suggested in the mentioned blogpost. However, I'm not able to inspect this code with DotPeek.
So ... I'm afraid this is how far I could come. As you can see - the only dependent assembly is Windows.Common.Controls. Since the patch probably has some kind of windows form - that all makes sense. I would have expected system.web in case the assembly went out to connect to some remote box or download some kind of executable.
However - I haven't been able to look inside this dll, so this is where it ends for me. If you have any tips - please drop me a line or suggestion.