Difference between revisions of "User:Hatter/Windows Shellcode"
(Created page with "{{code|text=<source lang="asm"> find_kernel32: pushad ; preserve all registers xor ecx, ecx ...") |
m (moved Windows Shellcode to User:Hatter/Windows Shellcode) |
||
| (4 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| + | =Basic Code Concepts= | ||
| + | blah blah blah compatibility problems blah | ||
| + | |||
| + | Self-linking shellcode refers to machine code's ability to use what functions are already present in memory as opposed to carrying all of its functionality within itself. From a general | ||
| + | perspective, a linker is comprised of two parts. One part of the linker must be able to isolate the base pointer of any given library loaded into memory, and the other part of the linker must be able to parse the library and return the memory address/pointer for the start of any given function. | ||
| + | |||
| + | This is called self-linking shellcode or self-linking machine code because it does not rely on being linked with any kernel, in stead it finds the functionality it needs within the run-time environment and calls already existing functions out of memory. This will save the programmer time and size, and potentially even allow the programmer to write a cross-OS machine code application that is fully capable of using pre-built-in functionality of the operating system by linking itself in stead of relying on an external linker to both link and format the binary properly. | ||
| + | |||
| + | ==Finding Libraries and Modules== | ||
{{code|text=<source lang="asm"> | {{code|text=<source lang="asm"> | ||
find_kernel32: | find_kernel32: | ||
| Line 5: | Line 14: | ||
mov esi, [fs:ecx + 0x30] | mov esi, [fs:ecx + 0x30] | ||
mov esi, [esi + 0x0C] | mov esi, [esi + 0x0C] | ||
| − | mov esi, [esi + 0x1C] | + | mov esi, [esi + 0x1C]</source>}} |
| − | + | ||
| + | |||
| + | {{code|text=<source lang="asm"> next_module: | ||
mov ebx, [esi + 0x08] | mov ebx, [esi + 0x08] | ||
mov edx, [esi + 0x20] | mov edx, [esi + 0x20] | ||
| Line 14: | Line 25: | ||
mov [esp + 0x1c], ebx | mov [esp + 0x1c], ebx | ||
popad | popad | ||
| − | ret | + | ret</source>}} |
| − | + | ||
| + | ==Isolating Functions== | ||
| + | |||
| + | |||
| + | {{code|text=<source lang="asm"> | ||
| + | linkme: | ||
pushad | pushad | ||
mov ebp, [esp + 0x24] | mov ebp, [esp + 0x24] | ||
| Line 23: | Line 39: | ||
mov ecx, [edx + 0x18] | mov ecx, [edx + 0x18] | ||
mov ebx, [edx + 0x20] | mov ebx, [edx + 0x20] | ||
| − | add ebx, ebp | + | add ebx, ebp</source>}} |
| + | |||
| + | |||
| + | {{code|text=<source lang="asm"> | ||
find_function_loop: | find_function_loop: | ||
jecxz find_function_finished | jecxz find_function_finished | ||
dec ecx | dec ecx | ||
mov esi, [ebx + ecx * 4] | mov esi, [ebx + ecx * 4] | ||
| − | add esi, ebp | + | add esi, ebp</source>}} |
| + | |||
| + | |||
| + | {{code|text=<source lang="asm"> | ||
compute_hash: | compute_hash: | ||
xor edi, edi | xor edi, edi | ||
| Line 45: | Line 67: | ||
mov ebx, [edx + 36] | mov ebx, [edx + 36] | ||
add ebx, ebp | add ebx, ebp | ||
| − | mov cx, [ebx + 2 * ecx] | + | mov cx, [ebx + 2 * ecx] |
mov ebx, [edx + 28] | mov ebx, [edx + 28] | ||
add ebx, ebp | add ebx, ebp | ||
| Line 54: | Line 76: | ||
popad | popad | ||
ret</source>}} | ret</source>}} | ||
| + | ==Implementations== | ||
| + | |||
| + | =Some Simple Shellcodes= | ||
Latest revision as of 06:16, 7 April 2012
Contents
Basic Code Concepts
blah blah blah compatibility problems blah
Self-linking shellcode refers to machine code's ability to use what functions are already present in memory as opposed to carrying all of its functionality within itself. From a general perspective, a linker is comprised of two parts. One part of the linker must be able to isolate the base pointer of any given library loaded into memory, and the other part of the linker must be able to parse the library and return the memory address/pointer for the start of any given function.
This is called self-linking shellcode or self-linking machine code because it does not rely on being linked with any kernel, in stead it finds the functionality it needs within the run-time environment and calls already existing functions out of memory. This will save the programmer time and size, and potentially even allow the programmer to write a cross-OS machine code application that is fully capable of using pre-built-in functionality of the operating system by linking itself in stead of relying on an external linker to both link and format the binary properly.
Finding Libraries and Modules
find_kernel32:
pushad ; preserve all registers
xor ecx, ecx
mov esi, [fs:ecx + 0x30]
mov esi, [esi + 0x0C]
mov esi, [esi + 0x1C]
|
next_module: mov ebx, [esi + 0x08] mov edx, [esi + 0x20] mov esi, [esi] cmp [edx + 12 * 2], cx jne short next_module mov [esp + 0x1c], ebx popad ret |
Isolating Functions
linkme:
pushad
mov ebp, [esp + 0x24]
mov eax, [ebp + 0x3c]
mov edx, [ebp + eax + 0x78]
add edx, ebp
mov ecx, [edx + 0x18]
mov ebx, [edx + 0x20]
add ebx, ebp
|
find_function_loop:
jecxz find_function_finished
dec ecx
mov esi, [ebx + ecx * 4]
add esi, ebp
|
compute_hash:
xor edi, edi
xor eax, eax
cld
compute_hash_again:
lodsb
test al, al
jz compute_hash_finished
ror edi, 0xd
add edi, eax
jmp compute_hash_again
compute_hash_finished:
cmp edi, [esp + 0x28]
jnz find_function_loop
mov ebx, [edx + 36]
add ebx, ebp
mov cx, [ebx + 2 * ecx]
mov ebx, [edx + 28]
add ebx, ebp
mov eax, [ebx + 4 * ecx]
add eax, ebp
mov [esp + 0x1c], eax
find_function_finished:
popad
ret
|
