News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

Mystery - Int 3 inserted into code

Started by Magnum, June 12, 2010, 02:08:13 PM

Previous topic - Next topic

Magnum

I recently noticed that int 3 is inserted right after ExitProcess in a lot of my code.
What is causing that?



.DATA

.CODE

%Date       db " &@Date" ; Compile date

start:

; When the function is called, the thread will continue to
; run but a debugger will no longer receive any events
; related to that thread.  Among the missing events are that
; the process has terminated, if the main thread is the
; hidden one.  This technique is used by
; HyperUnpackMe2, among others.

invoke NtSetInformationThread,-2,11h,NULL,NULL

invoke ExitProcess,0

Have a great day,
                         Andy

clive

Probably linker alignment fill.

Disassembly

00401000 2030                   and     [eax],dh
00401002 362F                   das
00401004 3132                   xor     [edx],esi
00401006 2F                     das
00401007 3130                   xor     [eax],esi

00401009                    start:
00401009 6A00                   push    0
0040100B 6A00                   push    0
0040100D 6A11                   push    11h
0040100F 6AFE                   push    0FFFFFFFEh
00401011 E80E000000             call    jmp_NtSetInformationThread
00401016 6A00                   push    0
00401018 E801000000             call    jmp_ExitProcess
0040101D CC                     db      0CCh

0040101E                    jmp_ExitProcess:            ; Xref 00401018
0040101E FF254C204000           jmp     dword ptr [ExitProcess]

00401024                    jmp_NtSetInformationThread: ; Xref 00401011
00401024 FF2554204000           jmp     dword ptr [NtSetInformationThread]


Here putting a NOP after your call in the source, the alignment 0CCh byte disappears as word alignment is already achieved.

00401009                    start:
00401009 6A00                   push    0
0040100B 6A00                   push    0
0040100D 6A11                   push    11h
0040100F 6AFE                   push    0FFFFFFFEh
00401011 E80E000000             call    jmp_NtSetInformationThread
00401016 6A00                   push    0
00401018 E801000000             call    jmp_ExitProcess
0040101D 90                     nop

0040101E                    jmp_ExitProcess:            ; Xref 00401018
0040101E FF254C204000           jmp     dword ptr [ExitProcess]

00401024                    jmp_NtSetInformationThread: ; Xref 00401011
00401024 FF2554204000           jmp     dword ptr [NtSetInformationThread]
It could be a random act of randomness. Those happen a lot as well.

qWord

these INT's should prevent execution outside your code (e.g. if your proc hasn't a ret-instruction)
FPU in a trice: SmplMath
It's that simple!

Magnum

Thanks for the explanation.

I have seen nops used as fillers before.

Have a great day,
                         Andy

clive

NOP (090h), 000h and 0CCh are quite common. The compilers/linkers over the years have used different methods of alignment padding, especially up to 16 byte (paragraph) boundaries. The are some cases where multi-byte instructions which are effectively 'no operation' have been used. Mostly inconsequential. Also some of the older linkers run under Win95/98 would retain junk from previously allocated memory pages at the end of section boundaries. Typically NT would clear the memory allocation to prevent cross-process information leaks.
It could be a random act of randomness. Those happen a lot as well.