# Reversing Py2Exe binaries **[biebermalware.wordpress.com/2018/02/14/reversing-py2exe-binaries/](https://biebermalware.wordpress.com/2018/02/14/reversing-py2exe-binaries/)** View all posts by biebsmalwareguy February 14, 2018 Well, today, I came across an oddity that required digging a little deeper. I saw a C:\boots\syswin.exe, and I know that shouldn’t be there. A Virustotal check showed a high detection rate, but nothing that really explained what the file is, or does. ----- I used 7zip to open the file, and saw a lot of .pyc files inside, so this is Python related. Probably a Py2exe binary. Py2exe is a program which takes a Python script, compiles it, along with any necessary modules, and packages them with a small Python interpreter, into an executable. To verify, I ran: PYTHONSCRIPT is the resource which contains the original Python script. Now…how to go about getting the original script out of the exe? A quick Google search showed me that there are a lot of tools out there for this…and hours of reading and trial-anderror showed me that almost none of them work. Finally, I found [rePy2exe. Thankfully, this](https://github.com/4w4k3/rePy2exe) one worked quite well. The reverse ‘exe > py’ functionality errored out, but I was able to use unpy2exe to recover the .pyc file for PYTHONSCRIPT. Now, I could use option 3 (Reverse Pyc -> Py) in rePy2exe to get the source code back. ----- ----- Then I saw “Segmentation fault,” which, if you don’t know, is a bad thing. After a moment, though: ----- So…it looks like it worked…but I don’t expect to see a 250M Python script. Still…when I opened it, it looked like a Python script. ----- ----- On scrolling down, it was clear that the only issue (and what caused the segfault) was that it printed the Python script over and over and over until it segfaulted at 250M…so, all I had to do is find where the first one ended, copy/pasta, and then I could tear it apart. This is a bit more manageable. Now, to read the thing. ----- So, imports and var declarations, then we see that it’s got functionality to copy itself to USB. Awesome. ----- Then we see functionality to, essentially, destroy every executable on disk by unlinking them…but only if it’s a fixed disk. It won’t kill USB. After that, there’s some tasklist stuff… frankly, I’m not a Python god, so I’m not certain what’s going on there. ----- It queries the runkey…and adds itself. ----- Some more stuff for copying itself to USB… And closes with some conditionals… ----- So, basically, it checks to see if C:\txt.txt exists, and whether the date is before 2016/4/3 or earlier. If not, it launches newthread1, which is the code to destroy all the executables. Pretty fun stuff, right? Notice, there’s no backdoor/RAT functionality, or any network capability at all. There’s nothing to be gained here. This was written by an asshole, just to showcase his or her assholery. Presumably, it was initially written as a logic bomb, prior to 4/3/2016, and left to propagate via USB until that time, when it would explode and kill everyone’s files. Clearly, this was written by a very nice guy, right? Anyway…after all the time spent figuring out how…it turns out it’s pretty easy to tear these apart. So that much, at least, is a plus. -----