Info: To explore the content of exe file produced by gpc I compiled foo.pas - just "begin end.". It gave me 349.322 bytes exe file. Open it with hex editor I was wondered with content - there are a small manual how to use RTS (?), alot of zeros ... and a few web addresses I visited a few days ago! I have compiled one more time with -s switch. Again the visited addresses from the history of my Opera 6.05 I used hour before. Exploring it closer I found that some random memory dump is embeding in to exe. Who knows what will be there the next time - may be an accout's passwords or credit card detail you entered some days ago in browser. It placed after second 'msvcrt.dll' followed by two zeros and always is 328 bytes. I saved a few samples if someone will be interest. I use GPC under MinGW on Windows 98SE. Is it known issue?
Question: Is there a program for Windows to analyze the content of PE executables and cleaning out the rubbish?
Thanks, Peter
__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/
On 23 Jan 2004 at 9:24, Peter Norton wrote:
Info: To explore the content of exe file produced by gpc I compiled foo.pas - just "begin end.". It gave me 349.322 bytes exe file. Open it with hex editor I was wondered with content - there are a small manual how to use RTS (?), alot of zeros ... and a few web addresses I visited a few days ago! I have compiled one more time with -s switch. Again the visited addresses from the history of my Opera 6.05 I used hour before. Exploring it closer I found that some random memory dump is embeding in to exe. Who knows what will be there the next time - may be an accout's passwords or credit card detail you entered some days ago in browser. It placed after second 'msvcrt.dll' followed by two zeros and always is 328 bytes. I saved a few samples if someone will be interest. I use GPC under MinGW on Windows 98SE. Is it known issue?
I have not been able to reproduce this (under Windows XP). All I find in my executable are references to the names of a zillion routines. In any case, I doubt that what you have experienced is specifically a gpc issue. It is more likely a Windows issue, or an issue with the linker.
Question: Is there a program for Windows to analyze the content of PE executables and cleaning out the rubbish?
Compressing with upx does a pretty good job.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Peter Norton wrote:
To explore the content of exe file produced by gpc I compiled foo.pas - just "begin end.". It gave me 349.322 bytes exe file. Open it with hex editor I was wondered with content - there are a small manual how to use RTS (?), alot of zeros ... and a few web addresses I visited a few days ago! I have compiled one more time with -s switch. Again the visited addresses from the history of my Opera 6.05 I used hour before. Exploring it closer I found that some random memory dump is embeding in to exe. Who knows what will be there the next time - may be an accout's passwords or credit card detail you entered some days ago in browser. It placed after second 'msvcrt.dll' followed by two zeros and always is 328 bytes. I saved a few samples if someone will be interest. I use GPC under MinGW on Windows 98SE. Is it known issue?
AFAIK, it's a known issue ... of certain Windows versions. I've seen similar reports about MS-Word files etc.
The problem is that these Windows versions do not protect memory adequately, so newly allocated memory and/or memory paged out and back in can contain data from other processes.
I suppose that the NT-based versions will do better, but I'm not sure since I don't use any of them myself.
So, the moral is that *any* file created on Windows 98 etc. (except text files etc. where you can see exactly what they contain) may reveal sensible data when given to someone else. (Even if you don't see anything suspicious in a hex editor for a given file, that doesn't mean much since there could be binary data leaked.) What this means on a networked PC (apart from the "regular" insecurities and vulnerabilities) is up to you to imagine ...
Frank
On 23 Jan 2004 at 9:24, Peter Norton wrote:
...I found that some random memory dump is embeding in to exe. [...] I use GPC under MinGW on Windows 98SE. Is it known issue?
It appears to be a known issue with GNU Binutils. See:
http://sources.redhat.com/ml/binutils/2000-08/msg00437.html
If I understand correctly, the problem is that "ld" seeks beyond the EOF of the newly created EXE file as part of its normal write operations. Under WinNT/2K/XP, the area "skipped" is automatically zeroed. Under Win95/98/Me, the area contains whatever happened to be in memory at the time. So what you are seeing is expected behavior under Win98.
-- Dave
J. David Bryan wrote:
On 23 Jan 2004 at 9:24, Peter Norton wrote:
...I found that some random memory dump is embeding in to exe. [...] I use GPC under MinGW on Windows 98SE. Is it known issue?
It appears to be a known issue with GNU Binutils. See:
Seems that discussion got lost, and they only thought about performance and binary comparisons, not about the security implications.
Unless a similar patch has been applied to recent binutils versions, you might want to get back to the participants of the above discussion ...
Frank
On 24 Jan 2004 at 18:20, Frank Heckenbach wrote:
Seems that discussion got lost, and they only thought about performance and binary comparisons, not about the security implications.
"Security" and "Win9x" is a contradiction in terms. ;-)
Unless a similar patch has been applied to recent binutils versions...
I've searched the changelog for binutils 2.14 and did not find any mention of such a patch.
...you might want to get back to the participants of the above discussion ...
Perhaps the OP will, as I do not use Win9x for development (although I think that the recommended fix might be, "Change to WinNT/2K/XP").
An alternative might be to use Cygwin under Win9x, as the thread implied that this problem has been fixed for that platform.
-- Dave