This shows you the differences between two versions of the page.
cns:labs:lab-02 [2020/10/26 14:08] razvan.deaconescu [6. Smash the Stack] |
cns:labs:lab-02 [2022/10/17 19:18] (current) mihai.dumitru2201 [2. Shellcode] |
||
---|---|---|---|
Line 780: | Line 780: | ||
All content necessary for the CNS laboratory tasks can be found in [[cns:resources:repo|the CNS public repository]]. | All content necessary for the CNS laboratory tasks can be found in [[cns:resources:repo|the CNS public repository]]. | ||
+ | |||
+ | Submit your flags to [[https://cns-lab-ctf21.cyberedu.ro/|the CNS CyberEDU Platform]]. | ||
===== 1. Position independent executables ==== | ===== 1. Position independent executables ==== | ||
Line 862: | Line 864: | ||
- How do we actually use the data from this .o file? What symbols are exported? | - How do we actually use the data from this .o file? What symbols are exported? | ||
* <code> | * <code> | ||
- | $ readelf -s ./mycode.bin.o | + | $ nm ./mycode.bin.o |
0000000000000035 D _binary___mycode_bin_end | 0000000000000035 D _binary___mycode_bin_end | ||
0000000000000035 A _binary___mycode_bin_size | 0000000000000035 A _binary___mycode_bin_size | ||
Line 881: | Line 883: | ||
- The stack is still executable, remove this flag! | - The stack is still executable, remove this flag! | ||
* ''execstack -c ./my'' | * ''execstack -c ./my'' | ||
+ | |||
+ | <note> | ||
+ | If you're missing the ''execstack'' binary on the Kali VM (or on any Debian-based distribution), manually download and install it: | ||
+ | |||
+ | <code> | ||
+ | # curl -LO http://ftp.de.debian.org/debian/pool/main/p/prelink/execstack_0.0.20131005-1+b10_amd64.deb | ||
+ | # dpkg -i execstack_0.0.20131005-1+b10_amd64.deb | ||
+ | </code> | ||
+ | |||
+ | If installation freezes, cancel it then try again. | ||
+ | |||
+ | </note> | ||
+ | |||
- Why does ''execstack -c ./*.o'' throw an error? | - Why does ''execstack -c ./*.o'' throw an error? | ||
* ''execstack'' has to have information about the segments, information which is only available after the linking process | * ''execstack'' has to have information about the segments, information which is only available after the linking process | ||
Line 1017: | Line 1032: | ||
==== 5. Memory Dump Analysis ==== | ==== 5. Memory Dump Analysis ==== | ||
- | Using your newfound voodoo skills you are now able to tackle the following task. In the middle of two programs I added the following lines: | + | Let's consider the way programs run. |
+ | Consider the length of addresses for a given system and note that: | ||
+ | * there is a 3GB / 1GB user-mode / kernel-mode split for an i386 system | ||
+ | * that split is not the case for a 32bit program running on 64bits, it uses the entire 4GB of required virtual page | ||
+ | |||
+ | In the middle of two programs I added the following lines: | ||
<code c> | <code c> | ||
Line 1095: | Line 1115: | ||
==== 7. GDB ==== | ==== 7. GDB ==== | ||
- | * Use GDB and PEDA to run the code provided from ''07-bash-login''. The executable gets input from the user and evaluates it against a static condition. If it succeeds it then calls a ''password_accepted'' function that prints out a success message and spawns a shell. Try to not use a decompiler. | + | |
+ | Use GDB and PEDA to run the code provided from ''07-bash-login/''. The executable gets input from the user and evaluates it against a static condition. If it succeeds it then calls a ''password_accepted'' function that prints out a success message and spawns a shell. Try to not use a decompiler. | ||
Your task is to use GDB and PEDA to force the executable to call the ''password_accepted'' function. | Your task is to use GDB and PEDA to force the executable to call the ''password_accepted'' function. |