Видео

Initially yes, because addresses are randomized. However, if you are able to leak any address of the corresponding section during the execution, you may be able to find out the randomized address.

@RazviOverflow If you are trying an lpe and you can't get an interactive session on the binary, will ASLR and pie prevent exploitation?

@@oliverford5367 If you can't an interactive session, you must somehow be able to leak addresses from the running binary's memory sections. If you can't leak addresses during the execution, yes. ASLR/PIE prevents exploitation.

@RazviOverflow Annoying because I have found a Linux LPE 0-day that works with ASLR off

Glad you like it :)

Thank you :)

Just in case, check 23:41 - The MOVAPS issue and modify your exploit accordingly. Try again and tell us how it goes.

@@RazviOverflow hey yeah i added an extra ret statement for the stack alignment thing it didnt work either but i did the same thing with sendline in python instead of writing to a text file and sending it with < and it worked idk why thanks for the help

You are welcome, and thank you for watching

Hi there. Twitter is usually a good place to start a conversation.

@@RazviOverflow I Write :(

In case that happens, you can try jumping to adjacent addresses if they also do the job. Otherwise you'd have to find alternative solutions.

You are welcome!

You can try using other tools like objdump

Thank you :)

There's no need. Besides, which tool do you propose using?

How do you know the size of the buffer? What's its size?

@@RazviOverflow from what i understand the size buffer is 70 which we can get at rbp-0x70 and we send payload enough 70 byte right? so we not actually overflow it?

@@Ziq0012 And what about vars _4h and _8h, living at rbp-0x4 and rbp-0x8 respectively? Do they live within the buffer?

@@RazviOverflow ​ yes within the buffer it at bottom of the buffer . rbp > vars_4h >var_8h > scanf input

@@Ziq0012 How can a variable live within a buffer if it has its own type and allocated memory? What if the code is something like int a; int b; char buff[104]; Do a and b live within buff?

You are more than welcome :)

ye got the same problem, but there was .text main address which could be used as a dynamic base address. idk why it didn't show __libc_csu_init.

@@yukesh- omg same here, i have tried to fixed that for days but nothing has been like razvi himself =((((

Thank you :)

Glad you liked it :)

i have the same issue too, how can u exploit it locally?

The canary is always "before" the rbp, yes. "Before" in this context means at a lower memory address. If rbp is at, for example, 0x400, the canary is at 0x400-8

@@RazviOverflow sorry for bothering the conversation, but why when i debug it locally, using radare2 or gdb, but there is no __libc_csu? the value is just 0, why happening?

@@neverclick6520 if you are using the same binary as I did in the video, there should definitely be a __csu.

@@RazviOverflow when i tried i locally there's no a __csu, the value of %10 is 0, but when i tried it remotely, it have a value on the %10 address, im use the binary that tryhackme given, so thats why im not understand what happening

I'm not sure what binaries are you talking about, but you can place arbitrary instructions with the asm() function.

like? ​@@RazviOverflow

​@@RazviOverflowwhere i put it

@@r3plican docs.pwntools.com/en/stable/asm.html

Thank you :)

You are welcome. Yes, unfortunately cryptobros trying to scam people are flooding the internet nowadays.

Hi there. Yes, that's totally correct. Overwriting old rbp with random padding bytes implies the old stack frame (the one about to be restored with mov rsp, rbp; pop rbp) becoming invalid. Depending on what you are trying to achieve, you may or may not have to care about the state of the stack. In this case, it is irrelevant.

Thank you for your kind words. I'm happy my videos helped you :)

Thank you for your kind words ❤Glad my videos are useful to you :)

Any ret instruction would have the same effect.

You're welcome :)

Glad to receive it (again)

Glad to receive it :)

Thank you :)

You should be able to replicate the video, that's weird.

Glad to help :) Thank you for your kind words!

You are welcome :)

17:55 - Aligning the leaked address Usually the stack isn't that large. However, you can always debug and check it.

@@RazviOverflow Thanks for the tip. I ran the debugger in IDA several times (ASLR enabled) and noticed that you’re right in terms of the standard input and __libc_stack_end are always in the same page. Specifically, the offset between rbp-20h (the beginning of the buffer for standard input) and the virtual address of __libc__stack_end is always 0x148 bytes, which is good enough for a page size of 4096 bytes

If the library is loaded and you got its dynamic base address you should be able to see it.

@@RazviOverflow Thanks for the reply Razvi! The issue with the offset bits in a virtual address is that they are only 12 bits long. But you can have a starting virtual address of 0x7FABCDEF0000A000 in the text segment and a virtual address within the segment at 0x7FABCDEF0000B000. So the real offset here is not “000” but 0x1000, which is more than 12 bits.

@@rgb123-jm5mc I think I'm not fully understanding your problem. In order to get the offset, you shouldn't care about how many bits are used for this specific addressing. If you know the base address and the dynamic address, simply subtract them. Now, where does it say the offset has to be 12 bits? Could you link some docs?

@@RazviOverflow Hey Razvi, I think I might have mistaken the segment offset with page offset (lower 12 bits in virtual address). Since RUclips filters link, I found it in the first entry from the Google search “Cornell virtual address 12 bit offset”. Even though it uses 32-bit architecture, 12 bit virtual address offset is still used in 64-bit systems

@@RazviOverflow I think YT has deleted my comment for some reason, but I searched up Cornell Linux Virtual Address Offset and clicked on the first entry. Even though the webpage talks about 32-bit architecture, the offset is still 12 bits in 64-bit architecture.

I know it is, but it's worth the effort.

You are welcome :) Difficulty is something very hard to estimate. It is relative and subject to each one of us. However, I can tell you they're harder than a simple BOF. Specially pwn107, that requires you to know and understand what GOT and PLT are, and how do they work. (I have a video on that topic as well).

Thank you :) The extra ret instruction has no effect from the operational point of view, it just aligns some stuff within the stack frames. It is usually needed in ubuntu 18.04, give to the MOVAPS issue (which I briefly speak about in the ROP video)

Thank you Javier. I'm glad my videos could help you :) Gracias

What do you mean?

You are welcome, glad I could help :)

I'm not doing -shellcode, I'm doing - len(shellcode). That's because I want to pad with A's 0x50 minus the bytes of the shellcode, and I don't want to manually count them. So I use 0x50 - len(shellcode)

@@RazviOverflow Oh ok what is the purpose of subtracting 0x50 from the length of the shellcode ?

ignore me I think I figured it out.

@@davidmohan2698 No worries at all. If you still have any doubt ask me, I'll do my best to clarify it.

You are welcome

Thank you :)