yes, great job indeed! Although, personnally, I think you started to "shout" a bit more than before, compared to your ctf and koth videos. You and your content are interesting, no need for extra emphasis :) Thanks a lot for all you do!
I remeber like 7 years ago i finally found out that the million buffer overflow explanations all over the internet dont explain DEP so i found out about ROP and sucessfully wrote a ROP exploit for a program i actually used regularly. Was very proud of that
Just a quick note that Apple has that mitigation (PAC) since 4/5 years at least, but they're still pwning it (also if it's one of the most difficult target)
im brand new to programming although ive wanted to learn for many years, and i barely understand any of this but it's fun to watch anyway. thanks john!
It would be interesting to see if AMD or any other ARM CPUs are able to have something similar. Is there a way to look into the part that is actually blocking the ROP?
I have been wondering lately whether or not we will always be able to come up with automatic mitigations, and tbh unless we can get true ai that actually understands what is happening to the system and whether or not said actions are legit then i honestly think hackers will eventually win essentially it boils down to the fact that are so many more ways to misuse a system
I think it would be nice in general to also talk about Apple M chips, which people say that's the best thing that's happened to humankind! I'm super curious to know if, security wise, it lives up to the hype
12:08 If CET prevents modifications to the stack by comparing it to the shadow stack, how would it tell the difference if the program itself is trying to make those modifications? would CET prevent the program itself from modifying its own stack? or would it identify that the instruction came from the program's own set of instructions/code space? if so, how would it tell that the program initiated the instruction and not ROP (ROP using the program's own instructions to modify its own stack)? or if the program was coerced in some other way? My point is, how can Intel infer what the programmer intended without telepathy?! Parse the code maybe, but that assumes the programmer is competent. Maybe they are, maybe they're not. It's not guaranteed. It also assumes the programmer is not malicious. I suspect the answers to these questions is the magic sauce that makes it work and they don't want threat actors to know. As was stated in the video, "security is a cat and mouse game" (0:59).
Most programs don't modify the return pointer, which is what I imagine the shadow stack would be comparing. I have seen some programs use a modified return pointer, but I don't think it uses the dame return pointer that's on the stack. Would be interesting though. I know elden ring and dark souls 3 use this kind of obfuscation. I'm sure they still run fine on this, though?
I would also take into consideration that the shadow stack knows what's already on the stack, and can detect that a buffer was overflown after a call is executed, since stuff on the stack would be changed, when it shouldn't have (I.E. a call to memcpy to copy over some data to a buffer, and after that return, the stack for the current frame, has changed.
hey john is it still worth the time learning ROP today? I really wanted to learn it but if it is not relevant anymore i will not learn it. how widespread are these intel systems?
Seeing intel sponsoring the videos is weird and stinks When it comes down to corporations, I think I'll pick the old poison I'm familiar with over the one trying a new trick to look nice
Every new feature brings in new flaws. Soon, You will hear researchers finding out ways to push modified return address in the shadow stack. Not sure tho
Not applicable for pen testing. This more for exploit dev. Plus there are CET bypass using COOP on c++. Overall your goal as a ethical hacker (offesive/red team) is to work your self out of a job.
RIP ROP. That kinda has a nice ring to it
I said this out loud the second I read the title
This one feels so much more natural than the 1st vPro video.
Keep up the amazing work John!
yes, great job indeed! Although, personnally, I think you started to "shout" a bit more than before, compared to your ctf and koth videos. You and your content are interesting, no need for extra emphasis :)
Thanks a lot for all you do!
thinking back about this, I guess you must do what you must considering the sponsor, and you must put bread on that table. Keep it up, gold content.
I remeber like 7 years ago i finally found out that the million buffer overflow explanations all over the internet dont explain DEP so i found out about ROP and sucessfully wrote a ROP exploit for a program i actually used regularly. Was very proud of that
The most convincing promotion the world ever seen!
Cool vid, John!
Just a quick note that Apple has that mitigation (PAC) since 4/5 years at least, but they're still pwning it (also if it's one of the most difficult target)
Nice video!!!
I would love to see more videos about binary explotation (or other more advanced topics) in the future.
Ok, and next a video that explains how CET actually works? 🤗
im brand new to programming although ive wanted to learn for many years, and i barely understand any of this but it's fun to watch anyway. thanks john!
ROP will never be dead.
I am to far behind for this video. Still find it interesting though. Looking forward to learning more to get to this point.
Vpro currently conquering.. rop 🥀⚰️
Wow. That is quite something. Nice job from Intel.
How does this stand in terms of overhead? Are program execution times considerably slower?
This Intel video makes me want to buy intel , I watched 100s of Linus videos spewing intel ads and never wanted to but it. You got me sold.
It would be interesting to see if AMD or any other ARM CPUs are able to have something similar. Is there a way to look into the part that is actually blocking the ROP?
let's goooo 💜
Really loved, but is hard to understand
I have been wondering lately whether or not we will always be able to come up with automatic mitigations, and tbh unless we can get true ai that actually understands what is happening to the system and whether or not said actions are legit then i honestly think hackers will eventually win essentially it boils down to the fact that are so many more ways to misuse a system
Love your work John ❤️
I think it would be nice in general to also talk about Apple M chips, which people say that's the best thing that's happened to humankind!
I'm super curious to know if, security wise, it lives up to the hype
lol no, it doesn't.
@@RealILOVEPIE Can you elaborate ?
Does that mean that servers running the AMD "Threadripper" or "Epyc"-architecture, are still vulnerable for ROP instructions ?
Probably unless they have something similar
12:08 If CET prevents modifications to the stack by comparing it to the shadow stack, how would it tell the difference if the program itself is trying to make those modifications? would CET prevent the program itself from modifying its own stack? or would it identify that the instruction came from the program's own set of instructions/code space? if so, how would it tell that the program initiated the instruction and not ROP (ROP using the program's own instructions to modify its own stack)? or if the program was coerced in some other way?
My point is, how can Intel infer what the programmer intended without telepathy?! Parse the code maybe, but that assumes the programmer is competent. Maybe they are, maybe they're not. It's not guaranteed. It also assumes the programmer is not malicious.
I suspect the answers to these questions is the magic sauce that makes it work and they don't want threat actors to know. As was stated in the video, "security is a cat and mouse game" (0:59).
Most programs don't modify the return pointer, which is what I imagine the shadow stack would be comparing.
I have seen some programs use a modified return pointer, but I don't think it uses the dame return pointer that's on the stack.
Would be interesting though. I know elden ring and dark souls 3 use this kind of obfuscation. I'm sure they still run fine on this, though?
I would also take into consideration that the shadow stack knows what's already on the stack, and can detect that a buffer was overflown after a call is executed, since stuff on the stack would be changed, when it shouldn't have (I.E. a call to memcpy to copy over some data to a buffer, and after that return, the stack for the current frame, has changed.
I don't comment. but John you do so well. I will comment here & now/ well done
hey john is it still worth the time learning ROP today? I really wanted to learn it but if it is not relevant anymore i will not learn it. how widespread are these intel systems?
you got a big ol' brain John. Great stuff.
Damn it... And I just started learning how to ROP....
Seeing intel sponsoring the videos is weird and stinks
When it comes down to corporations, I think I'll pick the old poison I'm familiar with over the one trying a new trick to look nice
0:57
Aka change the exec flow...
Every new feature brings in new flaws. Soon, You will hear researchers finding out ways to push modified return address in the shadow stack. Not sure tho
I have mixed feelings about this. Yes it is great for security. Makes pen testing harder.
bruh...
Not applicable for pen testing. This more for exploit dev. Plus there are CET bypass using COOP on c++. Overall your goal as a ethical hacker (offesive/red team) is to work your self out of a job.
bro youtube vanced just died ffs
plzz make a video on reverse shell using pdf
Bebopping around
RIP ROP but nevetheless I nerver understood it it's too hard xD
We all know its pronounced IO"Cottle" not IOCTL
Boo! No!
Your videos are becoming too much advanced... Please post more of the easier tips and techniques
Is there any coupon available for tryhackme annual subscription