1

I am facing an odd situation. I have a licensed game that's doing odd actions on the system. I isolated it as I could and observed the behavior both network and so forth, and I suspect it's a custom-made malware. Till now, it wasn't discovered by any antivirus.

While trying to load it with IDA, I observed that I couldn't get it to analyze at all more than first few offsets – meaning most probably it was packaged with custom packager. I have never tried such a thing until now, and I would need a tutorial in this regard. Or some possible ways to improve my skills, or any documentation for this purpose.

I have also tried to find a loader to start my program and just dump the PE from a certain address, but unfortunately there's no such thing anymore, or I haven't found the right tool.

Thank you very kindly.

2

This answer covers the entire analysis process that you can perform when you want to analyse a potentially malicious sample. If you are interseted only in unpacking, see Manual unpacking subsection.

Quick solution

In order to determine whether your file is malicious, if you don't mind sharing your file with other parties, you could try any of the two following solutions:
  1. Submit the file on VirusTotal. If you don't want to upload your file, you can still check whether it was already scanned there by submitting only hash of the file.
  2. Send the file to some antivirus company for analysis. Some antiviruses have an option in their user interface for sending files directly, but they also provide an file upload option on their website (I don't want to advertise any antivirus product here so I recommend you to send your file to the antivirus company whose product you use). This way, your file will be analysed by professionals having right tools and experience, so there is a high chance that if there is something wrong with the file, it will be detected by them.

Advantages:

  • you don't have to risk running potential malware on your Virtual Machine (sometimes malware can try to exploit some older versions of virtualization software and try to move to your real computer, there is also a chance you misconfigure your VM and then malware can cause some harm)
  • quick and easy, doesn't require additional knowledge

Disadvantages:

  • you have to submit your file to other companies
  • you have to trust antivirus vendors they analysed the file properly

Analysis and unpacking

If you don't want to share your file with anybody (and it seems to be the case, since your game is licensed), you have to analyse the file yourself.

Setting the analysis lab

First thing to do is setting the analysis lab. I will not cover the details here, since it is described in many places (try to search "setting malware analysis lab" for details), but I will emphasise the most important things:

  • you want to use virtual machine of course. This will provide you safety, but it will also allow you to do snapshots and restore them if necessary.
  • you don't want to enable Internet connection for that VM. Unless you want to dive deeply into network protocols used, you won't need that. And your question is about unpacking, not about detailed analysis - I have analysed many packed samples in my life, but neither of them needed Internet connection in order to be unpacked.
  • you don't want to enable shared folder for that VM, since it is another security risk - just drag and drop the sample into VM and you should be fine.

Manual unpacking

After you install all the tools you need I recommend that you make a snapshot - this will be a starting point for any future analysis (some of the tools you may use are described later on, but feel free to search for other ones and choose them yourself). Then, drag and drop your suspicious file into that VM.

As the first step, you probably want to make some dynamic analysis to check whether something suspicious is done - you may use for example regshot for that purpose (do the first regshot snapshot before you run the sample and the second one after your run it - then compare them to see for the changes made in the system). If the file is malicious, in many cases this step will reveal it and you won't need any further analysis. If nothing strange happens, it's time to analyse the file statically. You may follow the following steps:

  1. Try using Detect It Easy and PEiD and see the results. If the sample is packed, there is a chance they will tell you the name of the packer. Then, you may search for unpacker in the Internet. You will rarely find one, except for easy packers, but it doesn't cost you much time, so I think, it's worth a try.
  2. If your file is indeed packed (one of the tools above has told you that or the file has high entropy), open it in your favourite debugger (which is x64dbg judging by one of the tags you added to the question).
  3. Now, there are several methods that can be used to unpack the file. I will try to describe each one of them:
  • some packers use pushad instruction at the beginning and corresponding popad instruction at the end. If that is the case, you can just set a breakpoint after pushad and navigate to the stack (that is, where ESP register points) and put a memory breakpoint at ESP+4. It will be triggered when popad instruction is executed. Then, you will probably see a jmp instruction nearby, possibly with destination stored in some register - it will be the entry point of the unpacked file. You may do a dump after the jump is performed and analyse your file statically from here.
  • the second option is more generic and works in many cases. It relies on the fact that packers usually use some specific API functions in order to recover the original executable: these include LoadLibraryA (and other LoadLibrary variants - see MSDN for more details) and VirtualProtect. You can set breakpoints on these functions and they are often triggered at the end of the packer stub. When the code returns from these functions, you can search for jmp register instructions nearby and if you find one, it will be likely the entry point of the unpacked file. Graph view of the function can be very helpful here (if I'm not mistaken, you can trigger it in x64dbg by pressing g) - jmp register instructions will be located at the end of nodes without successors. Even if you don't find these instructions (transition to EP can be done even by ret or in several other ways), you can try to step over instructions manually until you find EP, since you are likely to be close to it. Snapshots come in handy here - you can do them from time to time and restore in case the execution goes too far (for example if you step over the call to the function that does an actual jump to the EP).
  • If other methods don't work, you can always run the program, let it go for some time, and then do a memory dump of it. You won't get a clean, unpacked file, but you will most likely see the strings and functions. The dump you get can be also used to locate the original EP - you can open it in IDA, navigate to some function that you are sure belongs to the unpacked file (and is not in a packer stub) - for instance some function F referencing strings appearing in your program and find cross references to it (pressing x). Then navigate to some function G referencing F and do the same. You can repeat the process until you encounter function H which doesn't have any cross references and it is a candidate for an entry function (containing EP) in the unpacked program.

For process dumping you can use LordPE. Possibly x64dbg supports dumping as well (I'm not sure, I know OllyDbg had such a plugin). For imports reconstruction you can use Scylla.

Note that these methods work often but will not work every time - there are protectors using more sophisticated techniques than just packing and do not have unpacked file in their memory at any time of execution. Several packers also encorporate ani-debugging techniques. These things may happen in your case, since licensed game can be heavily protected.

8
  • Thank you very kindly for the answer! First thing i did was the lab analysis, of course - I thought of that in the first place so we're all covered. Now, when I started to analyze the executable a bit and verify it, it seems it's not recognized by any of Detect It Easy or PEiD, so it's most probably a custom-packed and custom-encrypted(?) executable. This was the bad news for me. I used x64dbg to try to find any answers, and i dumped a section of memory in order to find a executable, but my .data, .text, .reloc are obfuscated for some reason. How do I manage that?
    – Jcknsz
    Dec 13 '21 at 13:22
  • By obfuscated I mean that I do not even see them as .data, .text, so forth. I presume they are there.
    – Jcknsz
    Dec 13 '21 at 13:34
  • Did you try second and third unpacking technique I described (breakpoint at LoadLibrary and dump after some time of execution? Third technique should reveal something, and if not, it may be more complicated to unpack the file.
    – bart1e
    Dec 13 '21 at 16:53
  • I think I might have found the EntryPoint, the program mentions it starts another instance of itself but unprotected (it named it notprotected for some reason). After I found this entrypoint, what would be the best course of action?
    – Jcknsz
    Dec 14 '21 at 1:17
  • I could unpack it and fix it manually, but so far I haven't seen any PE format. This sequence I discovered based on your advice is somewhat after the .rsrc, but in a unknown memory area. Would it be valid even if it would be after the .rsrc area? Does it make sense? Thank you again.
    – Jcknsz
    Dec 14 '21 at 8:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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