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
Hi,
Well no one else commented so i'll take a shot.
Quote from: Magnum on March 16, 2013, 04:30:42 AM
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
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
This isn't working.
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
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 :biggrin:
(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
Thanks.
On another issue, am getting a conflicting parameter definition with two procedures.
The message doesn't tell me much.
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
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
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
Quote from: PSDK ExitThread documentation
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 ...
Quote from: dedndave on March 17, 2013, 01:26:09 PM
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:
ThreadProc proto/proc stdcall lpParameter:LPVOIDQuote from: dedndave on March 17, 2013, 01:26:09 PMthing 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.
Quote from: dedndave on March 17, 2013, 01:26:09 PM
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).
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
Quote from: dedndave on March 17, 2013, 02:07:30 PMit makes little sense to define the prototype that way, as the function is never invoke'd
that make no sense.
Quote from: dedndave on March 17, 2013, 02:07:30 PM
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
Quote from: dedndave on March 17, 2013, 02:07:30 PM
as for exiting a thread via RET....
if that makes you happy, do it that way - lol
The MS-approved one? As documented?
Quote...or by returning from a thread procedure...
This should explain it better.
I am looking to create an example of a deadlock.
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.
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 (http://msdn.microsoft.com/en-us/library/windows/desktop/ms682659%28v=vs.85%29.aspx)
QuoteRemarks
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"