i,m really sorry for our late in posting we really working on lots of things … before starting about our subject i should tell you about our advisories and exploits we are not really full-disclosure believers but still we will post some more exploits and advisories at :

http://www.exploit-db.com/author/abysssec

so stay tuned.

OK let’s start ….

=========================================

before start if you are not familiar with PE : The Portable Executable (PE) format is a file format for executables, object code, and DLLs, used in 32-bit and 64-bit versions of Windows operating systems. The term “portable” refers to the format’s versatility in numerous environments of operating system software architecture.

for more information : http://en.wikipedia.org/wiki/Portable_Executable

- now the first question is what is a signature ?

a signature actually is what that means but in computer world and more specific in reverse engineering and binary auditing world a signature is a sequence of unique instructions (actually their representation op-codes) in target binary.

for better understanding please watch figure 1

figure 1 – a c++ compiled binary opened in immunity debugger

reminiscence : an opcode (operation code) is the portion of a machine language instruction that specifies the operation to be performed.

in above figure it have tree red rectangular :

first rectangular are RVA (relative virtual address) of instructions

second rectangular are OP-Codes (will be execute)

third rectangular are readable assembly instructions

so we will search for a sequence of unique op-codes (so sequence of instructions) in our target binary and those byte will be signature of our binary. simple enough eh ?

- what and who need to use a signature ?

most of anti-virus (and other anti-things)

and almost all of PE Detection tools

so now you can imagine how an anti-virus company can detect a malware and how PE-Detection tools (witch areused for detecting signature in compiled binary and determine compiler / packer / compressor and … ) works .

- next question is why we need care about signatures:

before starting any fuzzing / reversing / auditing project we need to about our target binary

identify binaries those have not any signatures

with them we can speed up our reversing and we can find available tools against our target binary

-how we can find signatures in binaries ?

we should search for static and constant location (static instructions) in our file but how we can find them? for answer to this question please watch PE file layout again :

figure 2 – PE file layout

we can search for signatures in a few areas :

around program entry point (where program instructions will start execution …)

from offset (from top to bottom)

each executable file have some other locations can be good for generating signature those are :

around import table (where functions will be import)

start and end of sections (optional section specially)

name of optional / static sections

….

so we can just open the executable under debugger and copy a few OP-Codes from entry point and we are done ? of course not ! because in lots of situations entry point could be change refer to various factors like :

initializing addresses / variables with state of program

if we are in fighting against a packer / compressor / cryptor / there are several technologies they can use for hiding / changing instructions …

note : these changes are more on not “just compiled binaries” it means those have a packer / protector and ….

so how we can find reliable signatures ?

we need to research about variant program situations and then we can understand which bytes/instructions are constant and which are not then we can ignore dynamic bytes and rely to static bytes.

before a real case study i just want explain how packer/protectors works :

a packer will do what it sounds : packing a program. think about winzip it will comperes the program and actually will decrease size of program .

elementary packers just will compress the portable executable and will change entry point to decompression section for better understanding just watch below figure.

figure 3 How typical packer runtime works

1. Original data is located somewhere in the packer code data section
2. Original data is uncompressed to the originally linked location
3. Control is transferred to original code entry point (OEP)

Ok now you know how a basic packer works but today modern packers are not just compressor they will use a lots of anti-debugging technologies against debugger / disassembler to make reverser life harder. this technologies are out of scope of this post.

Ok for example if we want to make a signature for a new packer / protector we need to pack / protect variant executable (it’s better to test on different compiler / size) and then watch which byte of files are changed and which one are static !

you can use binary copy option in immunity debugger for starting our test

figure 4 binary copy

this program is packed with a really simple and good packer named FSG.

and my first signature will be :

87 25 5C AD 41 00 61 94 55 A4 B6 80 FF 13 73 F9 33 C9 FF 13 73 16 33

so now i need to pack more files and check my selected Op-codes to know which one are changed and then we will replace changed op codes with ?? . after a few try we will get a signature like :

87 25 ?? ?? ?? ?? 61 94 55 A4 B6 80 FF 13 73 F9 33 C9 FF 13 73 16 33

so if i search for these bytes i can find i can find them in any program those are packed with FSG v2 !

this example is really really simple for advanced packer we need really test more bytes to be sure our signature is good enough but from my experience length between 30-70 byte from entry point are good enough.

if you be smart you will select good instructions like sections those have 16-bit registers and instructions those are not used all times. so an example of really good signature can be below figure (taken from symantec slides) :

figure 5 ( a really good signature )

OK. now you can make you own signatures just by spending a few time on each target . there are several tools can be use for detecting signatures if executable most popular of them are :

PEiD

RDG Packer Detector

PE Detective

but all of them have a same problem not so update signatures ! so if you have a program that is packed by a really new packer or just a few byte take changed from their signature most of them will fail (intelligent signature detection is out of scope of this post) . so what we can do ? we should have our own database for our job .

so i collect all of existing signature database (those i found) in internet and i removed stupid and duplicated signature from the list those are :

BoB at Team PEiD signature database

Panda Security customized signature database

Diablo2002 signature database

ARteam members signature database

SnD members signature database

Fly signature database

and …

after i combined all of their signature databases i changed a few of important signature to be more general and i added some new signature to my list and my final list right now have around 5064 unique and 4268 from entry point signature.

PEiD can parse external signatures and it’s nice but i liked to have detection in my debugger so i searched for a signature detection library in python (i like python) and with a quick search i found nice Pefile coded by Ero Carrera can handle all of our requirement in working with PE file not only handling signatures you can download it at :

http://code.google.com/p/pefile/

so i decide to use this library to write a pycommand for immunity debugger fortunately i found a copy of a pefile in immunity debugger lib ! so all i have to do is writing a few line of code that can read my database and test it against my binary and tell me the output .
so here is my complete script also have a option for auto-update .

for using this script you just need copy PeDetect.py in you PyCommand directory in immunity debugger python then copy Database.TXT in DATA folder in immunity debugger. after this you just need run it from immunity debugger command bar using !PeDetect you can see the output of this script against some files…

figure 6 – output of PeDetect against not packed file

figure 7 – output against packed file

also this have an argument !PeDetect -u for updating your signature to our latest database. notice that my script will use md5checksum so your changes meaning it won’t be same as my database and your database will be update automatically.

figure 8 – update command

PS : after i wrote this i saw another PyCommand named scanpe wrote by BoB at PeiD it’s really good and have PE scan option but have not update update so no more new signatures …

The Portable Executable (PE) format is a file format for executables, object code, and DLLs, used in 32-bit and 64-bit versions of Windows operating systems. The term “portable” refers to the format’s versatility in numerous environments of operating system software architecture.