BASSMOD.dll not getting correctly unpacked

[demberto]

Unipacker fully supports PEtite, so why does it not recognize it? Asks for start and end address.

[vfsrfs]

Un{i}packer asks for start and End addresses if it is unable to detect which packer was used. We have only tested the PEtite packer with regular exe files and not with DLLs, so that might be the reason why it is not working. Can you share your sample?

[demberto]

BASSMOD.zip

[Masrepus]

Thanks, we'll look into it 👍

[vfsrfs]

PeiD signatures indicate that the DLL you have provided is packed with PEtite v1.4. This signature was not included in our initial yara signatures, as we have only analyzed samples that were packed with PEtite v2.0 and up. As I already mentioned we have not tested Un{i}packer with DLLs, but apparently the unpacking worked (see BASSMOD.log). You can find the modifications in the alt_signatures branch.

[demberto]

Yea the unpacking does work, but you probably get a 140kb dll with unipacker. It doesn't work once unpacked though. There's another unpacker named gunpacker which probably does it right, I get a 204kb unpacked dll which does work.
Also sometimes I can unpack an already unipacker-unpacked DLL without getting an error.

[vfsrfs]

Thanks for the feedback for the DLL unpacking. I suppose that the unpacked DLL stops working as we only perform the header fixes for regular exe files and we do not modify the export pointers. We will definitely look into the DLL unpacking and knowing that gunpacker does the job correctly is a great hint to fix this issue.

Regarding unpacking already unpacked samples is possible since we do not remove the packed code from the binary, but instead we just fix certain values like the entrypoint in the pe header. Therefore, we cannot know if a binary was already unpacked. We just start emulating the binary again (now with the real code) and stop when the unpacked heuristic matches, for instance, when there is a jump from one section to previously allocated memory. Nonetheless, this behavior is desired, as a file can be packed multiple times with the same packer. The drawback is that if a file was only packed once, then the second run through un{i}packer will yield garbage. Maybe we could add some indicator in the binary we can check to ensure that a binary is not unpacked twice, and only unpack it a second time if there really is a second packer stage.

[Masrepus]

On the other hand, executing an already unpacked sample a second time should not create any problems. The entry point has been switched over to the unpacked original code, so the sample starts executing its payload, i.e. usually the part where it wants to gain persistence in the victim's computer, download a second stage etc. At this point in time, it will most likely not modify its own code anymore, let alone destroy itself. So the code that is of interest for a malware researcher is still there in the executable that is dumped after the second run.

The only minor drawback here is that we update the entrypoint to the place where emulation stopped/crashed (usually at the first Windows API call that has not yet been implemented), so when running the sample, some instructions are skipped.