[blackwater]

We really need to kill all the usage of system() calls in C/C++... I've seen it many times now but I don't think people realize how bad it is, aside from the fact that it limits your binary to Windows only. I would love to have a program that I want to crack, do that.

I know this is an old post, but I just glanced at it and am very confused as to why you say system needs to be killed. The system call is not limited to windows by any means, it's part of libc.

More over the system function can also lead to a quite sophisticated buffer overflow attack.

Just because you call "system()" in your binary, doesn't mean it's vulnerable to a buffer overflow attack. I know you didn't directly say that, but wanted to clear up the confusion. Also, if you do happen to have a bof where the stack isn't executable, meaning you can't place your shellcode on the stack and just return to it and pop a shell, then you will need to "return to libc" via ROP (Return Oriented Programming) and call system with the parameters of your choice. It's actually fairly simple once you see how to do it, maybe I'll write up a post sometime and explain.

[1llusion]

We really need to kill all the usage of system() calls in C/C++... I've seen it many times now but I don't think people realize how bad it is, aside from the fact that it limits your binary to Windows only. I would love to have a program that I want to crack, do that.

I know this is an old post, but I just glanced at it and am very confused as to why you say system needs to be killed. The system call is not limited to windows by any means, it's part of libc.

More over the system function can also lead to a quite sophisticated buffer overflow attack.

Just because you call "system()" in your binary, doesn't mean it's vulnerable to a buffer overflow attack. I know you didn't directly say that, but wanted to clear up the confusion. Also, if you do happen to have a bof where the stack isn't executable, meaning you can't place your shellcode on the stack and just return to it and pop a shell, then you will need to "return to libc" via ROP (Return Oriented Programming) and call system with the parameters of your choice. It's actually fairly simple once you see how to do it, maybe I'll write up a post sometime and explain.

Just using "system()" doesn't mean you are vulnerable to BoF, but if you are then there is a chance of being able to execute system commands through it which isn't really nice.

More info why not to use it: http://www.cplusplus.com/forum/articles/11153/

[lady_godiva]

That is what i meant, i was in hurry and didn't explain it correctly !

[blackwater]

Just using "system()" doesn't mean you are vulnerable to BoF, but if you are then there is a chance of being able to execute system commands through it which isn't really nice.

Yes, that's what I said, and it's important to make clear that it does *not* have to be explicitly used in "your" code to call system (provided libc is linked). But that's getting into nitty gritty stuff and stack permissions etc. Sorry to take focus away from the original topic.

[xxterorxx]

Thanks for this tut

[TheUninvited_mybb_import15721]

A pointer is just an address to a location in memory. Depending on the architecture the address is usually 32 or 64 bits. A pointer itself is just two instructions that add two 16 bit integers based on high and low bitvalues. that pretty much sums up what a pointer is