Moving the view of the Stage
When the Stage is magnified, you may not be able to see all of it. The Hand tool lets you move
the Stage to change the view without having to change the magnification.
To move the Stage view:
1 In the toolbox, select the Hand tool. To temporarily switch between another tool and the
Hand tool, hold down the Spacebar and click the tool in the toolbox.
2 Drag the Stage.
Using the grid, guides, and rulers
Flash comes with rulers and guides that help you draw and lay out objects precisely. You can place
guides in a document and snap objects to those guides, or turn on the grid and snap objects to it.
Using the grid
When the grid is displayed in a document, it appears as a set of lines behind the artwork in all
scenes. You can snap objects to the grid, and you can modify the grid size and grid line color.
To display or hide the drawing grid:
Choose View > Grid > Show Grid.
To turn snapping to grid lines on or off:
Choose View > Grid > Snap to Grid.
To set grid preferences:
1 Choose View > Grid > Edit Grid.
2 For Color, click the triangle in the color box and select a grid line color from the palette.
The default grid line color is gray.
3 Select or deselect Show Grid to display or hide the grid.
4 Select or deselect Snap to Grid to turn snapping to grid lines on or off.
5 For grid spacing, enter values in the text boxes to the right of the horizontal and vertical arrows.
6 For Snap Accuracy, select an option from the pop-up menu.
7 If you want to save the current settings as the default, click Save Default.
Using guides
You can drag horizontal and vertical guides from the rulers onto the Stage when the rulers are
displayed. You can move guides, lock guides, hide guides, and remove guides. You can also snap
objects to guides, and change guide color and snap tolerance (how close objects must be to snap
to a guide). Draggable guides appear only in the Timeline in which they were created.
To create custom guides or irregular guides, you use guide layers. See “Using guide layers” on =
To display or hide the drawing guides:
Choose View > Guides > Show Guides.
Note: If the grid is visible and Snap to Grid is turned on when you create guides, guides will snap to the grid.
To turn snapping to guides on or off:
Choose View > Guides > Snap to Guides.
Note: Snapping to guides takes precedence over snapping to the grid in places where guides fall between grid lines.
To move a guide:
Use the Arrow tool to drag the guide.
Working in Flash 21
To remove a guide:
With guides unlocked, use the Arrow tool to drag the guide to the horizontal or vertical ruler. For
information on locking and unlocking guides, see the following procedure.
To set guide preferences:
1 Choose View > Guides > Edit Guides.
2 For Color, click the triangle in the color box and select a guide line color from the palette.
The default guide color is green.
3 Select or deselect Show Guides to display or hide guides.
4 Select or deselect Snap to Guides to turn snapping to guides on or off.
5 Select or deselect Lock Guides to lock or unlock guides.
6 For Snap Accuracy, select an option from the pop-up menu.
7 If you want to remove all guides, click Clear All.
Note: Clear All removes all guides from the current scene.
8 If you want to save the current settings as the default, click Save Default.
Using rulers
When rulers are displayed, they appear along the top and left sides of the document. You can
change the unit of measure used in the rulers from the default of pixels. When you move an
element on the Stage with the rulers displayed, lines indicating the element’s dimensions appear
on the rulers.
To display or hide rulers:
Choose View > Rulers.
To specify the rulers’ unit of measure for a document:
Choose Modify > Document, and then select an option from the pop-up menu at the upper right.
Creating a new document
Each time you open Flash, the application creates a new file with the FLA extension. You can
create additional new Flash documents as you work. To set the size, frame rate, background color,
and other properties of a new document, you use the Document Properties dialog box.
You can also open a template as a new document. You can choose from standard templates that
ship with Flash, or open a template you have saved previously. For information on saving a
document file as a template, see “Saving Flash documents”.
To create a new document and set its properties:
1 Choose File > New.
2 Choose Modify > Document.
The Document Properties dialog box appears.
22 Chapter 1
3 For Frame Rate, enter the number of animation frames to be displayed every second. For
most computer-displayed animations, especially those playing from a Web site, 8 fps (frames
per second) to 12 fps is sufficient. (12 fps is the default frame rate.)
4 For Dimensions, do one of the following:
• To specify the Stage size in pixels, enter values in the Width and Height text boxes.
The default movie size is 550 x 400 pixels. The minimum size is 1 x 1 pixels; the maximum is
2880 x 2880 pixels.
• To set the Stage size so that there is equal space around the content on all sides, click the
Contents button to the right of Match. To minimize movie size, align all elements to the upper
left corner of the Stage, and then click Contents.
• To set the Stage size to the maximum available print area, click Printer. This area is determined
by the paper size minus the current margin selected in the Margins area of the Page Setup
dialog box (Windows) or the Print Margins dialog box (Macintosh).
• To set the Stage size to the default size, click Default.
5 To set the background color of your movie, click the triangle in the Background Color box and
select a color from the palette.
6 To specify the unit of measure for rulers that you can display along the top and side of the
application window, select an option from the pop-up menu in the upper right. See “Using
rulers” on page 21. (This setting also determines the units used in the Info panel.)
7 Do one of the following:
• To make the new settings the default properties for your new document only, click OK.
• To make these settings the default properties for all new documents, click Make Default.
To open a template as a new document:
1 Choose File > New from Template.
2 In the New Document dialog box, select a category from the Category list, and select a
document from the Category Items list.
3 Click OK.
Setting preferences in Flash
Flash lets you set preferences for general application operations, editing operations, and
Clipboard operations. See also “Choosing drawing settings”\.
To set preferences:
1 Choose Edit > Preferences.
2 Click the General, Editing, Clipboard, Warning, or ActionScript Editor tab, and choose from the
respective options as described in the procedures that follow. For more information on
ActionScript Editor preferences, see “Setting Actions panel preferences” under Help > Using
Flash.
Working in Flash 23
To set general preferences, choose from the following options:
• For Undo Levels, enter a value from 0 to 200 to set the number of undo/redo levels. Undo
levels require memory; the more undo levels you use, the more system memory is taken up.
The default is 100.
• For Printing Options (Windows only), select Disable PostScript to disable PostScript
output when printing to a PostScript printer. By default, this option is deselected. Select this
option if you have problems printing to a PostScript printer, but keep in mind that this will
slow down printing.
• For Selection Options, select or deselect Shift Select to control how Flash handles selection of
multiple elements. When Shift Select is off, clicking additional elements adds them to the
current selection. When Shift Select is on, clicking additional elements deselects other
elements unless you hold down the Shift key.
• Select Show Tooltips to display tooltips when the pointer pauses over a control. Deselect this
option if you don’t want to see the tooltips.
• For Timeline Options, select Disable Timeline Docking to keep the Timeline from attaching
itself to the application window once it has been separated into its own window. For more
information, see “Using the Timeline”
• Select Span Based Selection to use span-based selection in the Timeline, rather than the default
frame-based selection (Flash 5 used span-based selection). For more information on span-based
and frame-based selection, see “Working with frames in the Timeline”
• Select Named Anchor on Scenes to have Flash make the first frame of each scene in a movie a
named anchor. Named anchors let you use the Forward and Back buttons in a browser to jump
from scene to scene in a movie. For more information, see “Using named anchors”
• For Highlight Color, select Use This Color and select a color from the palette, or select Use
Layer Color to use the current layer’s outline color.
• For Font Mapping Default, select a font to use when substituting missing fonts in movies you
open in Flash. See “Substituting missing fonts”.
To set editing preferences, choose from the following options:
• For Pen Tool options, see “Setting Pen tool preferences” .
• For Vertical Text options, select Default Text Orientation to make the default orientation of
text vertical, which is useful for some Asian language fonts. By default, this option is
deselected.
• Select Right to Left Text Flow to reverse the default text display direction. This option is
deselected by default.
• Select No Kerning to turn off kerning for vertical text. This option is deselected by default, but
is useful to improve spacing for some fonts that use kerning tables.
• For Drawing Settings, see “Choosing drawing settings”
To set Clipboard preferences, choose from the following options:
• For Bitmaps (Windows only), select options for Color Depth and Resolution to specify these
parameters for bitmaps copied to the Clipboard. Select Smooth to apply anti-aliasing. Enter a
value in the Size Limit text box to specify the amount of RAM that is used when placing a
bitmap image on the Clipboard. Increase this value when working with large or
high-resolution bitmap images. If your computer has limited memory, choose None.
• For Gradients (Windows only), choose an option to specify the quality of gradient fills placed
in the Windows Metafile. Choosing a higher quality increases the time required to copy
artwork. Use this setting to specify gradient quality when pasting items to a location outside of
Flash. When you are pasting within Flash, the full gradient quality of the copied data is
preserved regardless of the Gradients on Clipboard setting.
• For PICT Settings (Macintosh only), for Type, select Objects to preserve data copied to the
Clipboard as vector artwork, or select one of the bitmap formats to convert the copied artwork
to a bitmap. Enter a value for Resolution. Select Include PostScript to include PostScript data.
For Gradients, choose an option to specify gradient quality in the PICT. Choosing a higher
quality increases the time required to copy artwork. Use the Gradients setting to specify
gradient quality when pasting items to a location outside of Flash. When you are pasting within
Flash, the full gradient quality of the copied data is preserved regardless of the Gradient setting.
• For FreeHand Text, select Maintain Text as Blocks to keep text editable in a pasted FreeHand file.
To set warning preferences, choose one of the following options:
• Select Warn on Save for Macromedia Flash 5 Compatibility to have Flash warn you when you
try to save documents with Flash MX–specific content to a Flash 5 file. This option is selected
by default.
• Select Warn on Missing Fonts to have Flash warn you when you open a Flash document that
uses fonts that are not installed on your computer. This option is selected by default.
• Select Warn on Loss of Expert Mode Formatting to have Flash warn you of any expert mode
formatting that will be lost when you switch to normal mode in the Actions panel. This option
is selected by default.
• Select Warn on Reading Generator Content to have Flash display a red “X” over any Generator
objects, as a reminder that Generator objects are not supported in Flash MX.
• Select Warn on Inserting Frames when Importing Content to have Flash alert you when it
inserts frames in your document to accommodate audio or video files that you import.
Friday, June 18, 2010
Thursday, June 17, 2010
Viral operations
Viral operations
Although the "original" definition of computer viral programs
refers to reproduction by attaching to other programs, viri that
act in this manner having been less successful than those that
use other means. In the personal computer world, boot sector
infectors have been much more effective. (Examples in the
MS-DOS community are the BRAIN and Stoned viral programs.
Examples in the Mac realm are not as clear, but the WDEF virus
could be said to be a type of boot sector infector, as the WDEF
resource is one that is run automatically as soon as any Mac
disk is inserted, although this has changed under System 7.)
In larger systems, mini and mainframe computers, network and
mail viral programs have, so far, had the greatest impact. The
Morris/Internet/UNIX worm managed to spread and reproduce using
the facility of networked machines to submit programs to each
other. (A VMS program, WANK, used many of the same techniques.)
The CHRISTMA EXEC used mainframe mail commands, and the ability
to submit programs by mail, in order to reproduce copies which
eventually flooded the network.
Network and mail viral programs carry, in a sense, their own
payload. The reproduction of the programs themselves uses the
resources of the hosts affected, and in the cases of both the
Morris and CHRISTMA worms went so far as to deny service to
users by using all available computing or communications
resources.
Most other viral programs seem to be written "for their own
sake". A kind of electronic graffiti which writes itself on
further walls. However, even these can do damage, as with the
Stoned virus, which overwrites sections of the FAT with the
original boot sector. Some appear to be written as pranks, and
others as a kind of advertising, although the potential for
damage from even "benign" viri cannot be considered funny, and
the "advertising" viri probably don't engender much goodwill.
Relatively few viral programs carry a deliberately damaging
payload. Those which do attempt to erase infected programs or
disks are, fortunately, self limiting.
The last payload, or function, which a viral program may carry,
is some kind of intelligence to enable it to evade detection.
So far the various kinds of evasive action; self-modification,
multiple encryption and "stealth" activity; have not proven to
have any advantageous "survival" characteristics. In one sense,
this is to be regretted, as it demonstrates that the majority of
computer users are not taking the most elementary precautions to
defend against viral programs.
Although the "original" definition of computer viral programs
refers to reproduction by attaching to other programs, viri that
act in this manner having been less successful than those that
use other means. In the personal computer world, boot sector
infectors have been much more effective. (Examples in the
MS-DOS community are the BRAIN and Stoned viral programs.
Examples in the Mac realm are not as clear, but the WDEF virus
could be said to be a type of boot sector infector, as the WDEF
resource is one that is run automatically as soon as any Mac
disk is inserted, although this has changed under System 7.)
In larger systems, mini and mainframe computers, network and
mail viral programs have, so far, had the greatest impact. The
Morris/Internet/UNIX worm managed to spread and reproduce using
the facility of networked machines to submit programs to each
other. (A VMS program, WANK, used many of the same techniques.)
The CHRISTMA EXEC used mainframe mail commands, and the ability
to submit programs by mail, in order to reproduce copies which
eventually flooded the network.
Network and mail viral programs carry, in a sense, their own
payload. The reproduction of the programs themselves uses the
resources of the hosts affected, and in the cases of both the
Morris and CHRISTMA worms went so far as to deny service to
users by using all available computing or communications
resources.
Most other viral programs seem to be written "for their own
sake". A kind of electronic graffiti which writes itself on
further walls. However, even these can do damage, as with the
Stoned virus, which overwrites sections of the FAT with the
original boot sector. Some appear to be written as pranks, and
others as a kind of advertising, although the potential for
damage from even "benign" viri cannot be considered funny, and
the "advertising" viri probably don't engender much goodwill.
Relatively few viral programs carry a deliberately damaging
payload. Those which do attempt to erase infected programs or
disks are, fortunately, self limiting.
The last payload, or function, which a viral program may carry,
is some kind of intelligence to enable it to evade detection.
So far the various kinds of evasive action; self-modification,
multiple encryption and "stealth" activity; have not proven to
have any advantageous "survival" characteristics. In one sense,
this is to be regretted, as it demonstrates that the majority of
computer users are not taking the most elementary precautions to
defend against viral programs.
Viral activation
Viral activation
In attempting to protect against viral infection, and
particularly when trying to disinfect systems, it is important to
bear in mind the times that the virus is actively "infectious".
The viral activation is not the same as the activation of the
payload that a virus may carry. For example, the payload of the
original "Stoned" virus was a message which appeared on the
screen saying "Your PC is now Stoned!". This message only
appears at boot time, and on only one eighth of the times the
computer is rebooted. The virus, however, is infectious at all
times, if it has infected the hard disk.
There are basically three possibilities for the infectious
period: now ("one-shot"), during program run ("while called") or
from now on (resident). These periods may be modified by other
circumstances. A resident virus may remain in memory, but only
be actively infecting when a disk is accessed. A "while called"
virus may only infect a new program when a directory is changed.
"One-shot" viri only get one chance on each "run" of the infected
program. The viral code will seek out and infect a target
program. They then pass control to the original program, and
perform no further functions. These are, of course, the simplest
of the viral programs. Mainframe "mail" viri are generally of
this type.
The second class will activate when the infected program is
called, and then pass partial control to the original program.
The virus, however, will remain operational during the time that
the infected program is running. If this can be accomplished, it
is only a slight jump to write a fully memory resident virus.
Resident viri are the most successful, and the most dangerous, of
viral programs. A resident virus will become active when an
infected program is run (or at boot time for boot sector
infectors), and remain active until the computer is rebooted or
turned off. (Some viral programs are even able to trap the
rebooting sequence that is normally called when you press Ctrl-
Alt-Del on an MS-DOS PC, and thus are able to survive a "warm
boot.") The most successful of the file infectors, the Jerusalem
virus, is resident, as are all boot sector infectors. (For
fairly obvious reasons; the boot sector is never "called" in
normal operation.)
If a virus is active in memory, it is a waste of time trying to
disinfect a file or disk. No sooner is the file "cleaned", than
it becomes a suitable target for re-infection. You may try to
disinfect a hard disk right down to performing a low level
format: as soon as the disk is reformatted it may be infected all
over again. This is why all directions for disinfection stress
the necessity of "cold" booting from a disk that is known to be
free of infection before attempting any cleanup.
In attempting to protect against viral infection, and
particularly when trying to disinfect systems, it is important to
bear in mind the times that the virus is actively "infectious".
The viral activation is not the same as the activation of the
payload that a virus may carry. For example, the payload of the
original "Stoned" virus was a message which appeared on the
screen saying "Your PC is now Stoned!". This message only
appears at boot time, and on only one eighth of the times the
computer is rebooted. The virus, however, is infectious at all
times, if it has infected the hard disk.
There are basically three possibilities for the infectious
period: now ("one-shot"), during program run ("while called") or
from now on (resident). These periods may be modified by other
circumstances. A resident virus may remain in memory, but only
be actively infecting when a disk is accessed. A "while called"
virus may only infect a new program when a directory is changed.
"One-shot" viri only get one chance on each "run" of the infected
program. The viral code will seek out and infect a target
program. They then pass control to the original program, and
perform no further functions. These are, of course, the simplest
of the viral programs. Mainframe "mail" viri are generally of
this type.
The second class will activate when the infected program is
called, and then pass partial control to the original program.
The virus, however, will remain operational during the time that
the infected program is running. If this can be accomplished, it
is only a slight jump to write a fully memory resident virus.
Resident viri are the most successful, and the most dangerous, of
viral programs. A resident virus will become active when an
infected program is run (or at boot time for boot sector
infectors), and remain active until the computer is rebooted or
turned off. (Some viral programs are even able to trap the
rebooting sequence that is normally called when you press Ctrl-
Alt-Del on an MS-DOS PC, and thus are able to survive a "warm
boot.") The most successful of the file infectors, the Jerusalem
virus, is resident, as are all boot sector infectors. (For
fairly obvious reasons; the boot sector is never "called" in
normal operation.)
If a virus is active in memory, it is a waste of time trying to
disinfect a file or disk. No sooner is the file "cleaned", than
it becomes a suitable target for re-infection. You may try to
disinfect a hard disk right down to performing a low level
format: as soon as the disk is reformatted it may be infected all
over again. This is why all directions for disinfection stress
the necessity of "cold" booting from a disk that is known to be
free of infection before attempting any cleanup.
Anti-debugging and Anti-emulation Techniques (part 2)
2.3 Overextending the emulator
Overextending the emulator is defined as executing a set of instructions that will cause the emulator to crash or that may indicate that an emulator is running. Calling undocumented instructions that an emulator may not support is one way to cause the emulator to throw an exception and stop running. One such example is the undocumented CPU Instruction SALC that is used in W95/Vulcano [9]. Another way to detect emulation or to crash the emulator currently running, if there is one, is to try to access large portions of memory at once [1]. This is usually not effective though because most operating systems, as well as emulators, will impede the program.
A way to detect whether an emulator is running is to call a function twice that should return two different values. An example of this would be calling any of the time functions twice, and verifying that there is a difference between two return values. In Windows this can be achieved through kernel32!QueryPerformanceCounter which wraps ZwQueryPerformaceCounter, kernel32!GetTickCounter, or by querying the current number of CPU cycles executed since the machine started using the RDTSC (read time stamp counter) instruction. An example of the latter is below [15].
push offset handler
push dword ptr fs:[0]
mov fs:[0],esp
rdtsc
push eax
xor eax, eax
div eax ;trigger exception
rdtsc
sub eax, [esp] ;ticks delta
add esp, 4
pop fs:[0]
add esp, 4
cmp eax, 10000h ;threshold
jb @not_debugged
@debugged:
...
@not_debugged:
...
handler:
mov ecx, [esp+0Ch]
add dword ptr [ecx+0B8h], 2 ;skip div
xor eax, eax
ret
The example above shows how the RDTSC instruction can be used to detect whether a debugger is present. In this case, RDTSC is called twice and the difference of the two values returned is found. This difference is then compared to a threshold (in this example it is 10000h). If the difference is greater, than a debugger is present and a jump away from the malicious code is executed.
Importing obscure libraries may not actually cause the emulator to stop running, but if the library is not imported, the malware code itself may not run.
Malware can also look for webpages to see if it has access to the internet. This is something that can also cause the virus code to not execute on a machine that is not currently connected to the internet, but also stops execution when an emulator is running since most emulators do not allow internet access [1].
Using coprocessor FPU instructions is another way to overextend the emulator because most emulators do not emulate the FPU instructions. Prizzy polymorphic engine (PPE) can generate 43 different coprocessor instructions for the use of its polymorphic decryptor. If these FPU instructions are not provided, the decryption on Prizzy does not execute.
Along the same lines, malware can use MMX instructions. This instruction set adds 8 new registers to the architecture. The malware will check to see if MMX support exists by using the CPUID instruction. Examples of malware that use this technique are W32/Legacy and W32/Thorin.
Malware will also setup an exception handler, execute a garbage block of code, and then indirectly execute its own handler to transfer control to another part of the polymorphic decryptor. This is done in hopes that the emulator cannot handle the exception [9]. An example that is similar to this technique is shown in section 3.7.
3. Anti-debugging
Anti-debugging techniques are usually any attempt of the malware to monitor its own code to detect debugging. To do this, the malware can examine its own code for breakpoints or check for a debugger directly through system calls.
3.1 Breakpoints
To examine its code for breakpoints, the malware can look for the 0xcc opcode instruction, which raises a SIGTRAP. This is the instruction the debugger will use to gain control from the malware at a breakpoint. The malware can also set false breakpoints if the malware code itself has a signal handler. This way it can continue to execute instructions after the breakpoint that it set.
Malware can also try to overwrite the breakpoints. W95/Marburg virus uses a backwards decryption loop for the virus to overwrite the breakpoint. The viruses in the Yankee_doodle family, on the other hand, use hamming code to self correct their code. Hamming code allows programs to detect and correct errors, but in this case allows the virus to detect and remove breakpoints in its code [9].
3.2 Calculating the checksum
Malware can also checksum its own code. If the checksum has changed, then the virus can assume that it is being debugged and there have been breakpoints placed within the code [3]. VAMPiRE is an anti-anti debugging tool that gets around the detection of breakpoints [12]. VaMPiRE accomplishes this by keeping a table of breakpoints in memory to maintain a list of the breakpoints that have been set. The program consists of a page-fault handler (PFH), a general protection fault handler (GPFH), a single-step handler and a framework API. When a breakpoint is triggered either the PFH (handles breakpoints set on code, data, or memory mapped I/O) or the GPFH (handles legacy I/O breakpoints) receives control. The single-step handler is used for breakpoint persistence, allowing breakpoints to be used more than once.
3.3 Detecting the debugger
A very simple way of detecting a debugger on a Linux system is to simply call Ptrace, since Ptrace can’t be called in succession more than once for a specific process [3]. In Windows, the system call isDebuggerPresent will return 1 if the program is being debugged and 0 otherwise. This system call simply checks a flag that has been set by the debugger if it is running. This check can be done directly by checking the second byte in the Process Environment Block. The following code is an example of this technique.
mov eax, fs:[30h]
move eax, byte [eax+2]
test eax, eax
jne @DdebuggerDetected
As the above example shows, eax is set to the PEB (Process Environment Block) and the second byte of that block is then accessed and the contents moved into eax. A check is done to see whether eax is zero. If it is, then there is no debugger present, if not, then there is a debugger.
When a process is created with a debugger already running, the system sets certain flags for the heap manipulation routines in the Windows dll ntdll.dll. These flags are FLG_HEAP_ENABLE_TAIL_CHECK, FLG_HEAP_ENABLE_FREE_CHECK, and FLG_HEAP_VALIDATE_PARAMETERS. These flags can be checked using the following code:
mov eax, fs:[30h]
mov eax, [eax+68h]
and eax, 0x70
test eax, eax
jne @DebuggerDetected
In the above example, we again access the PEB and then get the start of the flags for the heap manipulation routine by adding 68h as an offset to the address of the PEB. The flags are then checked to see if a debugger is present.
Checking flags within heap headers such as the ForceFlags is another way to detect whether a debugger is running or not. Here is an example [15]:
mov eax, fs:[30h]
mov eax, [eax+18h] ;process heap
mov eax, [eax+10h] ;heap flags
test eax, eax
jne @DebuggerDetected
The above example shows how the process heap and the heap flags can be accessed from the offset of the PEB. These are then tested to see if the Force Flags were previously set by a debugger currently running.
Another possible way to detect the debugger is through the use of the NtQueryInformationProcess syscall. This function can be called with ProcessInformationClass set to 7, which refers to the ProcessDebugPort, and the function will return -1 if the process is being debugged. Below is an example [15].
push 0
push 4
push offset isdebugged
push 7 ;ProcessDebugPort
push -1
call NtQueryInformationProcess
test eax, eax
jne @ExitError
cmp isdebugged, 0
jne @DebuggerDetected
In this example, the parameters for the NtQueryInformationProcess syscall are first pushed onto the stack. These parameters are as follows: the first is the handle (in this case 0), the second is the process information length (4 bytes in this example), the following is the process information class (in this case 7, specifying the ProcessDebugPort), the next is the variable used to return whether or not there is a debugger present. If this value is non-zero then the process is being run under a debugger. If not, then all is well. The last parameter is the return length. NtQueryInformationProcess is then called with these parameters and a return value is placed in isdebugged. This is later tested to see if it equals zero, or not.
Other simple ways of detecting the debugger is by checking to see if the device list contains the name of a debugger, by checking the registry keys for a debugger, or by scanning memory to detect the debugger’s code in memory [9].
Another method, similar to the EPO method, is to instruct the PE loader that the entry point of the program is referenced in the Thread Local Storage (TLS) entry in the PE header. This has the effect of causing the code in the TLS to execute first instead of the read entry point of the program. Therefore, the TLS can perform anti-debugging checks before the program even starts [15]. Starting on the TLS also allows the virus to begin execution before the debugger starts, since some debuggers break on the main entry point of the program [9].
3.4 Checking for single stepping
Other ways that the malware can detect a debugger is to check for single stepping. Checking for single stepping can be done by adding a value above the stack pointer and then checking to see if the value is still there. If the value is there, this means that the code is being single stepped. When a debugger is single stepping a process, it will push instructions onto the stack when it takes control and pop them back off the stack before it executes the next instruction. So if the value is still there that means that something other than the running process has been using the stack [1]. Below is a code example of how malware can detect single stepping by using the stack state [9]:
mov bp, sp ; pick stack pointer
push ax ; store any ax mark on the stack
pop ax ; pick the value from the stack
cmp word ptr [bp-2], ax ; compare against stack
jne debug ; if different, debugger detected.
As the comments in this example show, a value is pushed onto the stack then popped off the stack. If the debugger is present, then the value at the top of the stack pointer – 2 will be different than the value that was just popped off the stack and the appropriate action can be taken.
3.5 Checking for slowdown in runtime
By looking for slowdown in the runtime of the program, malicious code can also detect a debugger. A significant slowdown in runtime likely means that the code is being single stepped. So if the difference in the timestamp for 2 different calls is too great, the malware can act accordingly [1]. LTTng/LTTV Linux Trace Toolkit gets around the slowdown problem to trace a virus. This is because LTTng/LTTV is a modular tool that traces the program without adding breakpoints or performing any analysis at the time of execution. It also uses a lockless re-entry mechanism, meaning that it does not lock any portions of the Linux kernel code that the program being traced might need to use, and therefore does not cause the traced program to slow down and wait [4].
3.6 Instruction prefetching
If the malicious code modifies the next instruction in a sequence and the new instruction is executed, then a debugger is running. This is due to instruction prefetching; if the new instruction is prefetched, this means there was a break in the execution of the process. Otherwise the original instruction would have been prefetched and executed [1].
3.7 Self modifying code
The malware can also self-modify other code. One example of this is HDSpoof. This malware starts out with exception handlers and then removes them during execution. That way, if anything goes wrong and an exception is thrown by the process during execution, the virus will terminate. It also modifies the exception handlers at other times during execution by either removing or adding exception handlers. Below is an example of HDSpoof removing all exception handlers except for the default one [7].
exception handlers before:
0x77f79bb8 ntdll.dll:executehandler2@20 + 0x003a
0x0041adc9 hdspoof.exe+0x0001adc9
0x77e94809 __except_handler3
exception handlers after:
0x77e94809 __except_handler3
0x41b770: 8b44240c mov eax,dword ptr [esp+0xc]
0x41b774: 33c9 xor ecx,ecx
0x41b776: 334804 xor ecx,dword ptr [eax+0x4]
0x41b779: 334808 xor ecx,dword ptr [eax+0x8]
0x41b77c: 33480c xor ecx,dword ptr [eax+0xc]
0x41b77f: 334810 xor ecx,dword ptr [eax+0x10]
0x41b782: 8b642408 mov esp,dword ptr [esp+0x8]
0x41b786: 648f0500000000 pop dword ptr fs:[0x0]
Below is code in which HDSpoof creates a new exception handler [7].
0x41f52b: add dword ptr [esp],0x9ca
0x41f532: push dword ptr [dword ptr fs:[0x0]
0x41f539: mov dword ptr fs:[0x0],esp
3.8 Overwriting debugger information
Some malware uses techniques that can override debugger information and therefore cause either the debugger or the virus itself to function improperly.
By hooking the INT 1 and INT 3 ( INT3 is the 0xCC opcode byte that debuggers use) interrupts, malware can cause the debugger to lose its context. This is harmless during normal execution of the virus. Another option is to hook the interrupts and call another interrupt to run the virus code indirectly. Below is the code to the Tequila virus that hooks INT 1.
new_interrupt_one:
push bp
mov bp,sp
cs cmp b[0a],1 ;masm mod. needed
je 0506 ;masm mod. needed
cmp w[bp+4],09b4
ja 050b ;masm mod. needed
push ax
push es
les ax,[bp+2]
cs mov w[09a0],ax ;masm mod. needed
cs mov w[09a2],es ;masm mod. needed
cs mov b[0a],1
pop es
pop ax
and w[bp+6],0feff
pop bp
iret
Normally the hook routine is set to IRET, as it is without a debugger installed. V2Px uses hooks to decrypt its body with INT 1 and INT 3. The INT 1 and INT 3 vectors are used continuously during execution of the code and calculations are done in the interrupt vector table.
Some viruses also clear the contents of the debug registers (DRn) [9]. This can be done in one of two ways. One way is to use the NtGetContextThread and NtSetContextThread syscalls. Another way is to generate an exception, modify the thread context and then resume normal execution with the new context. An example of this is below [15].
push offset handler
push dword ptr fs:[0]
mov fs:[0],esp
xor eax, eax
div eax ;generate exception
pop fs:[0]
add esp, 4
;continue execution
;...
handler:
mov ecx, [esp+0Ch] ;skip div
add dword ptr [ecx+0B8h], 2 ;skip div
mov dword ptr [ecx+04h], 0 ;clean dr0
mov dword ptr [ecx+08h], 0 ;clean dr1
mov dword ptr [ecx+0Ch], 0 ;clean dr2
mov dword ptr [ecx+10h], 0 ;clean dr3
mov dword ptr [ecx+14h], 0 ;clean dr6
mov dword ptr [ecx+18h], 0 ;clean dr7
xor eax, eax
ret
The first line of the above example pushes the offset of the handler onto the stack to make sure that its own handler will get control when the exception is thrown. Then setup is done in for control to transfer to the handler, including setting eax to zero by XORing it with itself. The div eax instruction generates and exception because eax is zero, so AX is being divided by zero. The handler then skips the divide instruction, cleans dr0-dr7, sets eax to zero again, indicating that the exception was handled, and execution is resumed.
3.9 Detaching the debugger thread
Detaching the thread from the debugger can be done with the NtSetInformationThread syscall. Calling this function with ThreadInformationClass set to 0x11 (ThreadHideFromDebugger), will detach the program’s thread from the debugger if there is a debugger present. The following code is an example [15]:
push 0
push 0
push 11h ;ThreadHideFromDebugger
push -2
call NtSetInformationThread
In this example, the parameters for the NtSetInformationThread are first pushed onto the stack and then the function is called removing the program’s thread from the debugger. This is done because 0 is passed in for the thread information length and thread information, -2 is passed on for the thread handle, and 11h is passed in for the thread information class which is the ThreadHideFromDebugger value.
3.10 Decryption
Decryption can be done in several different ways that also protect against debugging. Some decryption depends upon a specific execution path. If this execution path is not followed, due to a debugger being started at a specific point in the program, the value that the decryption algorithm uses may be incorrect. Therefore, the program will not decrypt itself correctly. HDSpoof uses this technique [7].
Some viruses use the stack to decrypt their code. Using a debugger on such a virus causes the decryption to fail, because the stack is used by INT 1 during debugging. One example is the W95/SK virus that decrypts and builds its code on the stack. Another example of this is the Cascade virus that uses the stack pointer register for one of the decryption keys. Below is the code:
lea si, Start ; position to decrypt
mov sp, 0682 ; length of encrypted body
Decrypt:
xor [si], si ; decryption key/counter 1
xor [si], sp ; decryption key/counter 2
inc si ; increment one counter
dec sp ; decrement the other
jnz Decrypt ; loop until all bytes are decrypted
Start: ; Virus body
The comments on the above example explain fairly well how the Cascade virus uses the stack pointer to decrypt the virus body. The Cryptor virus, on the other hand, stores its encryption keys in the keyboard buffer, which is also destroyed by a debugger. Tequila uses the decryptor’s code as the decryption key, so if the decryptor is modified with a debugger the virus will not be decrypted [9]. Below is the Tequila decryption code [13]:
perform_encryption_decryption:
mov bx,0
mov si,0960
mov cx,0960
mov dl,b[si]
xor b[bx],dl
inc si
inc bx
cmp si,09a0
jb 0a61 ;masm mod. needed
mov si,0960
loop 0a52 ;masm mod. needed
ret
the_file_decrypting_routine:
push cs
pop ds
mov bx,4
mov si,0964
mov cx,0960
mov dl,b[si]
add b[bx],dl
inc si
inc bx
cmp si,09a4
jb 0a7e ;masm mod. needed
mov si,0964
loop 0a6f ;masm mod. needed
jmp 0390 ;masm mod. needed
Research is being done on new anti-debugging methods that may be used in the future. One such project works on a multiprocessor computer in which one processor is unused while debugging. This new technique uses parallel processing of the decryption code [11].
4. Other Anti-detection Techniques
4.1 Retroviruses
Retroviruses try to disable the anti-virus software. They do this by carrying a list of process names and killing the processes the program finds running. Many retroviruses also take the process off of the startup list so the process no longer starts when the computer boots. This type of malware may also try to starve the anti-virus software of CPU time or prevent the anti-virus software from connecting to the company’s servers to update its database [1].
5. Combining Techniques
The W32.Gobi virus is a polymorphic retrovirus that uses EPO and several anti-debugging techniques. This virus opens a backdoor on TCP port 666 [8]
Simile (also known as Metaphor) is a very well known and complex virus that is approximately 14,000 lines of assembly [9]. This virus uses EPO by looking for the ExitProcess() API call. It is also a metamorphic virus that uses polymorphic decryption [1]. About 90% of its code is spent on the polymorphic decryption. The virus body and polymorphic decryptor are placed in a semi-random place in a newly infected file each time. The first payload of Simile only activates during March, June, September or December. Variants A and B display their message on the 17th of these months. Variant C displays its message on the 18th. The second payload activates on the 14th of May in variants A and B and on the 14th of July in variant C [9].
Ganda is a retrovirus that uses EPO. It examines the list of startup processes and replaces the first instruction of each startup process with a return. This renders any antivirus programs useless [1].
Overextending the emulator is defined as executing a set of instructions that will cause the emulator to crash or that may indicate that an emulator is running. Calling undocumented instructions that an emulator may not support is one way to cause the emulator to throw an exception and stop running. One such example is the undocumented CPU Instruction SALC that is used in W95/Vulcano [9]. Another way to detect emulation or to crash the emulator currently running, if there is one, is to try to access large portions of memory at once [1]. This is usually not effective though because most operating systems, as well as emulators, will impede the program.
A way to detect whether an emulator is running is to call a function twice that should return two different values. An example of this would be calling any of the time functions twice, and verifying that there is a difference between two return values. In Windows this can be achieved through kernel32!QueryPerformanceCounter which wraps ZwQueryPerformaceCounter, kernel32!GetTickCounter, or by querying the current number of CPU cycles executed since the machine started using the RDTSC (read time stamp counter) instruction. An example of the latter is below [15].
push offset handler
push dword ptr fs:[0]
mov fs:[0],esp
rdtsc
push eax
xor eax, eax
div eax ;trigger exception
rdtsc
sub eax, [esp] ;ticks delta
add esp, 4
pop fs:[0]
add esp, 4
cmp eax, 10000h ;threshold
jb @not_debugged
@debugged:
...
@not_debugged:
...
handler:
mov ecx, [esp+0Ch]
add dword ptr [ecx+0B8h], 2 ;skip div
xor eax, eax
ret
The example above shows how the RDTSC instruction can be used to detect whether a debugger is present. In this case, RDTSC is called twice and the difference of the two values returned is found. This difference is then compared to a threshold (in this example it is 10000h). If the difference is greater, than a debugger is present and a jump away from the malicious code is executed.
Importing obscure libraries may not actually cause the emulator to stop running, but if the library is not imported, the malware code itself may not run.
Malware can also look for webpages to see if it has access to the internet. This is something that can also cause the virus code to not execute on a machine that is not currently connected to the internet, but also stops execution when an emulator is running since most emulators do not allow internet access [1].
Using coprocessor FPU instructions is another way to overextend the emulator because most emulators do not emulate the FPU instructions. Prizzy polymorphic engine (PPE) can generate 43 different coprocessor instructions for the use of its polymorphic decryptor. If these FPU instructions are not provided, the decryption on Prizzy does not execute.
Along the same lines, malware can use MMX instructions. This instruction set adds 8 new registers to the architecture. The malware will check to see if MMX support exists by using the CPUID instruction. Examples of malware that use this technique are W32/Legacy and W32/Thorin.
Malware will also setup an exception handler, execute a garbage block of code, and then indirectly execute its own handler to transfer control to another part of the polymorphic decryptor. This is done in hopes that the emulator cannot handle the exception [9]. An example that is similar to this technique is shown in section 3.7.
3. Anti-debugging
Anti-debugging techniques are usually any attempt of the malware to monitor its own code to detect debugging. To do this, the malware can examine its own code for breakpoints or check for a debugger directly through system calls.
3.1 Breakpoints
To examine its code for breakpoints, the malware can look for the 0xcc opcode instruction, which raises a SIGTRAP. This is the instruction the debugger will use to gain control from the malware at a breakpoint. The malware can also set false breakpoints if the malware code itself has a signal handler. This way it can continue to execute instructions after the breakpoint that it set.
Malware can also try to overwrite the breakpoints. W95/Marburg virus uses a backwards decryption loop for the virus to overwrite the breakpoint. The viruses in the Yankee_doodle family, on the other hand, use hamming code to self correct their code. Hamming code allows programs to detect and correct errors, but in this case allows the virus to detect and remove breakpoints in its code [9].
3.2 Calculating the checksum
Malware can also checksum its own code. If the checksum has changed, then the virus can assume that it is being debugged and there have been breakpoints placed within the code [3]. VAMPiRE is an anti-anti debugging tool that gets around the detection of breakpoints [12]. VaMPiRE accomplishes this by keeping a table of breakpoints in memory to maintain a list of the breakpoints that have been set. The program consists of a page-fault handler (PFH), a general protection fault handler (GPFH), a single-step handler and a framework API. When a breakpoint is triggered either the PFH (handles breakpoints set on code, data, or memory mapped I/O) or the GPFH (handles legacy I/O breakpoints) receives control. The single-step handler is used for breakpoint persistence, allowing breakpoints to be used more than once.
3.3 Detecting the debugger
A very simple way of detecting a debugger on a Linux system is to simply call Ptrace, since Ptrace can’t be called in succession more than once for a specific process [3]. In Windows, the system call isDebuggerPresent will return 1 if the program is being debugged and 0 otherwise. This system call simply checks a flag that has been set by the debugger if it is running. This check can be done directly by checking the second byte in the Process Environment Block. The following code is an example of this technique.
mov eax, fs:[30h]
move eax, byte [eax+2]
test eax, eax
jne @DdebuggerDetected
As the above example shows, eax is set to the PEB (Process Environment Block) and the second byte of that block is then accessed and the contents moved into eax. A check is done to see whether eax is zero. If it is, then there is no debugger present, if not, then there is a debugger.
When a process is created with a debugger already running, the system sets certain flags for the heap manipulation routines in the Windows dll ntdll.dll. These flags are FLG_HEAP_ENABLE_TAIL_CHECK, FLG_HEAP_ENABLE_FREE_CHECK, and FLG_HEAP_VALIDATE_PARAMETERS. These flags can be checked using the following code:
mov eax, fs:[30h]
mov eax, [eax+68h]
and eax, 0x70
test eax, eax
jne @DebuggerDetected
In the above example, we again access the PEB and then get the start of the flags for the heap manipulation routine by adding 68h as an offset to the address of the PEB. The flags are then checked to see if a debugger is present.
Checking flags within heap headers such as the ForceFlags is another way to detect whether a debugger is running or not. Here is an example [15]:
mov eax, fs:[30h]
mov eax, [eax+18h] ;process heap
mov eax, [eax+10h] ;heap flags
test eax, eax
jne @DebuggerDetected
The above example shows how the process heap and the heap flags can be accessed from the offset of the PEB. These are then tested to see if the Force Flags were previously set by a debugger currently running.
Another possible way to detect the debugger is through the use of the NtQueryInformationProcess syscall. This function can be called with ProcessInformationClass set to 7, which refers to the ProcessDebugPort, and the function will return -1 if the process is being debugged. Below is an example [15].
push 0
push 4
push offset isdebugged
push 7 ;ProcessDebugPort
push -1
call NtQueryInformationProcess
test eax, eax
jne @ExitError
cmp isdebugged, 0
jne @DebuggerDetected
In this example, the parameters for the NtQueryInformationProcess syscall are first pushed onto the stack. These parameters are as follows: the first is the handle (in this case 0), the second is the process information length (4 bytes in this example), the following is the process information class (in this case 7, specifying the ProcessDebugPort), the next is the variable used to return whether or not there is a debugger present. If this value is non-zero then the process is being run under a debugger. If not, then all is well. The last parameter is the return length. NtQueryInformationProcess is then called with these parameters and a return value is placed in isdebugged. This is later tested to see if it equals zero, or not.
Other simple ways of detecting the debugger is by checking to see if the device list contains the name of a debugger, by checking the registry keys for a debugger, or by scanning memory to detect the debugger’s code in memory [9].
Another method, similar to the EPO method, is to instruct the PE loader that the entry point of the program is referenced in the Thread Local Storage (TLS) entry in the PE header. This has the effect of causing the code in the TLS to execute first instead of the read entry point of the program. Therefore, the TLS can perform anti-debugging checks before the program even starts [15]. Starting on the TLS also allows the virus to begin execution before the debugger starts, since some debuggers break on the main entry point of the program [9].
3.4 Checking for single stepping
Other ways that the malware can detect a debugger is to check for single stepping. Checking for single stepping can be done by adding a value above the stack pointer and then checking to see if the value is still there. If the value is there, this means that the code is being single stepped. When a debugger is single stepping a process, it will push instructions onto the stack when it takes control and pop them back off the stack before it executes the next instruction. So if the value is still there that means that something other than the running process has been using the stack [1]. Below is a code example of how malware can detect single stepping by using the stack state [9]:
mov bp, sp ; pick stack pointer
push ax ; store any ax mark on the stack
pop ax ; pick the value from the stack
cmp word ptr [bp-2], ax ; compare against stack
jne debug ; if different, debugger detected.
As the comments in this example show, a value is pushed onto the stack then popped off the stack. If the debugger is present, then the value at the top of the stack pointer – 2 will be different than the value that was just popped off the stack and the appropriate action can be taken.
3.5 Checking for slowdown in runtime
By looking for slowdown in the runtime of the program, malicious code can also detect a debugger. A significant slowdown in runtime likely means that the code is being single stepped. So if the difference in the timestamp for 2 different calls is too great, the malware can act accordingly [1]. LTTng/LTTV Linux Trace Toolkit gets around the slowdown problem to trace a virus. This is because LTTng/LTTV is a modular tool that traces the program without adding breakpoints or performing any analysis at the time of execution. It also uses a lockless re-entry mechanism, meaning that it does not lock any portions of the Linux kernel code that the program being traced might need to use, and therefore does not cause the traced program to slow down and wait [4].
3.6 Instruction prefetching
If the malicious code modifies the next instruction in a sequence and the new instruction is executed, then a debugger is running. This is due to instruction prefetching; if the new instruction is prefetched, this means there was a break in the execution of the process. Otherwise the original instruction would have been prefetched and executed [1].
3.7 Self modifying code
The malware can also self-modify other code. One example of this is HDSpoof. This malware starts out with exception handlers and then removes them during execution. That way, if anything goes wrong and an exception is thrown by the process during execution, the virus will terminate. It also modifies the exception handlers at other times during execution by either removing or adding exception handlers. Below is an example of HDSpoof removing all exception handlers except for the default one [7].
exception handlers before:
0x77f79bb8 ntdll.dll:executehandler2@20 + 0x003a
0x0041adc9 hdspoof.exe+0x0001adc9
0x77e94809 __except_handler3
exception handlers after:
0x77e94809 __except_handler3
0x41b770: 8b44240c mov eax,dword ptr [esp+0xc]
0x41b774: 33c9 xor ecx,ecx
0x41b776: 334804 xor ecx,dword ptr [eax+0x4]
0x41b779: 334808 xor ecx,dword ptr [eax+0x8]
0x41b77c: 33480c xor ecx,dword ptr [eax+0xc]
0x41b77f: 334810 xor ecx,dword ptr [eax+0x10]
0x41b782: 8b642408 mov esp,dword ptr [esp+0x8]
0x41b786: 648f0500000000 pop dword ptr fs:[0x0]
Below is code in which HDSpoof creates a new exception handler [7].
0x41f52b: add dword ptr [esp],0x9ca
0x41f532: push dword ptr [dword ptr fs:[0x0]
0x41f539: mov dword ptr fs:[0x0],esp
3.8 Overwriting debugger information
Some malware uses techniques that can override debugger information and therefore cause either the debugger or the virus itself to function improperly.
By hooking the INT 1 and INT 3 ( INT3 is the 0xCC opcode byte that debuggers use) interrupts, malware can cause the debugger to lose its context. This is harmless during normal execution of the virus. Another option is to hook the interrupts and call another interrupt to run the virus code indirectly. Below is the code to the Tequila virus that hooks INT 1.
new_interrupt_one:
push bp
mov bp,sp
cs cmp b[0a],1 ;masm mod. needed
je 0506 ;masm mod. needed
cmp w[bp+4],09b4
ja 050b ;masm mod. needed
push ax
push es
les ax,[bp+2]
cs mov w[09a0],ax ;masm mod. needed
cs mov w[09a2],es ;masm mod. needed
cs mov b[0a],1
pop es
pop ax
and w[bp+6],0feff
pop bp
iret
Normally the hook routine is set to IRET, as it is without a debugger installed. V2Px uses hooks to decrypt its body with INT 1 and INT 3. The INT 1 and INT 3 vectors are used continuously during execution of the code and calculations are done in the interrupt vector table.
Some viruses also clear the contents of the debug registers (DRn) [9]. This can be done in one of two ways. One way is to use the NtGetContextThread and NtSetContextThread syscalls. Another way is to generate an exception, modify the thread context and then resume normal execution with the new context. An example of this is below [15].
push offset handler
push dword ptr fs:[0]
mov fs:[0],esp
xor eax, eax
div eax ;generate exception
pop fs:[0]
add esp, 4
;continue execution
;...
handler:
mov ecx, [esp+0Ch] ;skip div
add dword ptr [ecx+0B8h], 2 ;skip div
mov dword ptr [ecx+04h], 0 ;clean dr0
mov dword ptr [ecx+08h], 0 ;clean dr1
mov dword ptr [ecx+0Ch], 0 ;clean dr2
mov dword ptr [ecx+10h], 0 ;clean dr3
mov dword ptr [ecx+14h], 0 ;clean dr6
mov dword ptr [ecx+18h], 0 ;clean dr7
xor eax, eax
ret
The first line of the above example pushes the offset of the handler onto the stack to make sure that its own handler will get control when the exception is thrown. Then setup is done in for control to transfer to the handler, including setting eax to zero by XORing it with itself. The div eax instruction generates and exception because eax is zero, so AX is being divided by zero. The handler then skips the divide instruction, cleans dr0-dr7, sets eax to zero again, indicating that the exception was handled, and execution is resumed.
3.9 Detaching the debugger thread
Detaching the thread from the debugger can be done with the NtSetInformationThread syscall. Calling this function with ThreadInformationClass set to 0x11 (ThreadHideFromDebugger), will detach the program’s thread from the debugger if there is a debugger present. The following code is an example [15]:
push 0
push 0
push 11h ;ThreadHideFromDebugger
push -2
call NtSetInformationThread
In this example, the parameters for the NtSetInformationThread are first pushed onto the stack and then the function is called removing the program’s thread from the debugger. This is done because 0 is passed in for the thread information length and thread information, -2 is passed on for the thread handle, and 11h is passed in for the thread information class which is the ThreadHideFromDebugger value.
3.10 Decryption
Decryption can be done in several different ways that also protect against debugging. Some decryption depends upon a specific execution path. If this execution path is not followed, due to a debugger being started at a specific point in the program, the value that the decryption algorithm uses may be incorrect. Therefore, the program will not decrypt itself correctly. HDSpoof uses this technique [7].
Some viruses use the stack to decrypt their code. Using a debugger on such a virus causes the decryption to fail, because the stack is used by INT 1 during debugging. One example is the W95/SK virus that decrypts and builds its code on the stack. Another example of this is the Cascade virus that uses the stack pointer register for one of the decryption keys. Below is the code:
lea si, Start ; position to decrypt
mov sp, 0682 ; length of encrypted body
Decrypt:
xor [si], si ; decryption key/counter 1
xor [si], sp ; decryption key/counter 2
inc si ; increment one counter
dec sp ; decrement the other
jnz Decrypt ; loop until all bytes are decrypted
Start: ; Virus body
The comments on the above example explain fairly well how the Cascade virus uses the stack pointer to decrypt the virus body. The Cryptor virus, on the other hand, stores its encryption keys in the keyboard buffer, which is also destroyed by a debugger. Tequila uses the decryptor’s code as the decryption key, so if the decryptor is modified with a debugger the virus will not be decrypted [9]. Below is the Tequila decryption code [13]:
perform_encryption_decryption:
mov bx,0
mov si,0960
mov cx,0960
mov dl,b[si]
xor b[bx],dl
inc si
inc bx
cmp si,09a0
jb 0a61 ;masm mod. needed
mov si,0960
loop 0a52 ;masm mod. needed
ret
the_file_decrypting_routine:
push cs
pop ds
mov bx,4
mov si,0964
mov cx,0960
mov dl,b[si]
add b[bx],dl
inc si
inc bx
cmp si,09a4
jb 0a7e ;masm mod. needed
mov si,0964
loop 0a6f ;masm mod. needed
jmp 0390 ;masm mod. needed
Research is being done on new anti-debugging methods that may be used in the future. One such project works on a multiprocessor computer in which one processor is unused while debugging. This new technique uses parallel processing of the decryption code [11].
4. Other Anti-detection Techniques
4.1 Retroviruses
Retroviruses try to disable the anti-virus software. They do this by carrying a list of process names and killing the processes the program finds running. Many retroviruses also take the process off of the startup list so the process no longer starts when the computer boots. This type of malware may also try to starve the anti-virus software of CPU time or prevent the anti-virus software from connecting to the company’s servers to update its database [1].
5. Combining Techniques
The W32.Gobi virus is a polymorphic retrovirus that uses EPO and several anti-debugging techniques. This virus opens a backdoor on TCP port 666 [8]
Simile (also known as Metaphor) is a very well known and complex virus that is approximately 14,000 lines of assembly [9]. This virus uses EPO by looking for the ExitProcess() API call. It is also a metamorphic virus that uses polymorphic decryption [1]. About 90% of its code is spent on the polymorphic decryption. The virus body and polymorphic decryptor are placed in a semi-random place in a newly infected file each time. The first payload of Simile only activates during March, June, September or December. Variants A and B display their message on the 17th of these months. Variant C displays its message on the 18th. The second payload activates on the 14th of May in variants A and B and on the 14th of July in variant C [9].
Ganda is a retrovirus that uses EPO. It examines the list of startup processes and replaces the first instruction of each startup process with a return. This renders any antivirus programs useless [1].
Wednesday, June 16, 2010
Anti-debugging and Anti-emulation Techniques
Anti-debugging and Anti-emulation Techniques
Malware is code written with the intent to cause annoyance, to retrieve sensitive information about individuals, to cause data loss, or for other similar purposes. Antivirus companies are constantly trying to detect malware and to lessen or stop these damaging effects. This causes an ongoing struggle between antivirus companies and virus writers. Anti-debugging and anti-emulation techniques have been devised by virus writers to counteract the efforts of antivirus companies to detect and remove malicious code. To further detect and stop malware, these techniques must be understood. This paper attempts to identify current anti-debugging and anti-emulation techniques and to provide code samples to allow for the identification of malicious code.
1. Introduction
To deter or slow down analysts from reverse-engineering malware, virus writers employ anti-debugging and anti-emulation techniques. These techniques slow down the reverse-engineering process by attempting to avoid detection when a virus is being run in an emulator or debugger. Several different methods are employed by malware to fool dynamic detection and other analysis mechanisms such as emulators and debuggers. Each virus usually employs one to many of these techniques.
This paper discusses those methods virus writers employ to slow down reverse-engineering of their viruses. It also provides examples of these methods. This paper is intends to provide an overview of the various anti-debugging and anti-emulation techniques for those that want to protect against these defenses.
The paper is split into several sections. Section 2 addresses anti-emulation techniques, followed by anti-debugging techniques in section 3, and other anti-detection techniques that do not fall into the first two categories are discussed in section 4. Examples of viruses that combine all of the techniques are discussed in section 5, while section 6 is the conclusion.
2. Anti-emulation
An emulator provides a restricted environment (an image of an operating system that is installed on top of a host operating system) in which one can dynamically analyze a program. For example, a machine running Linux can have a virtual machine installed on it running Windows XP. An emulator will also include CPU and memory emulation, hardware emulation, and an emulation controller [1]. This provides a safe way to dynamically analyze programs without the possibility of causing damage to the underlying operating system.
There are also drawbacks to this system. First, the more time spent emulating, the longer the user has to wait to get any analysis back on the program. Second, emulation is slow due to the overhead required to monitor the program and to emulate the operating system and hardware. QEMU, a hardware and operating system emulator, has between a factor of 4 to 10 slowdown in hardware emulation and a factor of 2 slowdown on emulation of the software memory management unit [2]. QEMU does not have any dynamic monitoring, which would further increase the slowdown. A final drawback is that malware employs different anti-emulation techniques to fool the emulator. These techniques fall into three categories: Outlasting, outsmarting, or overextending the emulator.
2.1 Outlasting the emulator
Since emulation is expensive, emulators only run a couple hundred instructions of code to detect malware before terminating. On an Intel x86 system, it is believed that running around 1000 instructions is enough to detect malicious code while maintaining a short runtime [1]. If the code does nothing considered malicious during that time, the emulator will not detect the code as malware. Outlasting the emulator can be done by replicating based on a specific probability, by running benign code for a specific time frame before running the malicious code, or by entry point obfuscation.
2.1.1 Probabilistic Replication
Some malware will only replicate a certain percentage of the time. This means that an emulator would have to run the code several times in order to accurately detect the malicious code. An example of this is a virus that runs benign code 90% of executions and malicious code only 10%.
2.1.2 Running Benign Code
Other malware will run benign code every time on startup for a specific time frame and then run the malicious code. The purpose of this is to allow the emulator to run for the given number of instructions and pretend that the code does nothing malicious in this time frame. It then goes on to replicate and cause damage to a system.
2.1.3 Entry Point Obfuscation
Entry point obfuscation (EPO) is a method that includes attaching malicious code to a specific section of a file. Instead of the malicious code executing first, the code can look for calls to the ExitProcess() API function and overwrite those calls with a jump to the malicious code. This way the code runs on exit, not entry of an executable. It can also look for a specific sequence of code to overwrite with the malicious code itself, or with a jump to the malicious code. Entry point obfuscation, therefore, has the added advantage of giving the virus the ability to run the code later by copying the code to a new location before actually overwriting it [1].
2.2 Outsmarting the emulator
To outsmart the emulator some malware uses time based triggers, or other conditionals, or it uses different decryption techniques if it is encrypted malware. Time based triggers can be anything as simple as running the malicious code only on 3 pm or only on a specific day. The malware can also check conditions such as checking to see if it is being debugged or emulated. If it is, it executes benign code.
Decryption techniques that can be used include spreading the decryption loop throughout the code or having multiple decryption passes [1]. Multiple decryption layers are used by W32/Harrier, W32/Coke and W32/Zelly where the first decryptor will decrypt the second, the second will decrypt the third, etc [9]. Malware can also only decrypt blocks of code as needed in order to outsmart the emulator [1].
The RDA.Fighter virus uses brute force decryption. This means that the virus does not store the decryption key so it must try all possible decryption keys in order to decrypt itself. This is useful because it is then difficult for anti-virus companies to decrypt the virus without using the same brute force method, which takes a large amount of emulation instructions. It is likely, then, that the virus will not decrypt itself while the emulator is running. Below is the code for the decryption code of the RDA Fighter virus [6].
setup:
xor ebx,ebx
iterate:
mov esi,[ebp + hostOffset]
mov edi,esi
mov ecx,[ebp + host_size]
inc ebx
decrypt:
lodsb
xor al,bl
stosb
loop decrypt
check:
mov esi,[ebp + hostOffset]
push esi
mov ecx,[ebp + host_size]
push ecx
mov eax,[ebp + __ADDR_CheckSum] ; whatever this happens to be
call eax
test eax,eax
jnz iterate
mov esi,[ebp + hostOffset]
jmp esi
In the above example we see that the setup block sets ebx to zero and is only run once. Iterate then sets esi and edi to the beginning of the encrypted code, sets ecx to the size of the encrypted code, and also increments ebx by one. The decrypt basic block goes through the ecrypted code byte by byte and xors the byte with the key in ebx. This loop terminates when ecx becomes zero. The check basic block then checks to see if the current code matches a predetermined checksum. If it does, then the code has been decrypted. If it hasn’t been, it goes back to the iterative loop and tries again with the next largest key. If it has been decrypted then it jumps to the newly decrypted code.
W95/Fono uses a nonlinear decryption algorithm, meaning that the encrypted portion of the virus is not decrypted linearly as expected. Since the virus body is not decrypted one byte after the other, it can confuse emulators. W95/Fono uses a key table and the decryptor performs substitutions based on this table. Each symbol in the plaintext alphabet corresponds to another symbol in the ciphertext. For example: A corresponds with L, Z corresponds with F, etc. Therefore, by using this encryption method, each piece of the virus is decrypted in semi-random order and every position is only hit once. W95/Drill and {W32, Linux}/Simile.D use nonlinear decryption as well.
W95/Silcer and W95/Resure force the Windows Loader to relocate the infected program images when they are loaded to memory. Relocating the images is responsible for decrypting the virus body because the virus puts in special relocations for the decryption [9]. W95/Resurrel is a virus written after W95/Resure. This virus sets the base address of the newly infected file to a value of 0xBFxxxxxx (the xxxxxx is a random value returned by the GetTickCount() API call). Then it adds a relocation entry for each DWORD value of its own code section and encrypts each DWORD by adding the base address value to the DWORD of the code section and then subtracting 0x400000. When the application is executed the image of the program cannot be loaded into memory as is because the base address is wrong or an address in KERNEL32.DLL. Therefore, the system loader will relocate the code to a valid address, decrypting the virus as it does so. The difficulty in decrypting the virus makes it hard to detect [10].
Malware is code written with the intent to cause annoyance, to retrieve sensitive information about individuals, to cause data loss, or for other similar purposes. Antivirus companies are constantly trying to detect malware and to lessen or stop these damaging effects. This causes an ongoing struggle between antivirus companies and virus writers. Anti-debugging and anti-emulation techniques have been devised by virus writers to counteract the efforts of antivirus companies to detect and remove malicious code. To further detect and stop malware, these techniques must be understood. This paper attempts to identify current anti-debugging and anti-emulation techniques and to provide code samples to allow for the identification of malicious code.
1. Introduction
To deter or slow down analysts from reverse-engineering malware, virus writers employ anti-debugging and anti-emulation techniques. These techniques slow down the reverse-engineering process by attempting to avoid detection when a virus is being run in an emulator or debugger. Several different methods are employed by malware to fool dynamic detection and other analysis mechanisms such as emulators and debuggers. Each virus usually employs one to many of these techniques.
This paper discusses those methods virus writers employ to slow down reverse-engineering of their viruses. It also provides examples of these methods. This paper is intends to provide an overview of the various anti-debugging and anti-emulation techniques for those that want to protect against these defenses.
The paper is split into several sections. Section 2 addresses anti-emulation techniques, followed by anti-debugging techniques in section 3, and other anti-detection techniques that do not fall into the first two categories are discussed in section 4. Examples of viruses that combine all of the techniques are discussed in section 5, while section 6 is the conclusion.
2. Anti-emulation
An emulator provides a restricted environment (an image of an operating system that is installed on top of a host operating system) in which one can dynamically analyze a program. For example, a machine running Linux can have a virtual machine installed on it running Windows XP. An emulator will also include CPU and memory emulation, hardware emulation, and an emulation controller [1]. This provides a safe way to dynamically analyze programs without the possibility of causing damage to the underlying operating system.
There are also drawbacks to this system. First, the more time spent emulating, the longer the user has to wait to get any analysis back on the program. Second, emulation is slow due to the overhead required to monitor the program and to emulate the operating system and hardware. QEMU, a hardware and operating system emulator, has between a factor of 4 to 10 slowdown in hardware emulation and a factor of 2 slowdown on emulation of the software memory management unit [2]. QEMU does not have any dynamic monitoring, which would further increase the slowdown. A final drawback is that malware employs different anti-emulation techniques to fool the emulator. These techniques fall into three categories: Outlasting, outsmarting, or overextending the emulator.
2.1 Outlasting the emulator
Since emulation is expensive, emulators only run a couple hundred instructions of code to detect malware before terminating. On an Intel x86 system, it is believed that running around 1000 instructions is enough to detect malicious code while maintaining a short runtime [1]. If the code does nothing considered malicious during that time, the emulator will not detect the code as malware. Outlasting the emulator can be done by replicating based on a specific probability, by running benign code for a specific time frame before running the malicious code, or by entry point obfuscation.
2.1.1 Probabilistic Replication
Some malware will only replicate a certain percentage of the time. This means that an emulator would have to run the code several times in order to accurately detect the malicious code. An example of this is a virus that runs benign code 90% of executions and malicious code only 10%.
2.1.2 Running Benign Code
Other malware will run benign code every time on startup for a specific time frame and then run the malicious code. The purpose of this is to allow the emulator to run for the given number of instructions and pretend that the code does nothing malicious in this time frame. It then goes on to replicate and cause damage to a system.
2.1.3 Entry Point Obfuscation
Entry point obfuscation (EPO) is a method that includes attaching malicious code to a specific section of a file. Instead of the malicious code executing first, the code can look for calls to the ExitProcess() API function and overwrite those calls with a jump to the malicious code. This way the code runs on exit, not entry of an executable. It can also look for a specific sequence of code to overwrite with the malicious code itself, or with a jump to the malicious code. Entry point obfuscation, therefore, has the added advantage of giving the virus the ability to run the code later by copying the code to a new location before actually overwriting it [1].
2.2 Outsmarting the emulator
To outsmart the emulator some malware uses time based triggers, or other conditionals, or it uses different decryption techniques if it is encrypted malware. Time based triggers can be anything as simple as running the malicious code only on 3 pm or only on a specific day. The malware can also check conditions such as checking to see if it is being debugged or emulated. If it is, it executes benign code.
Decryption techniques that can be used include spreading the decryption loop throughout the code or having multiple decryption passes [1]. Multiple decryption layers are used by W32/Harrier, W32/Coke and W32/Zelly where the first decryptor will decrypt the second, the second will decrypt the third, etc [9]. Malware can also only decrypt blocks of code as needed in order to outsmart the emulator [1].
The RDA.Fighter virus uses brute force decryption. This means that the virus does not store the decryption key so it must try all possible decryption keys in order to decrypt itself. This is useful because it is then difficult for anti-virus companies to decrypt the virus without using the same brute force method, which takes a large amount of emulation instructions. It is likely, then, that the virus will not decrypt itself while the emulator is running. Below is the code for the decryption code of the RDA Fighter virus [6].
setup:
xor ebx,ebx
iterate:
mov esi,[ebp + hostOffset]
mov edi,esi
mov ecx,[ebp + host_size]
inc ebx
decrypt:
lodsb
xor al,bl
stosb
loop decrypt
check:
mov esi,[ebp + hostOffset]
push esi
mov ecx,[ebp + host_size]
push ecx
mov eax,[ebp + __ADDR_CheckSum] ; whatever this happens to be
call eax
test eax,eax
jnz iterate
mov esi,[ebp + hostOffset]
jmp esi
In the above example we see that the setup block sets ebx to zero and is only run once. Iterate then sets esi and edi to the beginning of the encrypted code, sets ecx to the size of the encrypted code, and also increments ebx by one. The decrypt basic block goes through the ecrypted code byte by byte and xors the byte with the key in ebx. This loop terminates when ecx becomes zero. The check basic block then checks to see if the current code matches a predetermined checksum. If it does, then the code has been decrypted. If it hasn’t been, it goes back to the iterative loop and tries again with the next largest key. If it has been decrypted then it jumps to the newly decrypted code.
W95/Fono uses a nonlinear decryption algorithm, meaning that the encrypted portion of the virus is not decrypted linearly as expected. Since the virus body is not decrypted one byte after the other, it can confuse emulators. W95/Fono uses a key table and the decryptor performs substitutions based on this table. Each symbol in the plaintext alphabet corresponds to another symbol in the ciphertext. For example: A corresponds with L, Z corresponds with F, etc. Therefore, by using this encryption method, each piece of the virus is decrypted in semi-random order and every position is only hit once. W95/Drill and {W32, Linux}/Simile.D use nonlinear decryption as well.
W95/Silcer and W95/Resure force the Windows Loader to relocate the infected program images when they are loaded to memory. Relocating the images is responsible for decrypting the virus body because the virus puts in special relocations for the decryption [9]. W95/Resurrel is a virus written after W95/Resure. This virus sets the base address of the newly infected file to a value of 0xBFxxxxxx (the xxxxxx is a random value returned by the GetTickCount() API call). Then it adds a relocation entry for each DWORD value of its own code section and encrypts each DWORD by adding the base address value to the DWORD of the code section and then subtracting 0x400000. When the application is executed the image of the program cannot be loaded into memory as is because the base address is wrong or an address in KERNEL32.DLL. Therefore, the system loader will relocate the code to a valid address, decrypting the virus as it does so. The difficulty in decrypting the virus makes it hard to detect [10].
Tuesday, June 15, 2010
OS:Disk Transfer Area (DTA)
Disk Transfer Area (DTA)
For all file reads and writes performed using FCB function calls, as well as for "Find First" and "Find Next" calls using FCBs or not, DOS uses a memory buffer called Disk Transfer Area, which is by default located at offset 80h in the PSP and is 128 bytes long (this area is also used by the command tail), so in order not to interfere with whichever command line parameters there might be, the Disk Transfer Address should be set to a different location in memory. This is done like this:
--8<--------------------------------------------------------------------------- Set_DTA:
mov ah, 1Ah
lea dx, [bp+offset DTA]
int 21h
---------------------------------------------------------------------------8<--
;Interrupt: 21h
;Function: 1Ah - Set Disk Transfer Address (DTA)
;On entry: AH - 1Ah
; DS:DX - Address of DTA
;Returns: Nothing
Of course that before passing control back to the host you should restore the Disk Transfer Address back to its original value:
--8<--------------------------------------------------------------------------- Restore_DTA:
mov ah, 1Ah
mov dx, 80h
int 21h
---------------------------------------------------------------------------8<--
A sufficient buffer area should always be reserved, as DOS will detect and abort any disk transfers that would fall off the end of the current segment or wrap around within the segment.
For all file reads and writes performed using FCB function calls, as well as for "Find First" and "Find Next" calls using FCBs or not, DOS uses a memory buffer called Disk Transfer Area, which is by default located at offset 80h in the PSP and is 128 bytes long (this area is also used by the command tail), so in order not to interfere with whichever command line parameters there might be, the Disk Transfer Address should be set to a different location in memory. This is done like this:
--8<--------------------------------------------------------------------------- Set_DTA:
mov ah, 1Ah
lea dx, [bp+offset DTA]
int 21h
---------------------------------------------------------------------------8<--
;Interrupt: 21h
;Function: 1Ah - Set Disk Transfer Address (DTA)
;On entry: AH - 1Ah
; DS:DX - Address of DTA
;Returns: Nothing
Of course that before passing control back to the host you should restore the Disk Transfer Address back to its original value:
--8<--------------------------------------------------------------------------- Restore_DTA:
mov ah, 1Ah
mov dx, 80h
int 21h
---------------------------------------------------------------------------8<--
A sufficient buffer area should always be reserved, as DOS will detect and abort any disk transfers that would fall off the end of the current segment or wrap around within the segment.
MAYA:LAVA SHADER EFFECT
Lava shader effect
Lava shader effect
Page 2
Page 3
Page 4
Page 5
Page 1 of 5
Here is a cool tutorial on making a lava shader effect.
Here I will explain how to make shader for lava effects using Maya material editor, called hypershade. For this tutorial I recommend basic knowledge about connecting material nodes inside hypershade.
So for lava effect, we will following procedural 3d textures:
- Stucco
- SolidFractal
- Granite
Also, we are going to use following utility nodes:
- MultiplyDivide
- SetRange
- Bump3d
- Displacement
- Luminance
- 3D texture placement
First, create plane (NURBS or poly), and assign lambert shader to it.
Go to hypershade, graph the network of lambert material(lambert4 in my case, in yours will be lambert2 if you started blank scene), don’t do with the lambert1.
Create stucco node (under 3d textures tab)
Stucco and the 3d placement node shall pop near the material, and also open attribute editor for stucco (ctrl+a)
Change shaker attribute to 30, and change channel1 to black and channel2 to orange.
Connect Stucco to incandescence of the material.
Create Fractal texture (also under 3d textures)
Open color balance tab and click to change color gain attribute.
In the color wheel make the color orange. In the HSV sliders under the wheel, change V to 2.5 (so basicly the color goes higher than actual color range, use this every time when you need to create fire and explosions)
Connect Fractal to the channel2 of the stucco. You can do that easily by selecting the stucco, and than dragging fractal to the channel2 color (black rectangle).
So now you are starting to get something that looks like lava!
Lava shader effect
Page 2
Page 3
Page 4
Page 5
Page 1 of 5
Here is a cool tutorial on making a lava shader effect.
Here I will explain how to make shader for lava effects using Maya material editor, called hypershade. For this tutorial I recommend basic knowledge about connecting material nodes inside hypershade.
So for lava effect, we will following procedural 3d textures:
- Stucco
- SolidFractal
- Granite
Also, we are going to use following utility nodes:
- MultiplyDivide
- SetRange
- Bump3d
- Displacement
- Luminance
- 3D texture placement
First, create plane (NURBS or poly), and assign lambert shader to it.
Go to hypershade, graph the network of lambert material(lambert4 in my case, in yours will be lambert2 if you started blank scene), don’t do with the lambert1.
Create stucco node (under 3d textures tab)
Stucco and the 3d placement node shall pop near the material, and also open attribute editor for stucco (ctrl+a)
Change shaker attribute to 30, and change channel1 to black and channel2 to orange.
Connect Stucco to incandescence of the material.
Create Fractal texture (also under 3d textures)
Open color balance tab and click to change color gain attribute.
In the color wheel make the color orange. In the HSV sliders under the wheel, change V to 2.5 (so basicly the color goes higher than actual color range, use this every time when you need to create fire and explosions)
Connect Fractal to the channel2 of the stucco. You can do that easily by selecting the stucco, and than dragging fractal to the channel2 color (black rectangle).
So now you are starting to get something that looks like lava!
Subscribe to:
Posts (Atom)