Introduction

as you may read in @abysssec in twitter actually in past a few months we did a cool research on bypassing anti-viruses and got really great result .

Bypassing anti-viruses is not a new topic and it’s still about encrypting / decrypting of a program to being hide from AV eyes. In past it was really, really easy task to do but AV’s getting smarter and bypassing all anti-viruses with some really unique methods that each of them use is not funny and neither easy to do.

before i go feature i like to have a simple glossary for unfamiliar readers.

Glossary

Crypter : the program (mostly GUI) will crypt the malware / bot to make it hide from anti-viruses

Stub : the Decryptor of crypted program

FUD : Fully Un Detectable (FUD = no AV detect)

RUNPE : run the PE without headers in memory

USG : unique stub generator. (make unique stubs)

Binder: will join two file will drop in hdd or mem

Pumper: will increase size of tool

EOF : end of file(in crypter it need to preserve)

Cloner : will clone the file (Decryptor like in HDD)

Icon Changer: will change the final exe icon

well there are two also different kind of crypters scan time and run time. The good crypter is run time one because as it name says the scan time crypter is just FUD at scan time and when you run it and after real malware decrypted it will be detect so not that useful. And the real crypter is the runtime one.

How it works ?

if we remove all complex technical info for bypassing all 35 anti-virus around the world it works really sample.

it simply encrypt program, decrypt, and then run it in memory. encryption algorithm is not important and sample ideas are enough to make a crypter fud

but some of mostly used alghortims are :

I. RC4

II. AES

III.DES

IV. TEA

V. XOR

VI. CryptoAPI

VII. blowfish

note that there is important part in your job and that is run the malware safely in memory after decrypting it , and this is done by RunPE . the idea of RunPE comes from great PoC by Tan Chew Keong called dynamic forking of win32 exe : http://www.security.org.sg/code/loadexe.html

steps and idea are really sample :

CreateProcess

Find Base address

Virtualalloc

Align sections

Fix thread context

Resume thread

but this is not easy to hide this kind of API chaining from anti-viruses .

so we finished our research by writing a new fud crypter and our crypter is unique and different with public ones .

4) Vulnerabilities detail

The vulnerability exists in gdiplus!GpPath::CreateDashedPath function of gdiplus.dll that is responsible for bitmap drawing and other 2d graphic rendering. EMF+ file is one of the image file format that is rendered by the library. And the vulnerability is based on some floating point calculation of an EMF+ path object.

We made the following proof of concept to trigger the issues and it will be explained more:

A little taste of file format we simply put a EMF_COMMENT record (id = 0×00000046) and embed and emf+ geraphic object ( id = 0×00004008 ) . For simplicity we ripped out a valid graphic object from another file and started to play with it. The record have two important area that we highlighted them in the above picture.

Here is the faulty code:

.text:4ECFCBAD loc_4ECFCBAD:

.text:4ECFCBAD mov eax, esi

.text:4ECFCBAF shl eax, 3

.text:4ECFCBB2 cmp [ebp+lpMem], 0

.text:4ECFCBB6 push eax ; dwBytes

.text:4ECFCBB7 jz short loc_4ECFCBCE

.text:4ECFCBB9 push [ebp+lpMem] ; lpMem

.text:4ECFCBBC call GpRealloc(x,x)

.text:4ECFCBC1 test eax, eax

.text:4ECFCBC3 jz loc_4ECFCCDB

.text:4ECFCBC9 mov [ebp+lpMem], eax

.text:4ECFCBCC jmp short loc_4ECFCBDE

.text:4ECFCBCE ; —————————————————————————

.text:4ECFCBCE

.text:4ECFCBCE loc_4ECFCBCE:

.text:4ECFCBCE call GpMalloc(x)

.text:4ECFCBD3 test eax, eax

.text:4ECFCBD5 mov [ebp+lpMem], eax

.text:4ECFCBD8 jz loc_4ECFCCDB

The above code uses the eax register as arguments to the GpMalloc function. GpMalloc is simply a gdi version of heapAlloc function. The value of eax register is based on various floating point calculation that is not simple to examine at first look.

But I traced the value of eax register and it seems the calculations are based on our values mentioned earlear in the file. And it doesn’t bound checked well, by changing the path value tricky it is possible when the “shl eax, 3” instruction multiply the value by 8 we get an integer overflow and in turn a faulty heap allocation.

I dynamically traced the values with my proof of concept file. Eax register is equall to eax + [ebp-38] * 10 and as there are a lot of values and calculations before that, for better consideration I made the following diagram:

It took a lot of time explanation of all of the variables above but, the important one is the GpPath object that is in the code a clone of the object is made to later be manipulated for drawings.

After calling the clone, it checks whether it is a valid clone or not at address 4ECFC9FE.

The offset +34h of the object contains a pointer to our 4byte path object values.

0:000> dd ecx

0e03ca50 4ec67e58 68745031 00000000 00000000

0e03ca60 0e03ca74 0e03ca74 00000010 00000010

0e03ca70 00000002 00000100 00000000 00000000

0e03ca80 00000000 0e03ca98 0e03ca98 00000010

0e03ca90 00000010 00000002 449a8eab 458ac500

0e03caa0 449a8eab 4e0000fe 00000000 00000000

0e03cab0 00000000 00000000 00000000 00000000

0e03cac0 00000000 00000000 00000000 00000000

Our floating point values in the file format:

0e03ca98 449a8eab 458ac500 449a8eab 4e0000fe

0e03caa8 00000000 00000000 00000000 00000000

But there are some modifications on our values before we get the faulty code. First after the clone is performed GpPath::Flatten function made some changes to our values based on a transform matrix in the file. So this is cause of the highlighted 6 DWORDs in the file.­­­

.text:4ECFC9FE call dword ptr [eax+4]

.text:4ECFCA01 test eax, eax

.text:4ECFCA03 jz loc_4ECFCDBA

.text:4ECFCA09 fld ds:flt_4ECB80FC

.text:4ECFCA0F push ecx ; float

.text:4ECFCA10 lea eax, [ebp+var_F8]

.text:4ECFCA16 fstp [esp+108h+var_108]

.text:4ECFCA19 push eax ; int

.text:4ECFCA1A mov ecx, edi

.text:4ECFCA1C call GpPath::Flatten(GpMatrix const *,float)

.text:4ECFCA21 cmp [ebp+var_2C], 0

Flattened GpPath object values:

0:000> dd poi(edi+34)

0e03cd18 449a7eab 458ac100 449a7eab 4e0000fd

0e03cd28 00000000 00000000 00000000 00000000

And after that our changed GpPath object is sent to calculateGradiantArray and some array of floating point values are made based on its calculation.

There are many other default floating point values has effects on the value of the overflowing size for GpMalloc that are not so interesting and I’ve just shown them on the diagram.

After the calculation integer wrapped, the heap allocated by the gpMalloc function is not big enough to hold our data. So in next uses of the wrapped allocated heap the corruption occurs. But it seems there is not a straight way of exploiting such heap corruptions using a standalone file. .

Hello again . as a lot of readers like windows 7 exploits here is other one .

1) Advisory information

Title : Adobe Flash player Action script type confusion

Version : flash10h.dll

Discovery : Malware writers

Exploit : abysssec.com

Vendor : http://www.adobe.com

Impact : Critical

Contact : info [at] abysssec.com

Twitter : @abysssec

CVE : CVE-2010-3654

2) Vulnerable version

Adobe Flash Player 10.1.53 .64 prior versions

3) Vulnerability information

Class

1- Type Confusion

Impact

Successfully exploiting this issue allows remote attackers to execute code under the context of targeted browser.

Remotely Exploitable

Yes

Locally Exploitable

Yes

4) Vulnerability detail

Here we have type confusion vulnerability in ActionScript bytecode language. The cause of these vulnerabilities is because of implementation of verification process in AS3 jit engine that because of some miscalculation in verifying datatype atoms, some data replaces another type of data and the confusion results in faulty machine code.

Action script has the following structure. First our scripts are compiled using an action script compiler like flex to AS3 ByteCodes and embed it to DoABC, DoAction or DoInitAction tags in swf file format. When flash player opens the swf file, bytecodes are compiled to a jitted machine code through verification and generation process. Verification process is responsible for checking bytecodes to be valid instructions and it pass the valid bytecodes to generation process, thus generation process produces the machine code in memory.

According to Dion Blazakis’s JIT Spray paper:

To handle this runtime typing requirement, the ActionScript interpreter represents internal objects using tagged pointers – internal, this object is called an “atom”. Tagged pointers are a common implementation technique to differentiate between those objects stored by value and those stored by reference using the same word sized memory cell. A tagged pointer stores type information in the least significant bits and stores a type specific values in the most significant bits. As shown in Illustration 1, the ActionScript atom is 32 bits wide; it allocates 3 bits to store the type information and uses 29 bits for the value.

So if it would be possible to confuse verifier too act an atom as another atom by some bytecode changes it would be possible to generate faulty code that most of the times lead to disclosing a vtable pointer call to the attacker.

The bug is perfectly presented in Haifei li recent slides. We have OriginalClass and RefClass with the same functions. Func1 – OriginalClass return a class objects, but Func1 – RefClass returns another type. By changing a byte in the bytecode we have confused AS3 to execute RefClass functions in the main class. After that verifier confuses the return type of the function with an OriginalClass object and generate faulty code with the vtable under the control of the return value.

Exploitation:

For exploitation purpose on recent protections on windows 7 without any 3rd party, it is possible to use the same bug many times to leak the imageBase address and payload address. In our exploit we used three confusion to read String Objects address and accordingly imagebase address.

Step1: read shellcode string object pointer by confusing it with uint and use it to leak ImageBase.

Step2: leak address of the shellcode with the same pointer and NewNumber trick.

Step3: send imageBase & shellcode address as parameters to the RopPayload function, develop Rop payload string and again confuse the return value with uint to read address of RopPayload string.

Step4: send address of the rop payload as parameters to the last confused function that confuses string type with class object. And thus address of our rop payload will be used as vtable in the fake class object.

Note: In using strings as a buffer for shellcode in action script, it is important to use alphanumeric characters because the toString method converts our ascii character set to uincode thus make our shellcode unusable.

5) Conclusion

Finally we got the point that memory leakages are extremely useful in modern exploitation to bypass DEP, ASLR protections. It would be possible to find same atom confusion situation and other object leakage in adobe flash player. Kudos to haifei li for his great research, although it was not that simple to implement a reliable exploit with just slides without attending in talk.

we know that there are thousands and millions of online game players around and we guess lots of them may like to cheat this is our totally offensive research that we did to present in immunity infiltrate and as we missed that so here we go .

This research is about hacking /exploiting / cheating in online games and is sponsored by immunity.

This is a six part talk and contains:

Part I : introduction

Part II: Hacking Online Game Servers

Part III: Exploiting Online Games

Part IV: Cheating in Online games

Part V : Creating your own cheats

Part VI: Bypassing anti-cheat engines

Real world cheating is mainly focused on in this talk as it’s fun and legal.
During this talk we will have a tour into all the ways to manipulate an online game
and we will end up with bypassing the latest anti-cheating technologies and
manipulating the game to our heart’s desire.

Our case studies are:

1 -counter strike (half-life) as game:

2- SXE-Injected and Valve-anti cheat (VAC) as anti-cheat engines

Our codes will be release soon as soon we can but if you are hurry to use some cheats you can find almost all necessary codes in slides also there is two demos for proofing our research. We really enjoyed this research and it’s done from our side hope you enjoy too.

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.

Ok fire up the olly and load the target, run the target [F9] and in the main olly open the View > Executable modules and take look at the executed m
You will see the Prog.dll is in the use ok DClick to load the dll in olly

Oki daki the dll loaded into olly, in the CPU view right click under the Search for > All intermodular Calls
Scroll done, remember when u wrote the wrong serial the PE popup the Message box ok

DClick on the MessageBoxA and u going to the refer of message box
Do nothing

There is nothing interesting, not good??

Make olly minimize and u able to see the serialME, input the wrong name and serial again , the message box popup again click on the ok and back to olly

O some line was append, I think those are interesting :) , u can see the wrong serial 123 and right serial beside each other

right click on the serial in olly under copy > to clipboard and paste the code into serialME

and see the right message

that’s it , u fish the serial

see the source of serialME

and the author write his own keygen

see the source of keygen

u need the RadASM to use the source

lets going to the next step

I really enjoy to make the PE work with my serial

In the world of cracking we call this byte patching

Ok lets patch the EXE

Load the dll again into olly like as I say in up

Going to the message lines

And look carefully you will see 1 old friend into the strange PE

That’s right

JNZ

very easy , change the JNZ to JE and u able to register the PE with any serial that u like

it’s been a long time since we wrote our last post’s ?! first of all i should say sorry for late in blog updates but the first reason is we are really busy in these days with accomplish our projects . the second reason was changing our server . and finally the third reason is starting abysssec inc with a professional team for accomplish new projects and services . in soon future we have lots of good news may that’s interest you . so please be patient to see our news on our new index (that come soon as soon possible)

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

today i wanna talk about Microsoft security patch’s analysis . as you know this year and specially last month’s of this year was a nightmare for M$ windows because we saw MS08-067 – MS08-068 – MS08-006 and MS08-001 and etc . and as you know too publishing real and working exploits is going to die and just you can see commercial exploits on time .

i saw this picture in one of Mr Nicolas Waisman presentation and i believe to mind of this picture :

my goal from this introduction is if you want an exploit on publishing time you just have two chose :

1- write your own exploit

2- buy commercial exploit for your requirement vulnerability

- if you are a super millionaire you can buy all commercial exploits from variant security research teams and we are one of them ;)

- and if you are not you and you like and you need an exploit on time you should write your own exploit . and writing exploit for modern operation system’s is not easy because you need bypass a dozen of memory protections (such as DEP / ASLR / SAFSEH / Safe unlinking and etc … (from OS to commercial target software) also i believe this Mr Dave Aitel sentence : Not only are bugs expensive but the techniques for reliably exploiting bugs becomes expensive .

anyway becoming a real exploit coder is not easy but it’s possible and i should quote and notice another sentence that is : Modern Exploits – Do You Still Need To Learn Assembly Language (ASM) ( you can read full post here : (http://www.darknet.org.uk/2008/09/modern-exploits-do-you-still-need-to-learn-assembly-language-asm/)

i,m fully sure learning assembly language will help you in all of exploit development levels from reversing and understanding vulnerability to writing reliable exploit code for modern operation system’s .

after you can understand assembly code you can supposition high level code and thereupon you can identify vulnerability from discrepancy between patched and unpatched binaries (however advanced tools and IDA plugin’s make your life easier and you can identify vulnerable code / function if a few minutes) this technic is called binary diffing. in future i,ll discuss a few advanced trick and methods , that’s improve your speed and analysis but for now i just talk about main of binary diffing on Microsoft security patch’s .

first step is downloading patch from Microsoft . the best way is searching on Microsoft site for your target bulletin . for example see MS08-067 (my favorite bug in this year :D )

just you need click on your target os and download the path.

after you downloaded the patch as you know you should not install the patch and you need extract patch data

with /x command .for example extracting ms08-067 patch :

the output of executing atop command is extract all date inside the patch . and in this example result is :

as you can see in this patch we have just one file and that is a dll named netapi32.dll so we can understand vulnerable function is in this dll .

next step is find vulnerable (unpatched) file (or files) on your system and then you can rename patched file to filename_patched.XXX and then you can analysis and notice changes in patched and unpatched files.

for accomplish this procedure you can use different tools and ways . but using IDA Pro is one of best and logical ways you can use for this procedure . you can understand changes without any plugins and auxiliary tools but for imporving speed and getting better result you have tree choice .

after videos please read following link (a good work from Mr stephen lawler) about full reverse of MS08-067 patch using DiffingSuite and IDA pro cheerfully because it contain divisor of work :

http://www.dontstuffbeansupyournose.com/?p=35

3- using tenable security PatchDiff . PatchDiff is another IDA Pro Plugin (like bindiff) but have a big difference with Bindiff this plugin is free !

you can see a video about this plugin here :

http://cgi.tenablesecurity.com/tenable/pdiff2.swf.html

and you can download this plugin from following link :

http://cgi.tenablesecurity.com/tenable/dl.php?p=patchdiff2-2.0.5.zip

using this plugin is so easy but i discuss a few about this plugin . frist of all you need patched and unpatched binaries after this you just first need open unpatched binary IDA and save disassembly in idb file after that you should open patched binary and save disassembly result to another idb file :

since this you just need open unpatched IDB using plugin to understating discrepancy . after this step as Mr Nicolas Pouvesle (pathdiff plugin author) discussed graph nodes can be synchronized by double clicking on a given node. Graphs use the following colors:

white: identical nodes

grey: unmatched nodes

red: matched nodes

tan: identical nodes (different crc)

for example you see patchdiff result for MS08-067 patch :

and :

if you be smart you can write a high level simulator code for vulnerable function . for example Mr Alexander Sotirov wrote a simulator of vulnerable function :

#include

// This is the decompiled function sub_5B86A51B in netapi32.dll on XP SP3
// and sub_6EA11D4D on Vista SP1

for example Mr stephen lawler wrote a c program for checking MS08-067 vulnerability by taking the offset between sub_7CDDB23D and the load address of NETAPI32.DLL :

#include

#include

int wmain(int argc, wchar_t **argv)

{

HMODULE netapi32 = LoadLibraryW(argv[1]);

void (__stdcall *foo)(PWCHAR);

WCHAR buf[4096];

*(PVOID*)&foo = (PVOID)(((PUCHAR)netapi32) + 0×1b23d);

//__asm { int 3 }

wcscpy(buf, argv[2]);

foo(buf);

wprintf(L”%s\n”, buf);

}

and finnaly he got a crash :

after getting first crash you just need getting eip and write exploit for vulnerability .

finally i should say sorry for disheveled writing . the reason of this is size of this subject in next post i talk directly about patch analysis tricks and i,ll anlysis another interesting Microsoft Patch step by step .