More than two years ago I worked on meaningful MD5 collisions, especially creating executables files, but I never finished my write up about this until now (hurray for having a sabbatical 😉 ). The idea behind this project was to create multiple executables with the same MD5, but with different behavior. I ended up creating a Perl script which enables you to create a simple skeleton source code which you can use as a basis for your own code, after compilation you can use the same Perl script to create the multiple executables with different behavior. This project does not show a new way to create MD5 collisions, but makes it easy to exploit the weakness by creating executables with MD5 collisions. I based my project on existing research such as HashClash, and used fastcoll to create the collisions. For further information about MD5 collisions, I would like to refer to HashClash.
The MD5 collision executables can potentially be a security issue for MD5 whitelisting, which is still used by some security products. An attacker could potentially first send an executable which is considered safe and then its counterpart which is evil. Since the files will have the same MD5 hash value the first file will have the second file white-listed. The files could further have impact on products which use MD5 hash values to uniquely identify files, such as certain forensics software.
The whole project was inspired by my first MD5 collision experience while playing SmashTheStack IO and by forensic products using MD5 hash values as unique identifiers for files.
After posting information on my website about the Perl2Exe reversing article I published before, I got a comment with a question on how to perform the same “trick” on 64-bit Perl2Exe executables. Sadly enough at that time there was no free and easy to use 64-bit debugger available to create a similar approach for 64-bit Perl2Exe executables. However, that has changed with the release of x64_dbg. While I am still looking forward to the 64-bit version of OllyDbg, this new debugger looks very promising and with it I was able to create a fairly simple way of recovering the Perl sourcecode of 64-bit Perl2Exe executables. I decided to create this fairly short write-up about how to do this, which can also be used as a first hands-on with x64_dbg.
For reference, the approach for 32-bit Perl2Exe executables (using OllyDbg) can be found here, which also describes how Perl2Exe works and what the idea is behind the approach that we also follow in this article. These details have been left out of this current article.
Update 15-02-2017: User Julian commented on this article below that the instructions did not work on binaries created with Perl2Exe version 24. Updated instructions for this version can be found at the end of the article.
Two years ago I published my Perl2Exe back to Perl article in Digital Forensics Magazine, more information can be found in my post here. Since I published this article in a magazine I was not allowed to post it on my own website as well, but since enough time has passed I am now allowed to publish the full article which can be found below.
Reverse engineering Perl2Exe back to Perl
Perl2Exe is a program which converts Perl source code to standalone Windows executable files which hide the Perl code. When a forensic investigator encounters a Perl2Exe program (for example malware) it can take a lot of effort to analyse these files. This article describes a new and easy to follow approach to recover the full Perl source code from these Perl2Exe executable files, making the analysis of these files much easier.
In the August issue of the Digital Forensics Magazine (DFM) my article on reverse engineering Perl2Exe can be found. The article describes a way to recover the source code of the Perl program back from the executable created with Perl2Exe program.
Reverse Engineering PERL2EXE Back to Perl
Perl2Exe is a program which converts Perl source code to standalone Windows executable files which hide the Perl code. When a forensic investigator encounters a Perl2Exe program (for example malware) it can take a lot of effort to analyse these files. This article describes a new and easy to follow approach to recover the full Perl source code from these Perl2Exe executable files, making the analysis of these files much easier..
Perl2Exe converts the source code of the Perl script by packing it inside a single executable together with a Perl interpreter. The Perl source code is included inside the executable in encrypted form and thus it cannot easily be recovered from the executable.
In the past there have been a couple of other projects to retrieve the Perl source code from Perl2Exe executable files (see boxout 1). However, none of these projects work with the current versions of Perl and Perl2Exe. In the past couple of years there have been a number of Perl2Exe versions released (see boxout 2) and each new version seems to break the previously found solutions to recover the Perl source code.
Word reached me that my approach to get rid of the Buma Stemra Ransomware malware did not work on Windows 7. I initially only tested the approach on Windows XP, but I now took the time to test it on Windows 7 as well. The video below will show that the approach worked fine on Windows 7 in my test environment. While the approach is mostly the same there are some small differences.
Since a week or so a new Dutch version of some ransomware malware is active in the Netherlands. This malware claims to be from The Buma Stemra, but of course has nothing to do with the real Buma Stemra. The malware successfully takes over the system by replacing the start of explorer.exe with itself, so as soon as the system starts the malware will be loaded instead of the normal Windows environment. The malware further disables editing the registry, accessing the task manager and getting access to the system in any way. When infected with the malware you can not access your own system anymore, the only thing the system will do is show the screen below.