Making system calls in Windows shellcode is a little more complicated. On the UNIX
side, using an int 0x80 requires little more than placing the proper values in specific registers
or on the stack before executing the int 0x80 instruction. At that point the operating
system takes over and does the rest. By comparison, the simple fact that our shellcode is
required to call a Windows function in order to access system services complicates matters
a great deal. The problem boils down to the fact that while we certainly know the name of
the Windows function we wish to call, we do not know its location in memory (if indeed
the required library is even loaded into memory at all!). This is a consequence of the fact
that these functions reside in dynamically linked libraries (DLLs), which do not necessarily
appear at the same location on all versions of Windows, and which can be moved to
new locations for a variety of reasons, not the least of which is Microsoft-issued patches.
As a result, Windows shellcode must go through a discovery process to locate each function
that it needs to call before it can call those functions. Here again the Last Stage of
Delirium has written an excellent paper entitled ???Win32 Assembly Components??? covering
the various ways in which this can be achieved and the logic behind them.
Pages:
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383