ShowProcess PROTO pid:DWORD
Core Functions I. mov pbuf, ptr$(buffer) ; cast buffer address to a pointer invoke EnumProcesses,pbuf,4096,ADDR breq ; enumerate processes shr breq, 2 ; get process cou II. invoke ShowProcess,[esi] III. mov hProcess, rv(OpenProcess,PROCESS_QUERY_INFORMATION or PROCESS_VM_READ,FALSE,pid) .if hProcess != 0 .if rv(EnumProcessModules,hProcess,ADDR hMod,4,ADDR cbNeeded) != 0 invoke GetModuleBaseName,hProcess,hMod,pbuf,260 mov ptxt, cat$(ptxt,"pid ",str$(pid)," ",pbuf) .else mov ptxt, cat$(ptxt,"pid ",str$(pid)," -fail- EnumProcessModules") .endif .else mov ptxt, cat$(ptxt,"pid ",str$(pid)," -fail- OpenProcess") .endif Core Library include \masm32\include\psapi.inc includelib \masm32\lib\psapi.lib
0 Comments
Source: http://win32assembly.programminghorizon.com/tut2.html
Windows prepares a wealth of resources for Windows programs. Central to this is the Windows API (Application Programming Interface). Windows API is a huge collection of very useful functions that reside in Windows itself, ready for use by any Windows programs. These functions are stored in several dynamic-linked libraries (DLLs) such as kernel32.dll, user32.dll and gdi32.dll. Kernel32.dll contains API functions that deal with memory and process management. User32.dll controls the user interface aspects of your program. Gdi32.dll is responsible for graphics operations. Other than "the main three", there are other DLLs that your program can use, provided you have enough information about the desired API functions. Windows programs dynamically link to these DLLs, ie. the codes of API functions are not included in the Windows program executable file. In order for your program to know where to find the desired API functions at runtime, you have to embed that information into the executable file. The information is in import libraries. You must link your programs with the correct import libraries or they will not be able to locate API functions. Source: http://win32assembly.programminghorizon.com/
The structure of a typical WASM program is as follows: 386 .MODEL Flat, STDCALL .DATA <Your initialized data> ...... .DATA? <Your uninitialized data> ...... .CONST <Your constants> ...... .CODE <label> <Your code> ..... end <label> .386 This is an assembler directive, telling the assembler to use 80386 instruction set. You can also use .486, .586 but the safest bet is to stick to .386. There are actually two nearly identical forms for each CPU model. .386/.386p, .486/.486p. Those "p" versions are necessary only when your program uses privileged instructions. Privileged instructions are the instructions reserved by the CPU/operating system when in protected mode. They can only be used by privileged code, such as the virtual device drivers. Most of the time, your program will work in non-privileged mode so it's safe to use non-p versions. .MODEL FLAT, STDCALL .MODEL is an assembler directive that specifies memory model of your program. Under Win32, there's only on model, FLAT model. STDCALL tells MASM about parameter passing convention. Parameter passing convention specifies the order of parameter passing, left-to-right or right-to-left, and also who will balance the stack frame after the function call. Under Win16, there are two types of calling convention, C and PASCAL C calling convention passes parameters from right to left, that is , the rightmost parameter is pushed first. The caller is responsible for balancing the stack frame after the call. For example, in order to call a function named foo(int first_param, int second_param, int third_param) in C calling convention the asm codes will look like this: push [third_param] ; Push the third parameter push [second_param] ; Followed by the second push [first_param] ; And the first call foo add sp, 12 ; The caller balances the stack frame PASCAL calling convention is the reverse of C calling convention. It passes parameters from left to right and the callee is responsible for the stack balancing after the call. Win16 adopts PASCAL convention because it produces smaller codes. C convention is useful when you don't know how many parameters will be passed to the function as in the case of wsprintf(). In the case of wsprintf(), the function has no way to determine beforehand how many parameters will be pushed on the stack, so it cannot do the stack balancing. STDCALL is the hybrid of C and PASCAL convention. It passes parameter from right to left but the callee is responsible for stack balancing after the call.Win32 platform use STDCALL exclusively. Except in one case: wsprintf(). You must use C calling convention with wsprintf(). .DATA .DATA? .CONST .CODE All four directives are what's called section. You don't have segments in Win32, remember? But you can divide your entire address space into logical sections. The start of one section denotes the end of the previous section. There'are two groups of section: data and code. Data sections are divided into 3 categories:
There's only one section for code: .CODE. This is where your codes reside. <label> end <label> where <label> is any arbitrary label is used to specify the extent of your code. Both labels must be identical. All your codes must reside between <label> and end <label> Source: http://win32assembly.programminghorizon.com/tut1.html
Win32 programs run in protected mode which is available since 80286. But 80286 is now history. So we only have to concern ourselves with 80386 and its descendants. Windows runs each Win32 program in separated virtual space. That means each Win32 program will have its own 4 GB address space. However, this doesn't mean every win32 program has 4GB of physical memory, only that the program can address any address in that range. Windows will do anything necessary to make the memory the program references valid. Of course, the program must adhere to the rules set by Windows, else it will cause the dreaded General Protection Fault. Each program is alone in its address space. This is in contrast to the situation in Win16. All Win16 programs can *see* each other. Not so under Win32. This feature helps reduce the chance of one program writing over other program's code/data. Memory model is also drastically different from the old days of the 16-bit world. Under Win32, we need not be concerned with memory model or segments anymore! There's only one memory model: Flat memory model. There's no more 64K segments. The memory is a large continuous space of 4 GB. That also means you don't have to play with segment registers. You can use any segment register to address any point in the memory space. That's a GREAT help to programmers. This is what makes Win32 assembly programming as easy as C. When you program under Win32, you must know some important rules. One such rule is that, Windows uses esi, edi, ebp and ebx internally and it doesn't expect the values in those registers to change. So remember this rule first: if you use any of those four registers in your callback function, don't ever forget to restore them before returning control to Windows. A callback function is your own function which is called by Windows. The obvious example is the windows procedure. This doesn't mean that you cannot use those four registers, you can. Just be sure to restore them back before passing control back to Windows. |