TRUE = 1 or 0b80001?

[minor28]

This is a strange thing that I can't solve.

Here is the function:

Code Select Expand


IsIpAddressAvailable proc pIpAddress:dword
local pReplyBuffer:dword
local ReplySize:dword
local SendData[32]:byte
local hIcmp:dword

invoke lstrcpy,addr SendData,ASTR("Data Buffer")
mov ReplySize,sizeof ICMP_ECHO_REPLY
add ReplySize,sizeof SendData

invoke GetProcessHeap
invoke HeapAlloc,eax,HEAP_NO_SERIALIZE,ReplySize
mov pReplyBuffer,eax

invoke IcmpCreateFile
mov hIcmp,eax
invoke StringIpAddressToDword,pIpAddress
lea edx,SendData
invoke IcmpSendEcho,hIcmp,eax,edx,sizeof SendData,0,pReplyBuffer,ReplySize,1000
invoke IcmpCloseHandle,hIcmp
mov edx,pReplyBuffer
.if dword ptr [edx].ICMP_ECHO_REPLY.Status==0 ;IP_SUCCESS
int 3
mov eax,TRUE
ret
.endif
mov eax,FALSE
ret

IsIpAddressAvailable endp


Before the if statement TRUE is always equal to 1 but after the if statement TRUE becomes 0b80001h. Even if I replace TRUE with 1  the result is 0b8001h.

Disassembled:

Code Select Expand


mov eax,0B80001h 
add byte ptr [eax],al 
add cl,cl
ret 4


If I push and pop

Code Select Expand


push TRUE
pop eax


Here TRUE is equal to 0FFFFFFB8h and disassembled as

Code Select Expand


push 0FFFFFFB8h 
add byte ptr [eax],al 
add byte ptr [eax],al
leave
ret 4


Any ideas?

[aw27]

Consider checking with a traditional disassembler, the one you are using appears a bit creative  .
If you are using the MASM SDK, TRUE EQU 1 from Windows.inc

[hutch--]

TRUE - FALSE is a boolean distinction, normally you test for ZERO which is FALSE or anything else is TRUE.

[minor28]

It is not the disassembler. I have debugged with Olly and with VS2015. Same thing with both.

Testing the return value would be true with value 0b80001h but the app crashes on disassembled line "byte ptr [eax],al". 

[aw27]

Can't be, this:

Code Select Expand


include \masm32\include\masm32rt.inc

.code

myproc proc pIpAddress:dword
.if dword ptr [edx].ICMP_ECHO_REPLY.Status==0 ;IP_SUCCESS
int 3
mov eax,TRUE
ret
.endif
mov eax,FALSE
ret

myproc endp

end


gives this:

Code Select Expand


test.obj:     file format pe-i386


Disassembly of section .text$mn:

00000000 <_myproc@4>:
   0: 55                    push   ebp
   1: 8b ec                mov    ebp,esp
   3: 83 7a 04 00          cmp    DWORD PTR [edx+0x4],0x0
   7: 75 0a                jne    13 <_myproc@4+0x13>
   9: cc                    int3   
   a: b8 01 00 00 00        mov    eax,0x1
   f: c9                    leave 
  10: c2 04 00              ret    0x4
  13: b8 00 00 00 00        mov    eax,0x0
  18: c9                    leave 
  19: c2 04 00              ret    0x4


Note that the bytecodes b8 01  are what you are stating as the value for TRUE. 

[TimoVJL]

what assembler creates that bug ?

[minor28]

Apparently it was a stack problem. Touching the stack solved it.

Thanks for your help

[jj2007]

The trained eye understands immediately what these are:

Code Select Expand

add byte ptr [eax],al 
add byte ptr [eax],al
Nullbytes

[deeR44]

Apparently it was a stack problem. Touching the stack solved it.

Thanks for your help

I have been programming in assembly since 1975 on an Altair 8800 when there was no Assembler program. We wrote our assembly programs, then hand-assembled them into machine code (octal).

At no time since those days have I ever come across the phrase "touching the stack". Is that a push, a pop, manipulating the SP and grabbing something else or going someplace other than the return on the stack? I give up, what is "touching the stack"?

[Biterider]

Hi deeR44
Google for the following keywords "Stack Probing Guard Page Allocation Window".
There are many articles out there that explain how the stack grows. AFAIK most operating systems use the same mechanism.

Regards, Biterider