Tested in Windows 2000 sp2, Windows 2000 sp3 with and without IE6 sp1. Should work fine in XP and XPsp1
------------------------------
A lot of people are having troubles with System File Protection (SFP for short). This can be a major pain in the butt unless you know the tricks to it. Having only tweaked Windows 2000 Service Pack 3 I figured out a few things about SFP and replacing files:
1) TaskManger is your best friend when replacing files in 2k/XP.
When you open task manager you can do just about as much as you can do with Explorer just by going File>NewTask(Run..). From here you can either use the Run Dialog to launch programs one at a time, or select 'Browse' and explore. Using right click menu commands to do the bulk of your work (Copy, Paste, Rename). Problem is often times you can't replace items do to the fact that your browse is making calls to things you want to delete.
2) CommandLine or Cmd.exe is like that other friend you have that likes to help out.
One plus this has over TaskMan is you don't use the file you are trying to replace. A minus is that it can be a pain if you aren't an experienced DOS user.
3) Backups are your ace in the hole.
Always back your files up prior to doing anything (sometimes I don't bother and wish I did.). Keep It Simple Stupid applies here. Save yourself a few keystrokes and place your backups in something like C:\back\
4) SafeMode is the rest of the hand.
Windows2000 and XP (I believe) can both be booted into SafeMode. When your computer is first booting up, after your bios screen but before the Windows is Starting screen (I could be slightly wrong here seeing how I don't know the timing for sure.) you hit F4 or F8 to get the SafeMode menu. Select 'SafeMode with CommandPrompt'. Welcome to "DOS" on 2k/XP. Anything that can't be replaced while Windows is running can be replaced here. (url.dll) Syntax would be Copy c:\url.dll "c:\Program Files\Internet Explorer\" quotations allow you to put spaces in the path (I didn't know this)
...
Here we go. System File Protection, of Sytem File Checker is a neato feature of Windows meant to protect Joe Computeruser's PC from being ruined. When a needed System file is being replaced your File Checker says "Wait a minute this isn't mine." While this can be great in the long run, it's not a positive thing in Windows Hacking. The trick is to replace the files it uses to replace files.
...
1) First up you need to find the file you want to hack and then replace. Start>Search>Files and Folders>dllname. It's good to actually search for the file so you can find out all of the locations of all copies. Let the search finish just in case. If you have installed any service packs you will have probably have copies of the file in:
\winnt\servicepackfiles\i386\ (Win2k)
\windows\servicepackfiles\i386\ (XP)
As well as:
\winnt\system32\dllcache\ (hidden folder in Win2k)
\WINDOWS\system32\dllcache\ (hidden folder in XP)
\winnt\system32\ (win2k)
\windows\system32\ (XP)
2) Now that you have all of the locations, write them down on paper or your forehead just to be safe (backwards so it shows up in the mirror).
3) Make a backup (remember K.I.S.S.)
4) Hack your file and save it c:\ for simplicity.
5) Open TaskManger (Right click on your taskbar and select TaskManger)
6) Go to the 'Processes' Tab and find 'Explorer.exe' highlight it and push the 'End Process' button. Say Yeah to the popup.
7) Go to the first tab in TaskManger and select 'File>NewTask>Run>Browse' from this Window navigate to c:\ and higlight your hacked file. Right clic on it and select 'Copy' (don't Cut it.)
8) Nagivate to your Windows directory, open the \servicepackfiles\i386\ folder. Paste your hacked file and replace the copy that is in that folder.
9) Navigate to your respective dllcache folder, paste the file there too.
10) Replace the normail copy in system32 finally (or wherever it might be).
11) Reboot. Don't LogOff , Reboot.
Now chances are this won't go that smoothly. Either the file you want to replace is in use, or your pal and mine SFP will pop-up. It can mess with you in odd ways. I've replaced the servicepackfiles version and the dllcache files, then had SFP grab the normal and replace the other two with it. This can be frustrating. Or maybe the file is in use. This is where the Command Prompt comes into play. If you already replaced the files and rebooted to no change, launch TaskMan again, kill explorer.exe, then go 'File>NewTask>Run>Cmd.exe' Use the DOS commands to try to replace all of the copies of the file in that order using your hacked version in C:\
This is usually where you get the message from SFP telling you it's alive and kicking. You will get a rather urgent looking pop-up telling you that a file that Windows needs is being replaced by a different file. It will then ask you if you want keep the modified files. Say 'yes'. Next it will prompt you to insert your Windows cd to retrieve a copy of the file it needs. Click 'Cancel'. As a good rule of thumb, when you get this message replace what you need then reboot!
If your file still isn't changing, boot into SafeMode with CommandLine. Wait for Windows to take it's sweet time loading. Then just type copy c:\file.dll c:\winnt\servicepackfiles\i386\. Rinse and Repeat. Then reboot. This has worked for me 100% of the time, if followed it will work for you as well.
http://pixelarmy.org
21 April, 2008
Cracking Fiiles tihe easiy way
1) Don't try to modify a prog by editing his source in a dissasembler.Why?
Couse that's for programmers and assembly experts only. If any of you dumb kids
try to view it in hex you'll only get tons of crap you don't understand.
First off, you need Resource Hacker(last version).It's a resource editor-
very easy to use.
Resource Hacker Version 3.4.0
CODE
http://delphi.icm.edu.pl/ftp/tools/ResHack.zip/
Help File
CODE
http://www.users.on.net/johnson/resourceha...eshack_hlp.zip/
2)Unzip the archive, and run ResHacker.exe. You can check out the help file too,
if you want to be a guru.
3)You will see that the interface is simple and clean. Go to the menu File\Open or
press Ctrl+O to open a file. Browse your way to the file you would like to edit.
You can edit *.exe, *.dll, *.ocx, *.scr and *.cpl files, but this tutorial is ment
to teach you how to edit *.exe files, so open one.
4)In the left side of the screen a list of sections will appear.
The most common sections are: -Icon;
-String table;
-RCData;
-Dialog;
-Cursor group;
-Bitmap;
-WAV.
*Icon: You can wiew and change the icon(s) of the program by double-clicking the icon section,chossing the icon, right-clicking on it an pressing "replace resource". After that you can choose the icon you want to replace the original with.
*String table: a bunch of crap, useful sometimes, basic programming knowladge needed.
*RCData: Here the real hacking begins. Modify window titles, buttons, text, and lots more!
*Dialog:Here you can modify the messages or dialogs that appear in a program. Don't forget
to press "Compile" when you're done!
*Cursor group: Change the mouse cursors used in the program just like you would change the icon.
*Bitmap: View or change images in the programs easy!
*WAV:Change the sounds in the prog. with your own.
5) In the RCData,Dialog,Menu and String table sections you can do a lot of changes. You can
modify or translate the text change links, change buttons, etc.
TIP: To change a window title, search for something like: CAPTION "edit this".
TIP: After all operations press the "Compile Script" button, and when you're done editing save
your work @ File\Save(Save as).
TIP: When you save a file,the original file will be backed up by default and renamed to Name_original and the saved
file will have the normal name of the changed prog.
TIP: Sometimes you may get a message like: "This program has a non-standard resource layout... it has probably been compressed with an .EXE compressor." That means that Resource Hacker can't modify it becouse of it's structure.
Remember! This is only a small example of what you can do to executables with Resource Hacker.
Couse that's for programmers and assembly experts only. If any of you dumb kids
try to view it in hex you'll only get tons of crap you don't understand.
First off, you need Resource Hacker(last version).It's a resource editor-
very easy to use.
Resource Hacker Version 3.4.0
CODE
http://delphi.icm.edu.pl/ftp/tools/ResHack.zip/
Help File
CODE
http://www.users.on.net/johnson/resourceha...eshack_hlp.zip/
2)Unzip the archive, and run ResHacker.exe. You can check out the help file too,
if you want to be a guru.
3)You will see that the interface is simple and clean. Go to the menu File\Open or
press Ctrl+O to open a file. Browse your way to the file you would like to edit.
You can edit *.exe, *.dll, *.ocx, *.scr and *.cpl files, but this tutorial is ment
to teach you how to edit *.exe files, so open one.
4)In the left side of the screen a list of sections will appear.
The most common sections are: -Icon;
-String table;
-RCData;
-Dialog;
-Cursor group;
-Bitmap;
-WAV.
*Icon: You can wiew and change the icon(s) of the program by double-clicking the icon section,chossing the icon, right-clicking on it an pressing "replace resource". After that you can choose the icon you want to replace the original with.
*String table: a bunch of crap, useful sometimes, basic programming knowladge needed.
*RCData: Here the real hacking begins. Modify window titles, buttons, text, and lots more!
*Dialog:Here you can modify the messages or dialogs that appear in a program. Don't forget
to press "Compile" when you're done!
*Cursor group: Change the mouse cursors used in the program just like you would change the icon.
*Bitmap: View or change images in the programs easy!
*WAV:Change the sounds in the prog. with your own.
5) In the RCData,Dialog,Menu and String table sections you can do a lot of changes. You can
modify or translate the text change links, change buttons, etc.
TIP: To change a window title, search for something like: CAPTION "edit this".
TIP: After all operations press the "Compile Script" button, and when you're done editing save
your work @ File\Save(Save as).
TIP: When you save a file,the original file will be backed up by default and renamed to Name_original and the saved
file will have the normal name of the changed prog.
TIP: Sometimes you may get a message like: "This program has a non-standard resource layout... it has probably been compressed with an .EXE compressor." That means that Resource Hacker can't modify it becouse of it's structure.
Remember! This is only a small example of what you can do to executables with Resource Hacker.
Advanced Shell Coding Techniques
Introduction
This paper assumes a working knowledge of basic shellcoding techniques, and x86 assembly, I will not rehash these in this paper. I hope to teach you some of the lesser known shellcoding techniques that I have picked up, which will allow you to write smaller and better shellcodes. I do not claim to have invented any of these techniques, except for the one that uses the div instruction.
The multiplicity of mul
This technique was originally developed by Sorbo of darkircop.net. The mul instruction may, on the surface, seem mundane, and it's purpose obvious. However, when faced with the difficult challenge of shrinking your shellcode, it proves to be quite useful. First some background information on the mul instruction itself.
mul performs an unsigned multiply of two integers. It takes only one operand, the other is implicitly specified by the %eax register. So, a common mul instruction might look something like this:
movl $0x0a,%eax
mul $0x0a
This would multiply the value stored in %eax by the operand of mul, which in this case would be 10*10. The result is then implicitly stored in EDX:EAX. The result is stored over a span of two registers because it has the potential to be considerably larger than the previous value, possibly exceeding the capacity of a single register(this is also how floating points are stored in some cases, as an interesting sidenote).
So, now comes the ever-important question. How can we use these attributes to our advantage when writing shellcode? Well, let's think for a second, the instruction takes only one operand, therefore, since it is a very common instruction, it will generate only two bytes in our final shellcode. It multiplies whatever is passed to it by the value stored in %eax, and stores the value in both %edx and %eax, completely overwriting the contents of both registers, regardless of whether it is necessary to do so, in order to store the result of the multiplication. Let's put on our mathematician hats for a second, and consider this, what is the only possible result of a multiplication by 0? The answer, as you may have guessed, is 0. I think it's about time for some example code, so here it is:
xorl %ecx,%ecx
mul %ecx
What is this shellcode doing? Well, it 0's out the %ecx register using the xor instruction, so we now know that %ecx is 0. Then it does a mul %ecx, which as we just learned, multiplies it's operand by the value in %eax, and then proceeds to store the result of this multiplication in EDX:EAX. So, regardless of %eax's previous contents, %eax must now be 0. However that's not all, %edx is 0'd now too, because, even though no overflow occurs, it still overwrites the %edx register with the sign bit(left-most bit) of %eax. Using this technique we can zero out three registers in only three bytes, whereas by any other method(that I know of) it would have taken at least six.
The div instruction
Div is very similar to mul, in that it takes only one operand and implicitly divides the operand by the value in %eax. Also like, mul it stores the result of the divide in %eax. Again, we will require the mathematical side of our brains to figure out how we can take advantage of this instruction. But first, let's think about what is normally stored in the %eax register. The %eax register holds the return value of functions and/or syscalls. Most syscalls that are used in shellcoding will return -1(on failure) or a positive value of some kind, only rarely will they return 0(though it does occur). So, if we know that after a syscall is performed, %eax will have a non-zero value, and that the instruction divl %eax will divide %eax by itself, and then store the result in %eax, we can say that executing the divl %eax instruction after a syscall will put the value 1 into %eax. So...how is this applicable to shellcoding? Well, their is another important thing that %eax is used for, and that is to pass the specific syscall that you would like to call to int $0x80. It just so happens that the syscall that corresponds to the value 1 is exit(). Now for an example:
xorl %ebx,%ebx
mul %ebx
push %edx
pushl $0x3268732f
pushl $0x6e69622f
mov %esp, %ebx
push %edx
push %ebx
mov %esp,%ecx
movb $0xb, %al #execve() syscall, doesn't return at all unless it fails, in which case it returns -1
int $0x80
divl %eax # -1 / -1 = 1
int $0x80
Now, we have a 3 byte exit function, where as before it was 5 bytes. However, there is a catch, what if a syscall does return 0? Well in the odd situation in which that could happen, you could do many different things, like inc %eax, dec %eax, not %eax anything that will make %eax non-zero. Some people say that exit's are not important in shellcode, because your code gets executed regardless of whether or not it exits cleanly. They are right too, if you really need to save 3 bytes to fit your shellcode in somewhere, the exit() isn't worth keeping. However, when your code does finish, it will try to execute whatever was after your last instruction, which will most likely produce a SIG ILL(illegal instruction) which is a rather odd error, and will be logged by the system. So, an exit() simply adds an extra layer of stealth to your exploit, so that even if it fails or you can't wipe all the logs, at least this part of your presence will be clear.
Unlocking the power of leal
The leal instruction is an often neglected instruction in shellcode, even though it is quite useful. Consider this short piece of shellcode.
xorl %ecx,%ecx
leal 0x10(%ecx),%eax
This will load the value 17 into eax, and clear all of the extraneous bits of eax. This occurs because the leal instruction loads a variable of the type long into it's desitination operand. In it's normal usage, this would load the address of a variable into a register, thus creating a pointer of sorts. However, since ecx is 0'd and 0+17=17, we load the value 17 into eax instead of any kind of actual address. In a normal shellcode we would do something like this, to accomplish the same thing:
xorl %eax,%eax
movb $0x10,%eax
I can hear you saying, but that shellcode is a byte shorter than the leal one, and you're quite right. However, in a real shellcode you may already have to 0 out a register like ecx(or any other register), so the xorl instruction in the leal shellcode isn't counted. Here's an example:
xorl %eax,%eax
xorl %ebx,%ebx
movb $0x17,%al
int $0x80
xorl %ebx,%ebx
leal 0x17(%ebx),%al
int $0x80
Both of these shellcodes call setuid(0), but one does it in 7 bytes while the other does it in 8. Again, I hear you saying but that's only one byte it doesn't make that much of a difference, and you're right, here it doesn't make much of a difference(except for in shellcode-size pissing contests =p), but when applied to much larger shellcodes, which have many function calls and need to do things like this frequently, it can save quite a bit of space.
Conclusion
I hope you all learned something, and will go out and apply your knowledge to create smaller and better shellcodes. If you know who invented the leal technique, please tell me and I will credit him/her.
This paper assumes a working knowledge of basic shellcoding techniques, and x86 assembly, I will not rehash these in this paper. I hope to teach you some of the lesser known shellcoding techniques that I have picked up, which will allow you to write smaller and better shellcodes. I do not claim to have invented any of these techniques, except for the one that uses the div instruction.
The multiplicity of mul
This technique was originally developed by Sorbo of darkircop.net. The mul instruction may, on the surface, seem mundane, and it's purpose obvious. However, when faced with the difficult challenge of shrinking your shellcode, it proves to be quite useful. First some background information on the mul instruction itself.
mul performs an unsigned multiply of two integers. It takes only one operand, the other is implicitly specified by the %eax register. So, a common mul instruction might look something like this:
movl $0x0a,%eax
mul $0x0a
This would multiply the value stored in %eax by the operand of mul, which in this case would be 10*10. The result is then implicitly stored in EDX:EAX. The result is stored over a span of two registers because it has the potential to be considerably larger than the previous value, possibly exceeding the capacity of a single register(this is also how floating points are stored in some cases, as an interesting sidenote).
So, now comes the ever-important question. How can we use these attributes to our advantage when writing shellcode? Well, let's think for a second, the instruction takes only one operand, therefore, since it is a very common instruction, it will generate only two bytes in our final shellcode. It multiplies whatever is passed to it by the value stored in %eax, and stores the value in both %edx and %eax, completely overwriting the contents of both registers, regardless of whether it is necessary to do so, in order to store the result of the multiplication. Let's put on our mathematician hats for a second, and consider this, what is the only possible result of a multiplication by 0? The answer, as you may have guessed, is 0. I think it's about time for some example code, so here it is:
xorl %ecx,%ecx
mul %ecx
What is this shellcode doing? Well, it 0's out the %ecx register using the xor instruction, so we now know that %ecx is 0. Then it does a mul %ecx, which as we just learned, multiplies it's operand by the value in %eax, and then proceeds to store the result of this multiplication in EDX:EAX. So, regardless of %eax's previous contents, %eax must now be 0. However that's not all, %edx is 0'd now too, because, even though no overflow occurs, it still overwrites the %edx register with the sign bit(left-most bit) of %eax. Using this technique we can zero out three registers in only three bytes, whereas by any other method(that I know of) it would have taken at least six.
The div instruction
Div is very similar to mul, in that it takes only one operand and implicitly divides the operand by the value in %eax. Also like, mul it stores the result of the divide in %eax. Again, we will require the mathematical side of our brains to figure out how we can take advantage of this instruction. But first, let's think about what is normally stored in the %eax register. The %eax register holds the return value of functions and/or syscalls. Most syscalls that are used in shellcoding will return -1(on failure) or a positive value of some kind, only rarely will they return 0(though it does occur). So, if we know that after a syscall is performed, %eax will have a non-zero value, and that the instruction divl %eax will divide %eax by itself, and then store the result in %eax, we can say that executing the divl %eax instruction after a syscall will put the value 1 into %eax. So...how is this applicable to shellcoding? Well, their is another important thing that %eax is used for, and that is to pass the specific syscall that you would like to call to int $0x80. It just so happens that the syscall that corresponds to the value 1 is exit(). Now for an example:
xorl %ebx,%ebx
mul %ebx
push %edx
pushl $0x3268732f
pushl $0x6e69622f
mov %esp, %ebx
push %edx
push %ebx
mov %esp,%ecx
movb $0xb, %al #execve() syscall, doesn't return at all unless it fails, in which case it returns -1
int $0x80
divl %eax # -1 / -1 = 1
int $0x80
Now, we have a 3 byte exit function, where as before it was 5 bytes. However, there is a catch, what if a syscall does return 0? Well in the odd situation in which that could happen, you could do many different things, like inc %eax, dec %eax, not %eax anything that will make %eax non-zero. Some people say that exit's are not important in shellcode, because your code gets executed regardless of whether or not it exits cleanly. They are right too, if you really need to save 3 bytes to fit your shellcode in somewhere, the exit() isn't worth keeping. However, when your code does finish, it will try to execute whatever was after your last instruction, which will most likely produce a SIG ILL(illegal instruction) which is a rather odd error, and will be logged by the system. So, an exit() simply adds an extra layer of stealth to your exploit, so that even if it fails or you can't wipe all the logs, at least this part of your presence will be clear.
Unlocking the power of leal
The leal instruction is an often neglected instruction in shellcode, even though it is quite useful. Consider this short piece of shellcode.
xorl %ecx,%ecx
leal 0x10(%ecx),%eax
This will load the value 17 into eax, and clear all of the extraneous bits of eax. This occurs because the leal instruction loads a variable of the type long into it's desitination operand. In it's normal usage, this would load the address of a variable into a register, thus creating a pointer of sorts. However, since ecx is 0'd and 0+17=17, we load the value 17 into eax instead of any kind of actual address. In a normal shellcode we would do something like this, to accomplish the same thing:
xorl %eax,%eax
movb $0x10,%eax
I can hear you saying, but that shellcode is a byte shorter than the leal one, and you're quite right. However, in a real shellcode you may already have to 0 out a register like ecx(or any other register), so the xorl instruction in the leal shellcode isn't counted. Here's an example:
xorl %eax,%eax
xorl %ebx,%ebx
movb $0x17,%al
int $0x80
xorl %ebx,%ebx
leal 0x17(%ebx),%al
int $0x80
Both of these shellcodes call setuid(0), but one does it in 7 bytes while the other does it in 8. Again, I hear you saying but that's only one byte it doesn't make that much of a difference, and you're right, here it doesn't make much of a difference(except for in shellcode-size pissing contests =p), but when applied to much larger shellcodes, which have many function calls and need to do things like this frequently, it can save quite a bit of space.
Conclusion
I hope you all learned something, and will go out and apply your knowledge to create smaller and better shellcodes. If you know who invented the leal technique, please tell me and I will credit him/her.
