Prev: ml.exe
Next: beginner asm, where next?
From: "//o//annabee Free" " on 19 Jan 2007 23:57
P� Sat, 20 Jan 2007 01:21:43 +0100, skrev swishhh <dungspace(a)gmx.de>:

> Hi!
>
> I have the problem, that my EAX sometimes points on a unreadable area,
> because it is unallocated or the program has not the right.
>
> I call a function of a DLL. The returned value in EAX shall point to a
> structure. When the function fails, it returns a value, which points on
> a unreadable area. Trying to access [EAX] fails. Is there a possibility
> to check - without 'SetUnhandledExceptionFilter' - if EAX points on a
> readable value? Is there a test flag??

> I would not really like to use exception handeling, because it slows
> the application down. I CAN NOT use a different DLL.

Can you ask the people who made the DLL?

Exception handling is not extremly slow.
There was posted some exeption handling asm code, at RosAsm board a while
ago.
By Bob Edwards. I have tested them, and they does not slow down anything
at all.

If that doesnt work You could try to make a little application in RosAsm,
to call the DLL, and see if the runtime-debugger will step also the DLL
code. It often will be able to. Then if that doesnt help, you can try to
reassemble the DLL with RosAsm, and take a look at the code. If that
fails, you can try to guess at what kind of ranges of memory are normally
returned, and just test some lower and upperlimits. Check the first
successful one for instance, and compare it by hand to the illegal address.

And if all of that fails, reread any documentation, more closesly then
before. Then reread your code more closly, and maybe it turns out it was
just a misunderstanding on your part.(Happens to me a lot).

> Thanks,
>
> Sasha Gunthers
>

From: "//o//annabee Free" " on 20 Jan 2007 00:10
P� Sat, 20 Jan 2007 04:57:47 +0100, skrev santosh <santosh.k83(a)gmail.com>:

> swishhh wrote:
>> Hi!
>>
>> I have the problem, that my EAX sometimes points on a unreadable area,
>> because it is unallocated or the program has not the right.
>>
>> I call a function of a DLL. The returned value in EAX shall point to a
>> structure. When the function fails, it returns a value, which points on
>> a unreadable area. Trying to access [EAX] fails. Is there a possibility
>> to check - without 'SetUnhandledExceptionFilter' - if EAX points on a
>> readable value? Is there a test flag??
>>
>> I would not really like to use exception handeling, because it slows
>> the application down. I CAN NOT use a different DLL.
>
> Look up the docs on msdn.com. There're functions named isValidPtr() or
> something to that effect which check your pointer's value for
> deferencability.

That will maybe be slower then an exception handler, I think. I never
tried it, but I read some doc somewhere saying it could be very slow.

From: "//o//annabee Free" " on 20 Jan 2007 00:32
På Sat, 20 Jan 2007 05:47:41 +0100, skrev David Jones <ncic(a)tadmas.com>:

> IsBadReadPtr isn't a good idea.
>
> http://blogs.msdn.com/larryosterman/archive/2004/05/18/134471.aspx
> http://blogs.msdn.com/oldnewthing/archive/2006/09/27/773741.aspx
>
> David

"By calling IsBadReadPtr in your API, you've turned an easily identifiable
application bug into a really subtle stack overflow bug that may not be
encountered for many minutes (or hours) later."

How could it take hours or even minutes to discover a stackoverflow bug?
From: robertwessel2 on 20 Jan 2007 03:02

//\\o//\\annabee <Free" wrote:
> På Sat, 20 Jan 2007 05:47:41 +0100, skrev David Jones <ncic(a)tadmas.com>:
>
> > IsBadReadPtr isn't a good idea.
> >
> > http://blogs.msdn.com/larryosterman/archive/2004/05/18/134471.aspx
> > http://blogs.msdn.com/oldnewthing/archive/2006/09/27/773741.aspx
> >
> > David
>
> "By calling IsBadReadPtr in your API, you've turned an easily identifiable
> application bug into a really subtle stack overflow bug that may not be
> encountered for many minutes (or hours) later."
>
> How could it take hours or even minutes to discover a stackoverflow bug?


One of major problems with the IsBadXxxPtr() functions is that they can
cause the access exception for a stack guard page to be eaten if you
try validating a bad pointer that happens to point to a guard page.
Then when the stack does grow to the point where it hits the guard
page, the guard page does not trigger the correct sort of exception and
instead of growing the stack (the normal result of hitting the guard
page), the OS gets an access violation and the application abends.

To the OP: The IsBadXxxPtr() functions provide, at best, an illusion
of doing what you want. It is very, very, common that a bad pointer is
pointing at memory that exists, in which case the IsBad functions will
do precisely nothing. This memory may (and very commonly *does*) exist
even if it's not a currently malloc()'d piece of memory (or whatever
your heap management primitive is called), since the heap will
typically retain memory allocated from the OS for a long time even if
the area is freed. You can't even reliably walk the heap (assuming
you're using a heap which exposes an API or something that allows you
to do that), since a bad pointer can easily be pointing into a
malloc()'d bit of memory, and still be completely wrong.

In short, validating a pointer based on nothing more than OS page
allocation and the heap manager is essentially impossible. While you
may make some protection faults go away, you're probably replacing them
with some storage corruptions, which is usually a pretty bad trade off.

From: japheth on 20 Jan 2007 08:15

> I would not really like to use exception handeling, because it slows
> the application down. I CAN NOT use a different DLL.

Exception handling in Win32 is not slow, and with ASM it is even
trivial. Here's an example:

testmem proc pMem:ptr

xor edx, edx
push offset exception_occured
push fs:[edx]
mov fs:[edx], esp

mov eax,1 ;1 means error (IsBadReadPtr() emulation)!
mov ecx, pMem
mov dl,[ecx]
dec eax ;this code runs only if no exception occured
done:
xor edx, edx
pop fs:[edx]
pop ecx ;adjust stack (offset exception)
ret
exception_occured:
mov eax, [esp+12] ;get context pointer
mov [eax].CONTEXT.rEip, offset done
xor eax, eax ;== _XCPT_CONTINUE_EXECUTION
retn
testmem endp

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: ml.exe
Next: beginner asm, where next?