Open
Conversation
4207baf to
3293417
Compare
labs/lab-10/data_buffer: ported data_buffer task to x64
labs/lab-10/stack-buffer: updated README for x64 bits
- Changed 32-bit regs to 64-bit versions.
- Added explanations for `part 3` of the exercise,
- changed from `mov byte [ebx + TODO], TODO` to `mov dword [rbx + TODO],
TODO`. We are writing an integer, so dword seems appropriate.
labs/lab-10/stack-buffer: ported task to x64
- simple changes to register names + x64 calling conventions
labs/lab-10/stack-buffer: ported solution to x64:
- simple changes to register names + x64 calling conventions
- to solve todo3 it's the same like before, just use 64 bit registers in
base+offset calculation.
- to solve todo2 we need to print 84 bytes instead of 76 bytes, because
the return stack frame and return address are 8 bytes instead of 4.
labs/lab-10/stack-buffer: fixed checker
- Now checks for 84 bytes length instead of 76 bytes length. This is
because old stack frame and return address are now 8 bytes instead of 4
bytes.
labs/lab-10: updated payload from 4byte int to 8byte long
- Changed the flag, we are on 64 bits so lets use some long long
vars
- Added extra explanations in support/exploit.py to help the
student with strings in python
labs/lab-10/overflow-for-binary: Updated source file, makefile, README and the binary for the exercise to 64bits
- Makefile: removed 32bit flags
- overflow_in_binary.c: changed flag to 8 bytes long long,
changed win/lose printfs,
removed the random line of code (exercise is already pretty difficult)
- overflow-for-binary: compiled the new binary (without -g
flags)
labs/lab-10/overflow-for-binary: update checker to check for different print string for "win" case
- now the checker checks for "VICTORY!!!" instead of "Great success!"
labs/lab-10/overflow-for-binary: Update README file in solution/ , not final
- When porting this ex to x64, ghidra seems to analyze the
binary in a weird way. e.g. variable named `local10`
is at the position of `stack - 10 bytes` in x86, but in
x64 `local10` is `stack - 8 bytes`.
- analyzing the binary with `objdump -d -M intel` leads to more
accurate results and is preferrable
- Consider moving this to support/ folder? What is the point of
the README if it doesn't help you solve the exercise?
labs/lab-10/read-stdin-gets: ported exercise to x64
- source file: Changed .asm file to x64 calling conventions and register
names, added some useful explanations
- Makefile: removed 32bit flags
- exploit.py: added helpful explanations for strings in python
labs/lab-10/read-stdin-gets: Updated README
- changed payload creation command from python2.7 to python3
because nobody uses python2.7
- replaced 'gedit' with 'nano'
labs/lab-10/read-stdin-fgets: port task and README to x64
- Change calling conventions and register names in .asm files
- remove 32bit flags from Makefiles
- change comments about 32bit calling conventions to 64bit
calling conventions in the README
labs/lab-10/overflow-in-c: added .asm and binary file as specified in README
- In task README it says a binary and an .asm file would be
already present, so I removed the .gitignore rule that was
blocking that
labs/lab-10/overflow-in-c: upated READMEs with x64 register names and more appropriate
comments regarding 64bit executables
labs/lab-10/overflow-in-c: change payload to new payload in script and .txt
labs/lab-10/overflow-in-c: small modif in source file and remove 32bit
flag from makefile
- do_overflow.c: add more padding to make the presence of this
buffer more significant, if only 5 byte size of padding then
it's completely pointless. The padding added by the compiler
(even without the presence of `in_between[5]`) eclipses
`in_between[5]`, so we make it `in_between[25]`
- remove `-m32` flag from CC
labs/lab-10/overwrite-ret-addr: updated solution/README to x64, created
support/README to help the student complete task, updated python files
- python files changed to fit the new sizes on the x64 stack
- added helpful comments and tips in python files
- added new support/README to help the student with this
unfamiliar workflow of analyzing binaries
- changed solution/README to fit x64 conventions
maybe consider deleting the solution/README and putting everything in
support/README? P.S.: on the page online lab page on cs-pub-ro.github.io
you can see the `writeup` which is solution/README (even if during the
lab you would not want to get the solution spoiled)
labs/lab-10/overwrite-ret-addr: removed 32bit flags from Makefile
labs/lab-10/overwrite-ret-addr: bug present in break_this.c, compiled
binary
- The buffer overflow works correctly, the return addr is
changed and the program flow goes into `magic_function`, but
it does not execute the system("cowsay...") part.
- I placed a `puts("hi mom")` to show the function gets called
- I do have cowsay installed on the system
labs/lab-10: fixed read-stdin-gets & read-stdin-fgets checkers
- instead of checking exit code of python script as suggested,
changed the test_read_stdin_fgets.c test to pass if the
hard-coded string `var is 0x...` is found.
Before it checked to see if `CAFEBABE` (the initial value that
the task asks us to change) was not part of output
and in that case pass the test.
- I don't find it necessary to check python exit code in test.
If the target .asm file does not compile (as mentioned in the
issue) the test will not pass now.
Fixes cs-pub-ro#115
labs/lab-10/overwrite-ret-addr: change elf32 to elf64 in Makefile
labs/lab-10: Remove whitespaces for linter, remove overflow_in_c/ binary
and .asm files
- let the student compile on their machine with `make`, this
shouldn't be a problem with x64 libs
Signed-off-by: Berevoesu Remus-Napoleon <berevoescu.remus@gmail.com>
- for passing markdownlint CI Signed-off-by: Berevoesu Remus-Napoleon <berevoescu.remus@gmail.com>
- one more .md file with markdownlint - all python files with black formatter Signed-off-by: Berevoesu Remus-Napoleon <berevoescu.remus@gmail.com>
- flag is again a 4 byte variable. Will be easier for students to logic about that with 8 byte variable. - added a padding variable before the flag. now the null-byte terminator which `strcpy` spawns won't overwrite the old stack frame and cause segmentation faults or other problems - chose a new value for the flag (`GPT5`) and updated scripts accordingly - other linters Signed-off-by: Berevoesu Remus-Napoleon <berevoescu.remus@gmail.com>
Signed-off-by: Berevoesu Remus-Napoleon <berevoescu.remus@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Prerequisite Checklist
Description of changes
Ported all tasks to 64 bits, updated READMEs with relevant info, fixed inconsistencies.
Bugs still present in
overflow-for-binaryandoverwrite-ret-addrwhich don't allow the checker to work properly.also fixed #115 as part of this PR.
Fix #142