Length limit to MB_OK | MB_ICONEXCLAMATION

[Magnum]

When I added 20 more characters to the end of DbgFoundText, the program chokes.

Is there a length limit to MB_OK | MB_ICONEXCLAMATION?

Code Select Expand



DbgFoundText     db "Debugger found!",0h

PUSH 30h ; Show badboy
PUSH offset DbgFoundTitle
PUSH offset DbgFoundText
PUSH 0
CALL MessageBox



[dedndave]

no - it will almost fill the screen, if it needs to
actually - there may be some practical limit, but it will wrap and crop text, too
i think i put 32 k of text in one, once - something like that

i am guessing that you are overwriting something when you add 20 characters

as you have it shown, the text is in the code section
you would be overwriting the message box code   :P

Code Select Expand

DbgFoundText     db "Debugger found!",0h,20 dup(?)

PUSH 30h ; Show badboy
PUSH offset DbgFoundTitle
PUSH offset DbgFoundText
PUSH 0
CALL MessageBox

[Magnum]

It's not in the code section, just had it there to show my text.

Here is the entire code, it may be another issue.

More comments at the end to show what the code does and 2 modifications that need to be done to the P.E header.

Code Select Expand


; TLS_Callback.asm
;
; Now, clicking back in the Data Directories, double-click in the TLS Directory RVA and change it to 3046.
; Then change the TLS Size to 18. Now save the binary.
; Random,
;
.586
.model flat, stdcall
option casemap :none

include \masm32\include\windows.inc
include \masm32\include\user32.inc
include \masm32\include\kernel32.inc
include \masm32\include\comdlg32.inc

includelib \masm32\lib\user32.lib
includelib \masm32\lib\kernel32.lib
includelib \masm32\lib\comdlg32.lib

.data

DbgNotFoundTitle db "Debugger status:",0h
DbgFoundTitle    db "Debugger status:",0h
DbgNotFoundText  db "Debugger not found!",0h
DbgFoundText     db "Debugger found!",0h

; TLS Structure

dd offset StartAddress
dd offset EndAddress
dd offset AddressOfIndex
dd offset TlsCallBack

TlsCallBack     dd  offset TLS ; Address of our callback
                dd     0 ; Spacer
                dd     0       ; Spacer
StartAddress    dd     0
EndAddress     dd     0
AddressOfIndex  dd     0
TlsCallBack2    dd     offset TLS
SizeOfZeroFill  dd     0
Characteristics dd     0

.data?

TLSCalled db ? ; Flag for if TLS has been called

.code

start:

invoke ExitProcess,0 ; Main routine does nothing
ret

; TLSCallback                                                 


TLS:

CMP BYTE PTR[TLSCalled],1 ; If callback has already been run
JE @exit ; ignore it
MOV BYTE PTR[TLSCalled],1 ; Set flag for next time
CALL IsDebuggerPresent

CMP EAX,1 ; Are we being debugged?
JE @DebuggerDetected ; yes

PUSH 40h ; Show goodboy
PUSH offset DbgNotFoundTitle
PUSH offset DbgNotFoundText
PUSH 0
CALL MessageBox
JMP @exit

@DebuggerDetected:

PUSH 30h ; Show badboy
PUSH offset DbgFoundTitle
PUSH offset DbgFoundText
PUSH 0
CALL MessageBox

@exit:
RET

end start

Introduction

TLS stands for Thread Local Storage. As you probably know, threads are execution entities that run inside
of a process. Programs make use of threads when they wish to accomplish multiple actions concurrently,
even though sometimes 'concurrently' is just an illusion. For example, let's say you want to print a
document. You press the 'print' button and the program formats the document and sends it to the printer.
This activity would be run in a separate thread. The reason for this is we do not want to stop down the
entire application until the document is done printing. We want it to start the print process and then
immediately return to us, perhaps to do some work while it's printing.

If you have multiple processors, each thread can run on a separate processor. This can speed up
applications as multiple processors can be doing work at the same time. Concurrency can also benefit
from a single processor system. Take for example our print scenario above. Once the application sends the
document off to the printer, the application will sit around, waiting for the printing activity to finish.
This is a LOT of time, especially for a processor. During this waiting time, we can be doing other things.
Threads allow a processor to split up activities, and while waiting for a response from one, can be working on
another.

When these multiple threads are created, they usually share the same memory. For example, if we have
an address book application and we decide to print a contact, the print thread will begin and have access
to the main contact data. If, right after we start the print thread, we want to start another thread that begins showing the contact data on the screen (after all, the print dialog covered some of it), this new thread also has access to the contact data.

Threads access this pooled memory by calling the same addresses. In other words, thread A calls address
1000 to get the first contact, and thread B calls 1000 and gets the same data. The two addresses are the
same. But what happens when we want a thread to have it's own data? Perhaps we want the printing
thread to have a variable for if the printing was successful or not. All threads do not need to have this
variable. Therefore, this thread needs a 'local' variable, one that only that specific thread has access to.
This becomes really important when a single thread needs access to a large class or union. We do not
want every thread started to have access to such a large chunk of memory.

Windows provides a way that a thread can have it's own 'local storage'. This storage is similar to a stack,
but is only accessible to a specific thread. There is a certain chunk of memory that will be reserved for this
thread, and variables can be stored in it. This way, only this one thread has access.

We can also set up the threads so that they all have a local copy of a variable, but they all access it
through the same address. For example, we could have a count variable in every thread, and every thread
accesses it through memory location 1000. But they are all different. Even though they are all the same
address, Windows separates each thread's storage, so that location 1000 to thread A will not be the same
variable (in memory) as thread B.

This TLS storage area can be used for other, often malicious, activities. Code can be put into this TLS
section and can be run. The interesting thing about this is that the TLS code will run BEFORE the main
entry point of the binary is run. When the Windows loader first loads the binary into memory, right after it
loads in the DLLs needed, it checks a location in the PE header to see if there is a TLS section set up, and
if there is, it looks for a callback address. If one is provided, this address is called, and the code in this
section is run. After this runs, the loader then hands control over to the main application.

What all this boils down to is that when you load a binary into a debugger, often times we have the
debugger set to stop at the module's main entry point. Once our debugger has stopped here, our TLS
code has already been run. This code can do many things including checking for a debugger, infecting a
system, or formatting a hard drive. And an unwary (or unskilled) programmer will load this binary into
Olly, and before you know it, your system is infected (or worse).

You may see this behavior empirically when you load a binary into Olly and the program immediately
terminates, without ever touching any code in the actual main module. If this ever happens, your first
thought should always be check for a TLS section.



[dedndave]

still - it wouldn't hurt to declare an extra buffer for the appended text
see my previous post
DbgFoundText     db "Debugger found!",0h,20 dup(?)

[japheth]

More comments at the end to show what the code does and 2 modifications that need to be done to the P.E header.

There's no need at all to patch the PE header manually to add a TLS directory. There's an official way to make the linker add this info: define public variable _tls_used ( type IMAGE_TLS_DIRECTORY32 ).

[Magnum]

I tried this but it said "in structure."

Code Select Expand


_tls_used   IMAGE_TLS_DIRECTORY32


[qWord]

I tried this but it said "in structure."

Code Select Expand


_tls_used   IMAGE_TLS_DIRECTORY32


poor script kiddie 

[dedndave]

poor script kiddie 

lol - it's the campus, qWord   :P

Andy, try this

Code Select Expand

_tls_used IMAGE_TLS_DIRECTORY32 <>

if you want to know how it's defined, you can use the windows explorer search tool
go to the \masm32\include folder
search for files containing the text "IMAGE_TLS_DIRECTORY32"
you will see that it's defined in windows.inc
now, open windows.inc with notepad, and search for the same string

there are at least 3 ways to make it public - i'll let you figure that out   

[Magnum]

Thanks dave.

I think qWord was bullied as a kiddie and he thinks his anger is normal. 

[dedndave]

qWord and japheth are excellent coders
when you are very, very good at something, it's easy to forget what it was like when you started out

[Gunther]

Hi Dave,

qWord and japheth are excellent coders
when you are very, very good at something, it's easy to forget what it was like when you started out

but it's always good to know where you come from.

Gunther

[japheth]

I tried this but it said "in structure."

"In structure" seems not to be a known Masm error.   :icon_eek:

We're in the campus, that means you should try to express yourself in full sentences with proper citations and not use some kind of "Texas slang".

Here's a full sample how static TLS can be used: http://www.japheth.de/JWasm/Win32Tls.html

[Gunther]

Hi Andreas,

Here's a full sample how static TLS can be used: http://www.japheth.de/JWasm/Win32Tls.html

good link. Thank you.  :t

Gunther

[Magnum]

Gunther and Dave,

Don't worry about me, I have a good working example.

If someone throws out a suggestion to improve my code, then I check it out.

It's a fact of life that some folks are just miserable and don't cheerfully want to help others.

For every cranky one, there are 50 others who gladly help.

So, I stay happy and they stay unhappy.

Andy

[japheth]

Don't worry about me, ...

I don't know if Dave or Gunther are worried, but I am. It's because you're ovbviously doing stuff "beyond your league", and this means, in other words, that you're predestined to shoot yourself in the foot.

So, just see me as a somewhat strict, but nevertheless loving father who wants the best for his inexperienced and slightly ill-mannered child.