I would like to test (and validate) an application that analyses executable files obfuscated with UPX, ASProtect, PECompact, etc... Does someone knows a place where I can find (dummy) samples apps obfuscated with different algorithms?
Many software use packers to compress/obfuscate their binaries. However, instead of searching for such already obfuscated applications, I think you can download packers and obfuscate some application by yourself. You can then use these packed binaries for testing/validating PE analyzer. Some of the well known packers are:
http://upx.sourceforge.net/
http://www.bitsum.com/pecompact.php
http://www.aspack.com/asprotect.html
Related
Recently I'm reading malware analysis. I'm going through this Malware Repository (https://github.com/ytisf/theZoo). Here we can find malware binaries. Can binaries be in packed form? If so, how can we say that these binaries are packed or not?
PS: Packers compress a program and will try to hide internals from us(sort of compression or encryption). I got a doubt regarding this. Can binaries be in the packed form or not?
Edit2: In this repository, they just zipped it to be safe which is not actual packing I'm talking about. After unzipping, we will get a binary. Whether that can be in packed form or not?
First of all, the distinction you make between "packers" and archiver programs (ZIP, etc) or compression programs doesn't appear to have any basis.
A "packed" executable cannot be executed directly. It must be unpacked first. This is exactly the same as (say) a ZIP file containing malware, or a malware file that has been compressed with a standard compression program.
What about a "packed" executable that has been created by a program that does the "packing" in a secret way ... to evade detection? Well that won't work. The malware still has to be unpacked before it can be executed. So that means that the bad gut now has a second problem: getting the unpacker onto the victims machine. And once someone (an anti-hacker) gets hold of the super-secret unpacker, it is no longer secret. It can be reverse engineered ... or simply used as-is by an AV product on suspicious binary files.
The only practical use of "packing" that I can think of is to add self-unpacking functionality to the malware. The malware (as distributed) would consist of an executable with a small amount of code that implemented the unpacker. The rest of the executable would be packed code that implements the nasty stuff. When the user runs the malware, it would unpack the packed code, load it into memory and start executing.
However, there are potential ways to detect or prevent this kind of thing.
If the unpacker writes the executable code into a file prior to loading it, an AV product could detect that.
If the packer attempts to load code into itself, there are ways that could be blocked; e.g. using memory protection hardware + the OS, etc to stop the unpacker from creating memory segments containing executable code; see https://en.wikipedia.org/wiki/Executable_space_protection.
An AV could look for the signature in the packed code, or it cold look for a signature in the unpacker code.
In short, malware could use some kind of "packing" to hide itself, but there must be an executable component somewhere to unpack it.
If so, how can we say that these binaries are packed or not?
If the malware is distributed as a non-executable you figure out what is going to unpack it, and then see if that process is going to give you an executable.
If the malware is a self-unpacking executable, you reverse engineer the unpacking component to figure out how it works.
This is a question from someone clueless about disassembly and decompiling in general, so bear with me. I am curious to know if executable file extensions (for example, listed in http://pcsupport.about.com/od/tipstricks/a/execfileext.htm ) can be disassembled into assembly language so then I can analyze opcode patterns across files.
My logic is that once all these different file extensions are in opcode form, they are all on the same level, regardless of language barriers, etc, so it would be easier to analyze them.
How feasible is this?
EDIT: Example. I have an .exe file and an .app file. If I disassembled both, could I compare them across opcode on the same OS? If not, how about executable files from the same OS. For example, for all executable files on Windows, if I disassembled both, could I compare opcode across each?
EDIT2: How will obfuscators affect my efforts?
In short, no.
The problem is that there is no practical universal instruction set. In practice, every computer architecture has its own instruction set (or sometimes several instruction sets). A native executable format like .exe is compiled to the machine's instruction set, which will differ based on the ISA targeted.
I'm not familiar with the .app format, but it appears to be some sort of archive containing executable code. So if you have an exe and app targeting the same ISA, you could conceivably diassemble and compare.
Obfuscation makes things much harder because it is difficult to get a reliable disassembly, let alone deal with stuff like self modifying code.
Does anyone know where I can find a Firebreath sample (either Mac OS X or Windows) that illustrates how to create a plugin that includes 1 or more other libraries (.DLLs or .SOs) that each rely on other sub-projects built as static libraries (LIBs)?
For example, let's say that the Firebreath plugin is called PluginA, and that PluginA calls methods from DLL_B and DLL_C. DLL_B and DLL_C are C++ projects. DLL_B calls methods from another project called LIB_D, and DLL_C calls methods from a project called DLL_E.
Therefore, the final package should contain the following files:
PluginA.dll
DLL_B.dll (which also incorporates LIB_D)
DLL_C.dll
DLL_E.dll
I am currently forced to dump all source files in the pluginA solution, but this is just a bottleneck (for example I cannot call libraries written in other languages, such as Objective-C on Mac OS X).
I tried following the samples on Firebreath, but couldn't get them to work, and I found no samples from other users that claimed they were able to get it to work. I tried using CMAKE, and also running the solutions directly from X-Code, but the end result was the same (received linking errors, after deployment DLL_C couldn't find DLL_E etc.)
Any help would be appreciated - thank you,
Mihnea
You're way overthinking this.
On windows:
DLLs don't depend on a static library because if they did it would have been compiled in when they were built.
DLLs that depend on another DLL generally just need that other DLL to be present in the same location or otherwise in the DLL search path.
Those two things taken into consideration, all you need to do is locate the .lib file that either is the static library or goes with the .dll and add a target_link_library call for each one. There is a page on firebreath.org that explains how to do this.
On linux it's about the same but using the normal rules for finding .so files.
It is possible to extract executable files??
If it is what are the possible software may i use?
it depends how deep you want to dig into the executable and what kind of data you need from the exe.
As with all exe files you can analyse them on a low level. But I assume you want to have a high-level tool to get back the director files that were used to create the exe, right?
For the exe-file (the "projector" to use the appropriate director wording) there is no such tool known to me.
But very often the exe file is used together with files with extensions such as .dxr or .dir. Those are director files. DXR-Files are protected. But by importing them into director you can extract some of the cast memebers (graphics etc.) that are included. You need in-deep knowledge of lingo to do so.
You might also find .cst or .cxt files. Those are cast files. They can hold media, scripts etc. too. CXT are the protected versions. For these files the same is true as for the DXR and DIR files.
All in all - it is not easy and your chances are low to completly reveal all code and media. Most director programmer use the protected files for distributing their programs. Those do not allow to reveal all data included.
This Python script extracts Macromedia / Adobe Director movies and casts
from Windows and Mac executables.
https://github.com/n0samu/director-files-extract
I have a need to handle various rar/zip files, in Objective-C. Ideally I'd like to be as flexible as possible in terms of rar/zip versions. I'd also like to be able to only extract certain files from the rar/zip files, after pulling out a list of the file contents.
If that wasn't enough, I'd like to be able to access and modify the zip comment.
Is this easily possible in objective-c? I've searched around a lot and found a lot of half-finished libraries that don't do everything I want, or only support rar up to version 2, or don't support extracting single files.
I know I could just use the command line unzip tool that ships with MacOS Panther and up, but this seems inelegant and doesn't help me with rar files, as no unrar application ships with MacOS by default.
Can anyone point me at a decent library that does one or the other of these two types of files, or a recommended best approach for dealing with this problem? I know that one option is to wrap the unrar source, and also wrap the zlib source, but this to me is a daunting task. If there's no other option I'll do it - any advice or guidance on this would be gratefully received.
Thanks!
Yes, doing that it's easy in objective C. For zip files just use ZLIB (it's already included in Mac OS X.
RAR is not that simple though. Look for a C library (not an Objective-C library). There will be way more C libraries for RAR handling than Objective-C ones. And you can use all C libraries you want within an Objective-C program.