(Login MCalkins) C-Forum Posted Sep 16, 2011 4:21 AM
>It seems you know a lot more about the EXE than I do.
I've read about it, but I wouldn't consider myself very clear on it. We each have stronger areas and weaker areas.
>It's easy to cast wchar_t* or wchar_t** to a void* implicitly (without the (void*) part). That's why neither way gives an error.
Thanks for the explanation.
>I was thinking that most OSs separate the executing code from the data for security purposes, which is the assumption from which I deduced my conjectures. I get a segfault when I try to write to memory where the code is located.
I'm not entirely sure how of all this stuff works. I guess the OS is using the 386 protection mechanisms to make the .text section read only. As far as not executing the data, I would have thought that the 386 would allow enforcement of that also, but the impression that I am getting is that hardware based "No execute" protection is much more recent. Windows has an option (under "System Properties", "Advanced", "Performance" settings, "Data Execution Prevention" on whether to use that protection for 32 bit applications. It is always used for the OS and for 64 bit applications. I think a 32 bit application can execute data on the stack, unless that setting is changed. (Mark Russinovich demonstrates this.)
When I was doing some quick research about base relocations for the last post, I think I read that it is being required again for 64 bit programs, or something like that, for security reasons.
I used to wonder (and still do) how malicious code inserted into a program using a buffer overflow could actually do anything useful. I guess the fact that the program's base address is usually known might help with that. I'm not sure how much difference it makes.
>Most of what I know came from observations when debugging.
I need to be doing more of that, but I haven't figured out which Windows debugger I really like yet. I will probably end up using WinDbg, but I haven't looked much at the OpenWatcom debugger. I don't know how to use gdb.
I'm finding myself getting lazy about programming in general, even with QBASIC programs... :-( I go through cycles of productivity.
probably EBP, I'd think.
>Any suggestions for what to look for?
Not particularly. I guess I need to stop being lazy and start using a debugger more, and reading more.
Sometimes I have been reluctant to look at the assembly output or disassembly of compiled programs (which doesn't mean I haven't, just that I am reluctant), because I might want to write my own compiler without worry about legal issues. I guess it doesn't really matter. I think they probably expect people to do that. (you might say that gcc is open source, but if I write a compiler, it will be public domain or permissive license, not GPL.)
I hope you get to feeling better. Thank you for your time and responses.