Hi
.386
.model flat,stdcall
option casemap:none
include \masm32\include\windows.inc
include \masm32\include\kernel32.inc
includelib \masm32\lib\kernel32.lib
include \masm32\include\user32.inc
includelib \masm32\lib\user32.lib
include \masm32\macros\macros.asm
.data
caption db "getcurrentprocess",0
.data?
szBuffer db 16 dup (0)
.code
start:
invoke GetCurrentProcess
INVOKE wsprintf, ADDR szBuffer, SADD("Handle = %u"),eax
invoke MessageBox,NULL,addr szBuffer,addr caption,MB_OK
invoke ExitProcess,0
end start
This code not work.
Maybe try and make szBuffer a bit longer, since it needs to copy the original 'handle blah".
The buffer should be 20 bytes, but the code nevertheless works correctly for me. I would replace %u with %d.
http://msdn.microsoft.com/en-us/library/ms683179(VS.85).aspx
Quote from: sinsi on November 07, 2009, 11:38:59 AM
Maybe try and make szBuffer a bit longer, since it needs to copy the original 'handle blah".
Not good.Always Handle = 4294967295
RTFM (http://msdn.microsoft.com/en-us/library/ms683179%28VS.85%29.aspx)
GetCurrentProcess Function
Return Value
The return value is a pseudo handle to the current process.
Remarks
A pseudo handle is a special constant, currently (HANDLE)-1, that is interpreted as the current process handle. For compatibility with future operating systems, it is best to call GetCurrentProcess instead of hard-coding this constant value.
Well, fuck me. From MDSN
Quote
GetCurrentProcess
Return Value
The return value is a pseudo handle to the current process.
Remarks
A pseudo handle is a special constant, currently (HANDLE)-1, that is interpreted as the current process handle.
And your handle is 4294967295 which is -1 in 32-bit (FFFFFFFF)
This has cleared up a problem for me actually, using GetCurrentProcess then setting the affinity wouldn't work.
INVALID_HANDLE_VALUE eh?
edit: jj to the rescue! spanked heh heh
Hint: Launch Olly, and see what GetCurrentProcess does. An absolutely fascinating algo is waiting for you :green
Don't tell me - 'mov eax,-1' is it Stanley?
use OpenProcess(PROCESS_ALL_ACCESS,FALSE,GetCurrentProcessId()) to get the real process handle
Quote from: sinsi on November 07, 2009, 12:55:48 PM
Don't tell me - 'mov eax,-1' is it Stanley?
Mate, you are wasting precious space:
mov eax, -1 is a five byte instruction. Windows is lean and mean, as we all know :green
Hahaha, here it is :
755DE674 > 83C8 FF OR EAX,FFFFFFFF
755DE677 C3 RET
Sorry, 'or eax,-1' it is - even in win7 :bg
Anyway, windbg rules ok?
japeth has a nice command-line one going too...
edit: ok BV
"optimized" version...
push 0FFh
pop eax
ret
Quote from: dedndave on November 08, 2009, 04:05:05 PM
"optimized" version...
push 0FFh
pop eax
ret
Hey, it's not shorter than the MS solution...!
ahhhhhhh - thanks for pointing that out - i like that use of OR - i will have to remember that one
Also, dedndave, your "optimized" version incurs two stack pointer arithmetic operations and two memory bus access (i.e. potential cache misses), not to mention lengthy dependencies. The OR way is one single ALU uop, which can execute in half a clock cycle (or a third of one, on Core 2). Like my girlfriend says, size isn't everything (though she's probably just being nice :'( )
-r
Quote from: redskull on November 08, 2009, 07:46:09 PM
The OR way is one single ALU uop, which can execute in half a clock cycle (or a third of one, on Core 2).
After all that cruel Microsoft-bashing, finally some positive remarks: short and crispy, and fast, too! This is probably the best API call in Windows history, I think we should make it obligatory for every decent assembler proggie.