4

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?

Improve this question
4
  • Can you add the real packed binary?
    – Biswapriyo
    Nov 21, 2018 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, 2018 at 18:22
  • Sorry for offtop, what is the first program you use, the one that told you about ENIGMA(5.X)?
    – Uprooted
    Nov 24, 2021 at 1:42
  • 1
    @Uprooted: Detect It Easy
    – c00000fd
    Nov 24, 2021 at 19:44

2 Answers 2

Reset to default
5

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...)

Improve this answer
1

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.

Improve this answer
4
  • 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, 2018 at 21:15
  • try de4dot
    – Paweł Łukasik
    Nov 22, 2018 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, 2018 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, 2018 at 7:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.