halsten

My very first analysis paper for a malware is finished. The package contains all the information you might need to understand the malware. Be ware that this is the first draft and not the final version yet.

Recently, I been posting about anti-debugging tricks, but I thought I should add them to the one’s already existing in OpenRCE’s  anti-reversing section. Have fun all!

Recently, I have mentioned that one can detect the debugger presence through the DR7 debug register, now we’ll take a look at the DR0 to DR3 debug registers, which contains debug breakpoints.

This technique is one of the few ways to discover debug breakpoints, and it makes it possible to delete them without stopping the application in the debugger.

You can also use the debug registers with x86 processors to determine whether a debugger is active. Debug register 7 (DR7) is the most important one for you in this trick. If there is no debugger in memory, DR7 will be default to 400h. If there is a debugger, it will have a different value.

Note that in order for this to work the code must be ran in Ring-0 mode (VXD/SYS). It’s not hard to switch from Ring-3 to Ring-0 under Windows, but this will be discussed later.

A different technique is to search for the presence of a breakpoint. It’s based on CRC calculation for the particular program and the checks that run during the course of the program. A program’s current CRC is found at the CRC label. The CRC label changes with alterations in the program, and is therefore adjusted after each alteration. This method is even effective against changes performed in memory.

This trick uses the LOCK CMPXCHG8B instruction to make any debugger (SoftICE, OllyDBG, IDA, etc…) detect an error and stop.

The instruction CMPXCHG8B is used for 64−bit values. It compares a value in the EDX:EAX registers with the 64−bit value saved in the address determined by the pointer in the EAX register. If the values are the same, it saves the value from the ECX:EBX registers here, and sets the ZF flag in the flag register. If they do not match, it reads the 64−bit value from the address saved in the EAX register into the EDX:EAX registers, and nulls the ZF flag.

The register that determines the location of the 64−bit value may also be used incorrectly. It is a special instruction that will stop as an error if any debugger is active, because it doesn’t handle this instruction correctly. There are several possibilities for the instruction LOCK CMPXCHG8B.

If a program is running without the debugger, it will encounter this incorrect instruction and will continue to run by the essence of its SEH service. However, if that same program is ran together with the debugger, it will stop at the incorrect function.

Eventually, most attackers will be just happy with removing the instruction, to let the program run on smoothly. So, one can only take advantage of the fact that the code that follows LOCK CMPXCHG8B EAX will only run if the instruction was removed or jumped over. Which means that someone had tried to change the program code.

Recently I been playing around with some anti-debugging tricks. Most of them have showed some effective results. I’ll post more news about them once I get finished.

Recently I was given a problem to solve, which was a marble problem. A Marble Game is played with M marbles on a square board. The board is divided into NxN unit squares, and M of those unit squares contain holes. Marbles and holes are numbered from 1 to M. The goal of the Marble game is to roll each marble into the hole that has the same number.

A game board may contain walls. Each wall is one unit long and stands between two adjacent unit squares. Two squares are considered adjacent if and only if they share a side.

At the beginning of the game, all marbles are placed on the board, each in a different square. A “move” consists of slightly lifting a side of the game board. Then all marbles on the board roll downward toward the opposite side, each one rolling until it meets a wall or drops into an empty hole, or until the next square is already occupied by another marble. Marbles roll subject to the following restrictions:

• Marbles cannot jump over walls, other marbles, or empty holes.
• Marbles cannot leave the board. (The edge of the board is a wall.)
• A unit square can contain at most a single marble at any one time.
• When a marble moves into a square with a hole, the marble drops into that hole. The hole is then filled, and other marbles can subsequently roll over the hole. A marble in a hole can never leave that hole.

The game is over when each marble has dropped into a hole with the corresponding number.

The figure below illustrates a solution for a game played on a 4×4 board with three blue marbles, three holes and a wall. The solution has five moves: lift the east side, lift the north side, lift the south side, lift the west side, lift the north side.

Your program should determine the fewest number of moves to drop all the marbles into the correct holes – if such a move sequence is possible.

Okay, here is a snippet of assembly code of how to get a pointer to kernel32.dll, I’ll assume that you have some basic knowledge about the following topics:

• Assembly Programming Language
• Stack
• Debugging

Okay, so here is a very interesting thing; the kernel’s entry-point. I’ve disassembled it and translated the assembly listing into a pseudo like readable C code.

I apologize for the sloppy look of the code, but it’s quiet primitive to write code in here. Anyways, the previous snippet of code was from the entry-point “KiSystemStartup”; taken from ntoskrl. I have wrote some of the calls that are called from within the boundries of the function and as you can see they are all based on initialization. You can read all about it in the paper that I’ve written which is “A Technical Thorough View over Windows XP’s Kernel (x86)”. The website will be up very soon.