Program padding

[Magnum]

If my program is 2560 bytes, does it contain 1536 zeros as padding ?

Can I put data in that area ?

4096 byes in a sector - 2560 = 1536

[FORTRANS]

Hi,

   Well no one else commented so i'll take a shot.

If my program is 2560 bytes, does it contain 1536 zeros as padding ?

Can I put data in that area ?

4096 byes in a sector - 2560 = 1536

   In the "good olde days", no zeroes.  But that depends on
the operating system and file system.  The last time I checked,
the cluster was filled with whatever was last written to it.  But
you would need to check to see what your system does.  It
could zero it out.

   Assuming that it is not being zeroed you could write your
data to the cluster, offset by your program's size, erase it,
then write your program to the same cluster.  Of course, if
your program is moved, the contents of the unused area
would not be copied.  And accessing your data will require
a low level disk access program.

   The easiest way to put data in the "wasted" area is to
append it to the end of your progam as a comment.  That
solves the need for a low level cluster access.  Oh, you could
then erase it and then write only the program to the disk
obviating the need to calculate the offset for the data and
possibly using the same directory entry.  That would happen
is some cases way back when.

   I have not looked at this for a long time.  I needed to make
sure the data was erased from the disk upon a file delete once
upon a time.  So I needed the file's clusters and erase those.
The erase and write to the same name seemed to only work
in rare cases.  There had to be no erasures since the file was
created.

   Test your system.  Should be easy if you have the tools to
find and recover such "hidden" data.  Let us know.

Regards,

Steve

[Magnum]

Thanks.

My program sets the empty areas to 0.

From 00000670 -> 000007F0 is zeroed out.

Can I have my program write to that area if I made it read/write ?

Andy

[Magnum]

This isn't working.

Code Select Expand


code

start:

; 00401005 location of next instruction

mov  eax,10
nop ; room for inserting instructions
nop
nop
mov  ebx,7

;jmp 403FA0h jmp to area where mov eax,7 is

CPU Dump
Address   Hex dump                                         ASCII

00403FA0  B8 07 EB D9|00 00 00 00|00 00 00 00|00 00 00 00|
                  mov ax,7 and jmp 403FA0

00403FB0  00 00 00 00|00 00 00 00|00 00 00 00|00 00 00 00|
00403FC0  00 00 00 00|00 00 00 00|00 00 00 00|00 00 00 00|
00403FD0  00 00 00 00|00 00 00 00|00 00 00 00|00 00 00 00|
00403FE0  00 00 00 00|00 00 00 00|00 00 00 00|00 00 00 00|
00403FF0  00 00 00 00|00 00 00 00|00 00 00 00|00 00 00 00|

    pushad
    fn MessageBox,0,str$(esi),"Test",MB_OK
    popad

   

[dedndave]

EB D9 is a relative SHORT JMP

when you change the location of the instruction, you change the location of the target
you can recalculate the address, but it may be better to use the NEAR form   
(in this case, a SHORT will work, but it may not always)

also, the destination of the code must be in a section that has a PAGE_EXECUTE_READWRITE attribute

[Magnum]

Thanks.

On another issue, am getting a conflicting parameter definition with two procedures.

The message doesn't tell me much.

Code Select Expand



Thread1 PROTO :DWORD
Thread2 PROTO :DWORD

Thread2  proc
LOCAL count2:DWORD

invoke EnterCriticalSection,ADDR stCS

.while count2 < 10

inc count2

.endw

invoke LeaveCriticalSection,ADDR stCS

Thread2 endp


[dedndave]

ok - thread procs are a bit of a strange animal, when it comes to masm syntax
masm isn't really set up for them   :P

the conflicting parameter error might be that you have a prototype that has a dword parm
yet, on the PROC line, no parm

the best way to terminate a thread is via ExitThread
thing is, you don't really want masm to create a prologue, because it will never see a RET to generate an epilogue
thus, you can have a memory leak, because the stack doesn't get balanced
this means - no PROC-line parameters and no LOCAL variables, unless you set up the stack frame yourself

thread procedures do, however, get passed a single dword parameter
and, it would seem they have a return address below that on the stack
i have seen some programmers using RET to exit a thread, but i don't think the OS does a proper clean-up

Code Select Expand

ThrdProc PROTO

;--------------------------------------------

_main   PROC

    INVOKE  CreateThread,0,0,ThrdProc,dwPassedParm,0,0

;some code

    INVOKE  ExitProcess,0

_main   ENDP

;--------------------------------------------

ThrdProc PROC

    mov     eax,[esp+4]       ;get the passed parm

;some code

    INVOKE  ExitThread,0

ThrdProc ENDP

;--------------------------------------------

        END     _main

of course, another way would be to temporarily disable prologue and epilogue generation with OPTION
seems rather silly to do all that typing, then not have a PROC-line parm or LOCAL's - lol

[MichaelW]

When this function is called (either explicitly or by returning from a thread procedure), the current thread's stack is deallocated, all pending I/O initiated by the thread is cancelled, and the thread terminates. The entry-point function of all attached dynamic-link libraries (DLLs) is invoked with a value indicating that the thread is detaching from the DLL ...

[qWord]

ok - thread procs are a bit of a strange animal, when it comes to masm syntax
masm isn't really set up for them   :P

Thread procs are clearly defined:

Code Select Expand

ThreadProc proto/proc stdcall lpParameter:LPVOID

thing is, you don't really want masm to create a prologue, because it will never see a RET to generate an epilogue
thus, you can have a memory leak, because the stack doesn't get balanced
this means - no PROC-line parameters and no LOCAL variables, unless you set up the stack frame yourself

that assumption is not correct, because ExitThread() destroy the thread object, which also includes the stack.

i have seen some programmers using RET to exit a thread, but i don't think the OS does a proper clean-up

returning from a thread proc is a implicit call to ExitThread - this is documented (see MichaelW's post).

[dedndave]

Code Select Expand

ThreadProc proto/proc stdcall lpParameter:LPVOID

it makes little sense to define the prototype that way, as the function is never invoke'd
when you call CreateThread, all you really need is the address of the PROC

as for exiting a thread via RET....
if that makes you happy, do it that way - lol

[qWord]

it makes little sense to define the prototype that way, as the function is never invoke'd

that make no sense.

[sinsi]

Code Select Expand

ThreadProc proto/proc stdcall lpParameter:LPVOID

it makes little sense to define the prototype that way, as the function is never invoke'd
when you call CreateThread, all you really need is the address of the PROC

But your proc needs a way to access lpParameter

as for exiting a thread via RET....
if that makes you happy, do it that way - lol

The MS-approved one? As documented?

...or by returning from a thread procedure...

[Magnum]

This should explain it better.

I am looking to create an example of a deadlock.

Code Select Expand


This article introduces the use of lock leveling to prevent deadlocks. Lock leveling is also known as lock ordering, lock ranking and lock hierarchies. Lock leveling always acquire the locks in relative order to prevent deadlocks. Let us look at a simple deadlock example.

void Thread1()
{
    Lock lock1(A);
    {
        Lock lock2(B);
        {...}
    }
}

void Thread2()
{
    Lock lock1(B);
    {
        Lock lock2(A);
        {...}
    }
}

If Thread1 holds lock A while waiting to hold lock B and at the same time Thread2 holds lock B while waiting to hold lock A, both threads fail to get the second lock they want, thus a deadlock occurs.



[dedndave]

there are easier ways to create dead-lock - lol
try SendMessage to the same window that it's sent from

http://msdn.microsoft.com/en-us/library/windows/desktop/ms682659%28v=vs.85%29.aspx

Remarks

ExitThread is the preferred method of exiting a thread in C code. However, in C++ code, the thread is exited before any destructors can be called or any other automatic cleanup can be performed. Therefore, in C++ code, you should return from your thread function.

they go on to list a number of caveats, which rarely seem to apply
it does, however, tell us that there is a fundamental difference between RET and ExitThread

i have had great success using ExitThread and the method shown above

oddly enough, it seems i most often use alternate threads for communications, of some sort,
where i want to allow comm to continue while the main program thread plods on

another use would be to allow the program to continue processing while waiting for some event,
such as things that might make a program appear to "hang"