hello all. i'm new to the board, so i'm not really sure where to post this question, so i figure here is as good a place as any.
i'm using inline asm with vc++ which runs a thread in a remote process that patches sections of it's memory... it's for a PROGRAM... my problem is that the code needs to search priveleged segments of the .code /.data and i would like to be able to check before a mov to see if the instruction will except. here is an example of a mov that will except:
mov ecx, 0x0010000
mov eax,
i need some way to check to see if the above will except and prevent the mov. i am aware of verr/verw, but i'm kinda new to using asm in windows/protected mode. any code example would be greatly appreciated.
thanks in advance,
sulu
i'm using inline asm with vc++ which runs a thread in a remote process that patches sections of it's memory... it's for a PROGRAM... my problem is that the code needs to search priveleged segments of the .code /.data and i would like to be able to check before a mov to see if the instruction will except. here is an example of a mov that will except:
mov ecx, 0x0010000
mov eax,
i need some way to check to see if the above will except and prevent the mov. i am aware of verr/verw, but i'm kinda new to using asm in windows/protected mode. any code example would be greatly appreciated.
thanks in advance,
sulu
Just leave the "boo-boo-words" out next time. :)
Maybe I misunderstood your question but if it's like I think it is then you want you find which sections (not segments) in the PE file which are readable/writable. Instead of scanning the whole process I would rather read the PE header and scan the section table. If you process the section table you will find out where you can read/write data and if there's any restrictions.
Iczelion's PE tutorials are good for this along with LUEVELSMEYER's document http://webster.cs.ucr.edu/Page_TechDocs/pe.txt
If this wasn't what you were thinking of maybe you should be more clear.
A linear search of the whole memory to see if a address is readable/writeable or not could take alot time. This might be worth considering depending on if your app is somewhat timecritical.
I hope this helps.
// CyberHeg
Iczelion's PE tutorials are good for this along with LUEVELSMEYER's document http://webster.cs.ucr.edu/Page_TechDocs/pe.txt
If this wasn't what you were thinking of maybe you should be more clear.
A linear search of the whole memory to see if a address is readable/writeable or not could take alot time. This might be worth considering depending on if your app is somewhat timecritical.
I hope this helps.
// CyberHeg
Thanks CyberHeg...
Your right about the PE file (I can definitely learn some new stuff from that link :) ), but I'm sorry I wasn't real clear. I'm really only looking for data that has been malloc'd: heap space. Many regions will be locked and read/write instructions will except at the default privelege level. You're definitely right about linear scans being time intensive, but I really don't see a way around it. Here is a quick example of my problem below. In this example, I have a crude dword scan for a heap value in an inline function.
void ASMCrudeDWordSearch()
{
DWORD *pVal = (DWORD *) malloc(sizeof(DWORD));
*pVal = 0x12345678;
__asm
{
// search 0x00200000 - ?? for the DWORD 0x12345678 above
search_loop_start:
mov ecx, 0x00200000
mov eax, // this will throw an exception
cmp eax, 0x12345678
jnz search_loop_start
}
free(pVal);
}
My true code is a good deal more involved, but the problem boils down to the same general principal. I need to insert some code in that loop that will bypass locked areas of memory to avoid nasty crashes. It has to be pretty simple... or maybe I'm not seeing a better solution. I'm open to any suggestions.
Thanks again,
sulu
Your right about the PE file (I can definitely learn some new stuff from that link :) ), but I'm sorry I wasn't real clear. I'm really only looking for data that has been malloc'd: heap space. Many regions will be locked and read/write instructions will except at the default privelege level. You're definitely right about linear scans being time intensive, but I really don't see a way around it. Here is a quick example of my problem below. In this example, I have a crude dword scan for a heap value in an inline function.
void ASMCrudeDWordSearch()
{
DWORD *pVal = (DWORD *) malloc(sizeof(DWORD));
*pVal = 0x12345678;
__asm
{
// search 0x00200000 - ?? for the DWORD 0x12345678 above
search_loop_start:
mov ecx, 0x00200000
mov eax, // this will throw an exception
cmp eax, 0x12345678
jnz search_loop_start
}
free(pVal);
}
My true code is a good deal more involved, but the problem boils down to the same general principal. I need to insert some code in that loop that will bypass locked areas of memory to avoid nasty crashes. It has to be pretty simple... or maybe I'm not seeing a better solution. I'm open to any suggestions.
Thanks again,
sulu
Maybe this is what you're looking for?
Edit: Oh yeah and there is "IsBadReadPtr" which works the same way
Edit: Oh yeah and there is "IsBadReadPtr" which works the same way
[b]IsBadWritePtr[/b][size=12]
The IsBadWritePtr function verifies that the calling process has write
access to the specified range of memory.
[b] BOOL IsBadWritePtr(
LPVOID[/b] [color=blue][i]lp[/i][/color], // memory address
[b]UINT_PTR[/b] [color=blue][i]ucb[/i][/color] // size of memory block
);
[b]Parameters[/b]
[i]lp[/i]
[in] Pointer to the first byte of the memory block.
[i]ucb[/i]
[in] Specifies the size, in bytes, of the memory block. If this
parameter is zero, the return value is zero.
[b]Return Values[/b]
If the calling process has write access to all bytes in the specified
memory range, the return value is zero.
If the calling process does not have write access to all bytes in the
specified memory range, the return value is nonzero.
If the application is compiled as a debugging version, and the process
does not have write access to all bytes in the specified memory range,
the function causes an assertion and breaks into the debugger. Leaving
the debugger, the function continues as usual, and returns a nonzero
value This behavior is by design, as a debugging aid.
If the calling process has write access to some, but not all, of the
bytes in the specified memory range, the return value is nonzero.
[b]Requirements[/b]
[b]Windows NT/2000/XP:[/b] Included in Windows NT 3.1 and later.
[b]Windows 95/98/Me:[/b] Included in Windows 95 and later.
[b]Header:[/b] Declared in Winbase.h; include Windows.h.
[b]Library:[/b] Use Kernel32.lib.
[/size]perfect iblis!! thanks a lot everyone :)
sulu
sulu