I'm trying to reverse a Windows executable that shows as having been packed with ENIGMA(5.X):

enter image description here

If I later check the class name for one of its UI elements, when the process is unpacked and running, it shows as a .NET class WindowsForms10.BUTTON.app.0.378734a:

enter image description here

But if I then attach to that process with dnSpy, I can pause that .NET executable somewhere in System.Windows.Forms.dll in Application - UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop() function but there seems to be no info on the .NET assemblies from the target process itself:

enter image description here

My goal was to see the .NET code after the Start button click in that app. Any idea how should I proceed?

  • Can you add the real packed binary? – Biswapriyo Nov 21 '18 at 17:09
  • @Biswapriyo: I'm not sure what the policy is for posting this link here. (Moderator: I'll remove it if it's not allowed.) Here's it is, direct link to a 7-Zip file. The author put a password on it: kahusecurity -- A word of caution: once you unzip it, it will be reported as malware by your AV. – c00000fd Nov 21 '18 at 18:22

After you press 'Pause' you will end you in the message loop - that's ok. Go to the call-stack window and you should see your binary in on of the previous frames. Double click on one of them and dnSpy should load it and analyse.

But since the binary is packed (and probably obfuscated) I think you need to first unpack it and run this version in order to correctly map instructions to lines.

  • Yeah, the callstack has the reference to some location in the Main() function from the target .NET process but clicking it in dnSpy does nothing. TBH, I've never unpacked a .NET executable. What's the process for that? Is it just a manual process by dumping memory in the native debugger first. – c00000fd Nov 21 '18 at 21:15
  • try de4dot – Paweł Łukasik Nov 22 '18 at 7:14
  • Can de4dot access files from memory though? I'm getting The file isn't a .NET PE file if I just run the original exe thru it. – c00000fd Nov 22 '18 at 23:03
  • No, not really. It looks like the original exe is not a .net assembly and only after unpacking it becomes one. – Paweł Łukasik Nov 23 '18 at 7:25

OK, I think I got it. The tool I needed was MegaDumper. (I couldn't find the executable on its Github, so I had to build it myself.)

Then here's the steps how I used it:

  1. (I'm obviously doing all this in a VM.) Start up packed executable and let it unpack itself. (In my case it was a GUI app so it continued running.)

  2. Start up MegaDumper and locate the .NET process in the list (at this point it is already unpacked in memory).

  3. Right-click it and pick .NET dump, wait for a little bit and it will create a folder in the same location with the dumped .NET files.

    enter image description here

  4. Then simply open the .exe from the dumped folder in dnSpy and it will be able to disassemble it as normal, so you can place breakpoints and debug it:

enter image description here

Lastly, just want to say that, from a quick glance, the packed .NET executable in question does not appear to be malicious. The reports by multiple AVs were probably caused by the use of the Russian packer. So, this might be a clue to developers who decide to pack their legitimate software. (Just saying...)

This site is temporarily in read only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .