Skip to content

Lab 10 64bit#172

Open
Expooo7 wants to merge 5 commits intocs-pub-ro:mainfrom
Expooo7:lab-10-64bit
Open

Lab 10 64bit#172
Expooo7 wants to merge 5 commits intocs-pub-ro:mainfrom
Expooo7:lab-10-64bit

Conversation

@Expooo7
Copy link
Copy Markdown

@Expooo7 Expooo7 commented Apr 8, 2026

Prerequisite Checklist

  • Read the contribution guidelines regarding submitting new changes to the project;
  • Tested your changes against relevant architectures and platforms;
  • Updated relevant documentation (if needed).

Description of changes

Ported all tasks to 64 bits, updated READMEs with relevant info, fixed inconsistencies.
Bugs still present in overflow-for-binary and overwrite-ret-addr which don't allow the checker to work properly.
also fixed #115 as part of this PR.
Fix #142

@Expooo7 Expooo7 force-pushed the lab-10-64bit branch 3 times, most recently from 4207baf to 3293417 Compare April 9, 2026 14:49
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>
Expooo7 added 4 commits April 9, 2026 18:42
	- 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

labs/lab-10: Check x86_64 version labs/lab-10: Modify checkers for read-stdin tasks

1 participant