Do you remember that famous Windows XP startup sound? If you are like me and grew up on versions of Windows that have long since been retired, then you probably experience a similar wave of nostalgia washing over you whenever you hear that sound. These past few weeks, I’ve been able to experience that sound on a nearly daily basis because I was selected to be a member of the malware analysis capstone team. I was very excited to learn this wonderful news a few weeks ago, and I’m even more thrilled that I have two wonderful colleagues on my team who bring their own experiences and perspectives to the table.
This past week, after learning about some of the tools at our disposal, the team conducted an in-depth static analysis of malware specifically written for the purposes of learning the art and science of malware analysis. You might be wondering, what is static analysis? It’s the process of understanding a malware strain’s functionality without actually running it. How is this possible? Well, depending on how the author of the malware designed the malicious software, there are a number of different tools available to security researchers that allow them to peek inside the executable program. Our team has been using a variety of tools, including strings, PEid, Dependency Walker, Resource Hacker, and PEview. These tools are all covered in the book that is guiding our research, “Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software” by Michael Sikorski and Andrew Honig.
Out of all these tools, my favorite by far is PEview. PEview is a tool that explores various parts of a Windows executable file, including the file signature, headers, DLLs, and the .text, .rdata, and .data sections. Now, for someone who is unfamiliar with how Windows executable files are structured “under the hood,” it’s important to understand that there are several different parts of a file that contain information about the contents of the executable. I won’t delve too deeply into the technical details of how an executable is set up, but what’s important to know is that they contain information about when the program was compiled, what external libraries it utilizes, the functions in each library it uses, and information about how those functions may be used. To a trained eye, it can even hint at the potential presence of another executable “packed” within the outer executable.
If that last part sounded like a foreign language, don’t worry; I’ll break it down into simpler terms that even my non-technical audience can understand. On Windows, .exe files (portable executable files) are the primary types of software programs you use when browsing the internet or sending emails. When developers build these programs, they often use a special tool called a compiler to bundle all the code they wrote into a single file. When the file is compiled, the code is arranged in a specific order that allows the computer to interact with the file and perform the tasks the program author intended. Think of this process as assembling an automotive vehicle. Just like a car has various components, software has different libraries and functions that make the overall program work.
Continuing with this analogy, the reason I really like PEview is that it not only allows a researcher to view each individual component, like the engine, transmission, and steering wheel in a car, but it also lets you explore what each component is composed of. You can see what parts make up the engine, the transmission, and even if the seats are heated. Of course, malware doesn’t have heated seats, but the analogy is that I can gather a great deal of information about potentially malicious software without even having to run it. Just as with different components in a car, you can generally expect specific functionality from different libraries and functions in malware analysis. A malicious program may download another file from the internet or send information to a computer controlled by a threat actor, but by viewing the executable in PEview, you can easily explore the inner workings of the malware strain.
Certainly, there may be times when a highly sophisticated malware author tries to prevent this type of exploration, but that doesn’t entirely prevent any form of exploration using other tools. This is similar to an automotive vehicle manufacturer making components more challenging to disassemble and analyze. It might be more difficult to pop the hood and analyze each component, but with the right tools and expertise, analysis is still possible.
My main complaint about PEview, like most of the tools we are using, is that the user interface is quite clunky at times. However, considering that this tool is over 10 years old and is not actively developed, it is understandable. In fact, I would say that for the job it was designed for and the technical constraints of most hardware that ran Windows XP, it was quite cutting edge, especially for free software. If I were to improve it, I would make navigating the program easier by using only the keyboard. I try to minimize my use of the mouse to avoid constantly moving my shoulders, so this is an important feature I look for in software. I would also improve it by adding a feature that allows users to see information about what each of the dependencies and functions actually do. It would be nice not to have to search for information on the Windows documentation website every time I want to know more about a specific library or function.
In conclusion, PEview is a wonderful tool that gives users the ability to delve into both malicious and non-malicious software. It has not only helped me understand what to look for in potentially malicious software but has also shown me how software works behind the scenes and uses .dlls in the cryptic system32 folder. I can’t wait to continue using it and possibly find a more modern software program that has the same functionality!
-Sean Mack
P.S. Here is a screenshot of my lab 🙂
