Friday, June 15, 2007

The strange case of Dr.Rootkit and Mr.Adware :)

hi
In the last few years, we’ve seen a dramatic change of infection techniques.
Years ago, malicious programs started as simple file infectors, then progressed
through macro viruses, worms, script viruses, and now we are plagued in
massive numbers by backdoors, trojans, adware, and rootkits.
The skill set needed for writing malware has changed, and so have the goals.
The days when virus writers wrote viruses to show off how good they are at
making malicious programs have gone away, and now all that the virus writers
care about is making money by infecting a lot of computers.
 y using bot trojan horses, an attacker can remotely gain system access. There
are thousands of networks of !ombie computers ” machines infected with
backdoors that are ready to be used for anything the bot controllers desires,
ranging from sending spam emails to performing #estributed #enial of $ervice
%##o$& attacks.
‘ lot of these virus writers are fueled by companies that have poor moral
values and bad advertising campaigns. ‘ company that wants to advertise a
product to a million users by email would need to send out all of those emails
by themselves, which can get their company blacklisted very quickly. Instead,
all they would need to do is pay a virus writer to write a virus that can remotely
infect a computer, turning it into a mail server. (ompanies make millions of
dollars a year due to spam emails.
‘ lot of infections also advertise locally on the user’s computer. )alware is
frequently used to display messages about products on people’s computers by
analy!ing their surving habits and sending the user’s information to the
attackers server.
Terrorists are also using bot networks %botnets& frequently to attack websites.
*or e+ample, someone could digitally hold a company and its website ransom,
forcing them to send money or else the virus writer would start a distributed
denial of service attack. $ome computer terrorists have networks of hundreds
of thousands of computers, making the attacks powerful enough to take down
even the largest corporate servers.
The last weapon in the attacker’s arsenal is the rootkit ” a technique used to
hide the malicious code in an infected computer so that no software can see
them. There are many techniques available to attackers which can hide files
and other components of viruses. )any of these techniques have been
discovered and counter”attacks have been created by antivirus companies,
but, as always, the virus writers are one step ahead and have many ways to
combat even the most powerful antivirus and antirootkit software.
$ome months ago, users started reporting about a rootkit infection that was
totally unknown to antivirus companies. This threat is still emerging and
evolving and is still widely undetected. ,n the following pages, we are going to
analy!e this infection in detail.
link:
Posted by REM in 00:15:09 | Permalink | No Comments »

A Journey to the Center of the Rustock.B Rootkit

hi
This paper is divided into two main parts. In the first part I wanted to
extract the native Rootkit driver code but without the use of kernel
debuggers or other ring0 tools. The second part covers the extraction over
the last three stages but much faster and with lesser efforts using the
SoftICE debugger. Each part shows various possibilities for solving the
different problems facing the researcher when analyzing Rustock. The
techniques can also be useful in future reversing sessions. All the tools
I’ve used can be found in the references. Some of them are free and
others again are commercial, like IDA Pro. Further all the binary dumps
and IDA .idb files from each stage are included in the package with this
paper. Use caution when reproducing the work described here. Consider
employing a virtual machine like VMware or Virtual PC and perform the
analysis on an isolated network to avoid the damage that could be caused
by the Rootkit. Use at your own risk!
link:
note:
plz be cerful this file contains some rootkits for articles……:)
Posted by REM in 00:06:31 | Permalink | No Comments »

Thursday, June 14, 2007

REVERSE CODE ENGINEERING: AN IN-DEPTH ANALYSIS OF THE BAGLE VIRUS

hi
this is nice tutor about REVERSE CODE ENGINEERING.
Today, many anti-virus (AV) scanners primarily detect viruses by looking for simple virus signatures 
within the file being scanned.  The signature of a virus is typically created by disassembling the virus into
assembly code, analyzing it, and then selecting those sections of code that seem to be unique to the virus. 
The binary bits of those unique sections become the signature for the virus.  However, this approach can
be easily subverted by polymorphic viruses, which change their code (and virus signature) every time
they’re run.  In response, AV vendors implemented heuristics and decryption engines that would run the
decryptor/loader code of the binary and peak inside the unencrypted binary to determine if it’s a virus. 
2
However, the fact is that most viruses are of the “simple” type  – not encrypted or polymorphic, and many
of them have many variants that come out afterwards.  
 
We believe that reverse code engineering (RCE) can be used to better analyze viruses and provide us with
better techniques to protect against them and their variants.  This paper examines the benefits of RCE and
how it applies to detecting, preventing, and recovering from a virus.  RCE can be defined as analyzing and
disassembling a software system in order understand its design, components, and inner-workings.  RCE
also allows us to see hidden behaviors that cannot be directly observed by running the virus or those
actions that have yet to be activated.  These benefits can be used to prematurely defeat a virus’s future
variants by better analyzing the original virus.
 
The goal of this project is to try to answer the following three questions:
1.  How do you reverse engineer a virus?
2.  Can reverse engineering a virus lead to better ways of detecting, preventing, and recovering from a
virus and its future variants?
3.  Can reverse engineering be done more efficiently?
 
The virus we chose to examine in this paper is known as Bagle (also known as Beagle).  The reasons for
this will become evident in Section 4.1.  Although Bagle is often classified as a worm by AV vendors, we
refer to it as a virus because it requires human intervention (it’s activated only by the user) to continue its
propagation.  However, it has characteristics of a worm as well; including the ability to spread to other
computers and not needing a host file to attach to.  In the end, it doesn’t matter whether it is referred to
3
as a virus or a worm or just malware .
 
The remainder of this paper is organized into four sections and two appendixes.  Section 2 reviews basic
x86 concepts, including registers, assembly, runtime data structures, and the stack.  Section 3 gives a
brief introduction to viruses, their history, and their types.  Section 4 delves into the Bagle virus
disassembly, including describing the techniques and resources used in this process as well as presenting
a high level functional flow of the virus.  Section 5 presents the conclusions of this research.  Appendix A
provides a detailed disassembly of the Bagle virus, while Appendix B presents the derived source code of
the Bagle virus, as a result of this research.
………
link:
Posted by REM in 23:57:48 | Permalink | No Comments »

Application debugging in a production environment

Application debugging in a production environment

Summary: This document is made for people who have to support and maintain a production environment. Answers are given on questions like: “Yesterday it still worked and now it doesn’t anymore, what did happen?” or “Why does it work on this computer and not on another one?”. Every part of the paper is explained as a walkthrough in order to use it as reference material and/or as a workbook to learn some particular debugging scenarios. (125 printed pages)

This article covers the following topics:
  • Debugging and instrumenting scripts
  • Using tools to do first analysis (FileMon, RegMon, Dependency Walker, …)
  • A step-by-step guide for using the WinDbg debugger
  • Symbol and symbol servers
  • Calling conventions
  • Stack tracing and related subjects
  • Debugging of “free builds”
  • Creation and debugging of “dump files”
  • Working with ILDASM and ILASM
  • Other useful WinDbg extensions
  • Remote debugging
  • Debug scenarios

link:

source:
Posted by REM in 09:09:03 | Permalink | No Comments »

Tuesday, June 12, 2007

Crc32 Reversing

well today I’m gonna teach you *censored*ers an easy way of ‘reversing’ crc32. CRC stands for Cyclic Redundancy Check and 32 the size of the result in bits, 32 bits = 1 dword = 4 bytes. Ok, enough of this crap. My method of finding out the values necessary for resulting in a given crc goes like this:

Let’s suppose we need a sequence of bytes that results in the crc of 0xA02DD7CB. Analysing the crc32 routine:

lea esi, [message]
mov edx, -1
crcloop:
lodsb
mov ecx, edx
and eax, 0ffh
and ecx, 0ffh
xor eax, ecx ; let’s call it X
shr edx, 8
xor edx, dword ptr [eax*4+crctable]
dec contagem
jnz crcloop

We can figure out which value was the last one in X by looking up in the crctable a dword with the highest byte equal to 0xA0, so. eg: 0xA0YYYYYY. Then we save the position of this dword and the rest of the dword, YYYYYY. Why save YYYYYY? because it’s the value that has been XOR’d with another one to result in (A0)2DD7CB. Now we XOR YYYYYY with 2DD7CB. Now we do the mentioned operation till the last byte. Here goes a table of the operations:

__________ __________ __________ ___________
| VALUE | O.DWORD | Position | XOR’ing |
|———-|———-|———-|———–|
| A02DD7CB | A00AE278 | E0 | 002735B3 |
| 2735B300 | 270241AA | 71 | 000037F2 |
| 37F20000 | 37D83BF0 | EB | 0000002A |
| 2A000000 | 2A6F2B94 | FB | 00000000 |
| | | | |
¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯

Ok, so the values we got are the ones that must be the X’s. And, as we did this process backwards, we need to put the result backwards as well, so our values are 0xFB, 0xEB, 0×71 and 0xE0 So, we just need to recode a crc32 routine to retrieve the chars to be xored with the current crc in order to result the X’s and also replace them in execution so we can keep processing good values. Here it goes:

invoke lstrlen, addr message
mov contagem, eax
lea esi, [message]
lea edi, [temporary]
mov edx, -1
crcloop:
lodsb
mov ecx, edx
and eax, 0ffh
and ecx, 0ffh
xor eax, ecx
cmp contagem, 4
jg skipitt
stosb
mov al, byte ptr [esi-1]
skipitt:
shr edx, 8
xor edx, dword ptr [eax*4+crctable]
dec contagem
jnz crcloop

; Notes:
; message db 0FBh, 0EBh, 71h, 0E0h ; our precious values
; temporary dd 00 ; buffer for the last 4 bytes

After executing this routine we find out that the needed four bytes are ‘fuss’ (this is only when there’s nothing before it. If there are bytes before it then it’s probably gonna change ;).

So, as you can see it’s rather easy to reverse crc32. If you didn’t understand this tutorial, just cont… .. .no if you didn’t, you’re such a moronic dumbass…

See ya,
fusS

Posted by REM in 22:57:52 | Permalink | No Comments »

Replacing windows system files

Intro:
You all probably know about the windows file protection? No? Let me explain. The files in the directory system32(or system) are critical for windows. Therefore, windows has it own file protection system managed by sfc.exe. (Start -> Run -> cmd.exe -> sfc.exe and you see its parameters). This file is activate during windows. It checks if the files are the original ones, otherwise, the not original files get replaced by the original ones.

SFC scans the filetimes (creation and last modification time) and the file its size to check for originality. SFC does not check for actually changed (patched) bytes. I will describe two ways to get around this problem so you can replace the files with your patched ones.


Figure 1. Showing the parameters of SFC

First option:
You can disable this file its purpose by changing the CACHSIZE to 0. And then PURGECACHE so it has no files in his memory anymore so it can not copy the good files over the bad files anymore when it runs into a wrong file in the system dirs. So by doing this (first reboot after the modifications) you can copy modified files to the system dirs, replacing the originals. For example you have patched taskmgr.exe so it quits right away, and you have copied it to the systemdir so the CTRL ALT DEL will not pop up taskmgr.exe

Second option:
The second way, without disabling SFC is coding a little program. I have made a very simple application, its all API wrapping. See the download below. The app gets the filetime of the file to be replaced, then the app replaces the original file with the one specified and sets the new filetime of the copied file to the original filetime attained earlier.

Advantages & Disadvantages:
When you want to play around with your own system and you have internet connection and you are using the current windows installation for other things then messing around with Windows, it is dangerous to totally disable SFC. Because malicious programs can also easily replace the system files. On remote computers this maybe doesn’t matter. Another thing to consider is that the file size of the not original file must be exactly the same as the original one or else it gets replaced again by the original one if you leave SFC on.

Hopefully you have learned something!
Devoney

link:
Posted by REM in 22:53:22 | Permalink | No Comments »

Crypto Keygen Tutorial - MD5

hi
Crypto Keygen Tutorial #1 - MD5
Ziggy, SnD Team 3rd January 2006
This tutorial focuses on typical MD5 registration schemes and how to get started with
keygenning them.
There are not too many good MD5 tutorials around so I had to learn the hard way. I
hope this tutorial helps others learn the basics quickly.
The tutorial assumes you know the basics of cracking and keygenning apps. I haven’t
provided all the details of cracking the target example, so this tutorial isn’t aimed
at beginners.
I’ve used ImToo MPEG Encoder 2.1.55 as an example target app.
link:
Posted by REM in 17:58:03 | Permalink | No Comments »

lena151 nice collection tutor

hi
lena151 is nice women in the reversing engineering world teach u everything about reversing and analyzing anything that is executable !!! :)
this package is:
01. Olly + assembler + patching a basic reverseme
02. Keyfiling the reverseme + assembler
03. Basic nag removal + header problems
04. Basic + aesthetic patching
05. Comparing on changes in cond jumps, animate over/in, breakpoints
06. “The plain stupid patching method”, searching for textstrings
07. Intermediate level patching, Kanal in PEiD
08. Debugging with W32Dasm, RVA, VA and offset, using LordPE as a hexeditor
09. Explaining the Visual Basic concept, introduction to SmartCheck and configuration
10. Continued reversing techniques in VB, use of decompilers and a basic anti-anti-trick
11. Intermediate patching using Olly’s “pane window”
12. Guiding a program by multiple patching.
13. The use of API’s in software, avoiding doublechecking tricks
14. More difficult schemes and an introduction to inline patching
15. How to study behaviour in the code, continued inlining using a pointer
16. Reversing using resources
17. Insights and practice in basic (self)keygenning
18. Diversion code, encryption/decryption, selfmodifying code and polymorphism
19. Debugger detected and anti-anti-techniques
20. Packers and protectors : an introduction  
21. Imports rebuilding
22. API Redirection
23. Stolen bytes 
24. Patching at runtime using loaders from lena151 original 
25. Continued patching at runtime & unpacking armadillo standard protection 
26. Machine specific loaders, unpacking & debugging armadillo 
27. tElock + advanced patching  
28. Bypassing & killing server checks  
29. Killing & inlining a more difficult server check  
30. SFX, Run Trace & more advanced string searching 
31. Delphi in Olly & DeDe
32.  Author tricks, HIEW & approaches in inline patching                                  
33. The FPU, integrity checks & loader versus patcher
34. Reversing  techniques  in packed soft & A S&R loader for aspr 
35. Inlining inside polymorphic code
36. Keygenning
37. Indept  Unpacking  &  Anti-Anti-Debugging  A Combination Packer/Protector
38. Unpacking continued & debugger detection by DLL and TLS
39. Inlining blowfish in a dll + unpacking aspr SKE 2.2
thnax fly to lena151
Posted by REM in 17:39:41 | Permalink | No Comments »

Introducing Encryption and Cryptography

Introducing Encryption and Cryptography

Course Duration: 3:15 Hours

Audience: Any individual with technical security responsibilities, including system/network administrators and security officers/administrators; managers or technical staff who wish to demonstrate a technical understanding of a broad range of security-related issues and technologies

Prerequisites: A basic knowledge of networking internetworking concepts and associated hardware

Course aim: To discuss techniques for encrypting information

Course incorporates: Test, hands-on exercise

Learning Objectives:
- To explain what symmetric and asymmetric encryption are and discuss where they are used
- To discuss practical encryption

link:
pass included to comment :)
Posted by REM in 13:36:42 | Permalink | No Comments »

Inserting a MessageBox

hi
this is nice tut about reversing like  injecting code……
1. Introduction

Ok, here comes the tut about injecting code. We will insert a MessageBox at program start like a little “nagbox”. We will use my little example program in the zip file so I can better explain what we do. Note: it’s important that our target program import the MessageBoxA function! That makes sense cause without it we can’t use it. In this case we have to import it by hand which I will discuss in another tutorial. So check with Wdasm, PEditor, my Import Table Viewer or any other tool that MessageBoxA function is imported.

Tools needed:
PEditor
Hiew and Hex Workshop (I used both)
Opgen (not absolutely necessary)
some knowledge about PE file format and little knowledge of ASM is never wrong!

Last word here: Sorry for my bad English, it’s not my mother tongue! Ok, lets start..

2. What we have to do - some theory

Ok, at first we have a look how the MessageBoxA function looks like: (extract from Win32 Programmer’s Reference)

int MessageBox
( HWND hWnd, // handle of owner window
LPCTSTR lpText, // address of text in message box
LPCTSTR lpCaption, // address of title of message box
UINT uType // style of message box );

hWnd and uType can be zero, but we have to save our caption and our text somewhere in the file. Then we look for a place where we can insert the code for our MessageBox. But what should we do that it will be executed?
We just change the Entrypoint of our file to the postion where we have inserted out MessageBox Code. Right after this, we jump to the original Entrypoint. The Entrypoint is the address where the program starts.

3. Let’s play…

The section table of our file:

Section    Virtual Size    Virtual Offset    Raw Size    Raw Offset    Characteristics
.text      000002B4         00001000         00000400      00000400      60000020
.rdata     000001F2         00002000         00000200      00000800      40000040
.data      0000012C         00003000         00000200      00000A00      C0000040

- the .text section is our code section. Here we’ll insert our MessageBox code. This section starts at offset 400 and is 2B4 bytes long. So we can enter our code from 400 + 2B4 = 6B4. We have space till offset 400 + 400 = 800. This is room for 400 - 2B4 = 14C bytes.
- the .data section is the section where we will put our caption and our text. It starts at offset A00 and is 12C bytes long. So we can enter our cap+text from A00 + 12C = B2C. We have space till offset A00 + 200 = C00. This is room for 200 - 12C = D4 bytes.

We’ll see that this there is enough room in the file. If you don’t find such caves, you have to make a new section… (yeah exactly what my older tut is about :-) )
First, we will enter our caption and our text in the file, more exactly in the .data section at offset B2C.
So start Hex Workshop, open our file, go to offset B2C and enter your text. This is what I have entered:

00000B10 7474 6F6E 0000 0000 0000 0000 0000 0000 tton…………

00000B20 0000 0000 0000 0000 0000 0000 5468 6973 …………This

00000B30 2069 7320 6D79 2063 6F6F 6C20 4D65 7373  is my cool Mess

00000B40 6167 6562 6F78 2100 2D3D 2059 6561 682C agebox!.-= Yeah,

00000B50 2069 7420 776F 726B 7321 2052 6576 6572  it works! Rever

00000B60 7369 6E67 2069 7320 7468 6520 6B65 7920 sing is the key

00000B70 746F 2065 7665 7279 7468 696E 673D 2D00 to everything=-.

00000B80 0000 0000 0000 0000 0000 0000 0000 0000 …………….

Ok, you see that my caption starts at offset B2C and ends at B46. Our text starts at offset B48 and ends at B7F. We need the starting offsets later. It’s important that there is a “00″ after caption and after text! We need also the virtual addresses and they are for B2C = 40312C and for B48 = 403148.
(If you don’t know: The VA (virtual address) is the RVA + imagebase!)

Fine, now we insert our code. But we need some more information. Open PEditor and we see that Entrypoint is 1000 (it’s an RVA and the offset is 400). The last thing we need is the so-called opcode for MessageBox function. To get this opcode we use the little program Opgen by NeuRaL_NoiSE. You can also find it out in WDasm or Hiew by looking a bit around. Ok, the opcode for our MessageBox function in this file is 402018. Now we have everything.

Open Hiew, then open our file. Press 2x return key to view the Asm source. Now let’s go to offset 6B4 (press F5, enter 6B4, press return).
If you know a bit Asm, you know that we have to push all argument in reverse order (first utype, then lpCaption, then lpText, then hWnd) and then call the function. So press F3, then F2 and now enter exactly as I have below (after each line press enter):

push 00
push 0040312C
push 00403148
push 00
call d,[402018]
jmp 400

Now press escape, then F9 to update. Then it looks like the following:

.004012B4: 6A00         push 000
.004012B6: 682C314000   push 00040312C
.004012BB: 6848314000   push 000403148
.004012C0: 6A00         push 000
.004012C2: FF1518204000 call MessageBoxA
.004012C8: E933FDFFFF   jmp .000401000

First we push the last argument which is uType (style). As we said above, this can be zero. Then we push the caption which is at VA 40312C and then our text at VA 403148. The handle can be zero. After that we call with the help of our opcode the MessageBox. Then we jump to the orignal Entrypoint at offset 400 (VA is 401000 as you see).

Must now work, does’t it? NO! One thing we have forgotten…. think a bit… do you know it? Yeah, we haven’t changed the Entrypoint yet. So our program will run as usual cause it does never execute our entered code! Our code begins at offset 6B4, so RVA is 12B4. Open PEditor,change Entrypoint from 00001000 to 000012B4 and hit “Apply changes”.

That’s all. We have inserted a nice nagbox. If we press ok in this box, the program starts as usual! Hope you understand everything! Have fun!
If you have questions, ideas, suggestions, don’t hesitate to mail me!

Sunshine, May 2002
www.sunshine.2kx.de
www.welcome.to/sun-shine   

Posted by REM in 13:06:06 | Permalink | No Comments »