VS2010 compiled executables AND path segments in the clear

Question

3.00/5 (2 votes)

See more:

Is there a compiler/linker setting/command-line-switch which I'm overlooking that would eliminate these references to my computer?

It seems to me that this information qualifies as type "personal" and should easily be eliminated, even as early as project creation from within the interface, if not by VS then by something a bit more sophisticated than a basic binary editor.

... in C++, now ... not necessarily managed ...

Posted 13-Jan-11 8:23am

RedDk

Updated 13-Jan-11 8:56am

v2

Add a Solution

Comments

Espen Harlinn 13-Jan-11 14:32pm

??? isn't there something missing from this ???

Sergey Alexandrovich Kryukov 13-Jan-11 14:37pm

Where do you see "personal" references: in source files or executables?

Chris Meech 13-Jan-11 14:41pm

What do you mean by path segments?

RedDk 13-Jan-11 17:50pm

... post answer question ... How does one go about Improving questions ore than one time? (Don't answer that)

5 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

User 7429338 · Answer 1 · 2011-01-13T09:15:00

Solution 3

Could it be that you have generation of debug info turned on?

This is the default setting when building in debug mode, building in release mode has better settings if you want to distribute your .exe.

Posted 13-Jan-11 9:15am

User 7429338

Comments

Espen Harlinn 13-Jan-11 15:53pm

5+ sounds entirely reasonable

RedDk 13-Jan-11 15:53pm

Program Database information switches are available when compiling in release mode but that's besides the point. /Zi is the current setting. What do you use?

[no name] 13-Jan-11 15:56pm

They are available, I didn't mean to claim they weren't, but by default they're off.
To not have any debug info, you can remove the /Zi switch.

RedDk 13-Jan-11 16:00pm

blanked it as you proscribe, path is still there ...

RedDk 13-Jan-11 16:03pm

commandline:

/nologo /W3 /WX- /O2 /Oi /Oy- /GL /D "_MBCS" /Gm- /EHsc /GS /Gy /fp:precise /Zc:wchar_t /Zc:forScope /Fp"Release\(project).pch" /Fa"Release\" /Fo"Release\" /Fd"Release\(project).pdb" /Gd /analyze- /errorReport:queue

[no name] 13-Jan-11 16:29pm

I'm not sure then. I did some testruns and if I don't use the /Zi switch, there isn't any .pdb file generated or referenced in the executable. This seems to be backed up by msdn (http://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=VS.100%29.aspx).

Did you do a full rebuild of the project?

RedDk 13-Jan-11 17:25pm

Sorry,
Late reply. 'Vbeen querying Nish beneath this post. In answer to the question, full rebuild -> sure. But I'm actually trying to now put to rest the notion that debug is somehow involved in release output. So ...

RedDk 13-Jan-11 17:40pm

Update above. Thanks everybody

Nish Nishant · Answer 2 · 2011-01-13T09:02:00

Solution 2

If you mean C++ linkage, there are no file paths in use at all. Only the DLL names are stored. At runtime, there are predefined search paths where the required DLLs are searched for. So if your fear is that distributed executables will reveal your file system structure, then don't worry, there is zero risk of that happening.

Based on your response, it seems you may be looking at a debug build which will indeed have more information in it than a release build would. I am still surprised that you found the full compiler command line. That said, you will only ever need to distribute release builds of your binaries, and in fact you should never distribute a debug mode executable.

[Edit]
Okay, it seems you are referring to the PDB path. You can set this manually to a path-less string using the following switch /PDBALTPATH:

http://msdn.microsoft.com/en-us/library/dd998269.aspx[^]

Try that and see if you still have the problem.

[Edit]
From your 1 vote and your angry comment, it seems you have mistaken the above switch to be a dumpbin switch. It's not. What I gave you is a VC++ linker switch that can be used to prevent the full path to the pdb file from being inserted into the generated binary. Do give it a shot if you see this edit.

[Edit]

I think there is a miscommunication here. Here's what happens by default (I just verified this with VC++ 2010).

I created a new MFC project, and built a release mode executable (leaving all settings as default). The generated exe had the full path to the pdb file which did reveal file system info.

I added the above mentioned linker switch with a dummy pdb name:

/PDBALTPATH:dummyfile.pdb

I rebuilt the exe, and opened it in a binary editor. This time the path information was gone.

Isn't this what you want to do? And yes, I am talking about release mode here.

Posted 13-Jan-11 9:02am

Nish Nishant

Updated 13-Jan-11 11:59am

v5

Comments

RedDk 13-Jan-11 16:19pm

Just tried PP/Configprop/linker/debugging/generate dbg info = NO (previously YES) ... partial solution! The "findable" path is now absent. Unfortuneatly, the wide-character path is still present.

RedDk 13-Jan-11 16:22pm

I see my full path in the linker commandline!
How can I make that go away? That's surely the reason why it's being output. Where am I allowed to "../" in the VVisual Studio interface?

RedDk 13-Jan-11 16:35pm

MAC Address Finder demo executable (straight off cdprjct ... debug/release not withstanding:
path:
c:\documents and settings\Nish\My Documents\Visual Studio\Projects\MACAddressChanger\MACAddressChanger\Release\MACAddressChanger.(pdb)

Now I'm really confused.

Nish Nishant 13-Jan-11 16:43pm

I've updated my answer.

RedDk 13-Jan-11 17:02pm

Forget about it. DUMPBIN? Why can't anybody address the Visual Studio commandline? Talking a switch here. I've used your program for an example! Didn't use Visual Studio to pipe that one into codeproject?

Nish Nishant 13-Jan-11 17:32pm

Uhm, I don't understand your comment. You used my article demo as an example and the reason it had the full path to the pdb was because I had not used the available switch that can be used to suppress this info in the binary.

Have you tried it?

Nish Nishant 13-Jan-11 17:33pm

Btw, this is not a dumpbin option, what I have you was a C++ linker option that can be set via Visual Studio!

RedDk 13-Jan-11 17:40pm

Update above. (Thanks Nish)

Nish Nishant 13-Jan-11 17:59pm

Please read my most recent update too.

RedDk 13-Jan-11 18:00pm

Oh heck yeah! MAC Address Finder is key! And I like it! Thank you!

Nish Nishant 13-Jan-11 18:05pm

Okay, I gotta say this. I completely don't get the sarcasm here. I am not talking about my MAC address changer here.

RedDk 13-Jan-11 18:08pm

And you did a lot of work here too, so up my down thumb. Thanks again.

RedDk 13-Jan-11 18:14pm

It just occured to me that you can't find my conclusion. See Answer 4. I'm the author of it. I like the [Edit] style you propose however I can't seem to access the original post I made to excersize it. As I said in answer 4, "Quiet" was most likely the cardinal fix.

Nish Nishant 13-Jan-11 18:16pm

Yeah I did read your answer.

But if you want to generate a pdb and allow a client to debug your app with the pdb without revealing your directory structure, what I responded with will be handy.

But in your case, since you've completely disabled the pdb generation, what you tried out will be perfect for you.

Thanks.

Nish Nishant 13-Jan-11 18:17pm

BTW I am surprised it won't let you edit your original question. Maybe it's a new feature introduced to prevent authors changing their questions after people have replied! Not sure.

RedDk 13-Jan-11 18:31pm

May I'm TOO new. Yes?

Espen Harlinn · Answer 3 · 2011-01-13T10:01:00

Here is some info on the subject with some links at the bottom
http://www.mail-archive.com/openssl-dev@openssl.org/msg27691.html[^]

and here is a commercial option:
http://www.heaventools.com/remove-debug-information.htm[^]

you can also search for a version of the strip command for PE executables

Maybe this will help:
/PDBSTRIPPED (Strip Private Symbols)[^]

Update: copied from Description of the .PDB files and of the .DBG files[^]:
It is possible to strip debug information from a PE file and store it in a .DBG file for use by debuggers. For this to work, the debugger needs to know whether to find the debug information in a separate file or not and whether the information has been stripped from the file or not. One method would be for the debugger to search through the executable file looking for debug information. However, to save the debugger from having to search the file, a file characteristic field (IMAGE_FILE_DEBUG_STRIPPED) was invented that indicates that the file has been stripped. Debuggers can look for this field in the PE file header to quickly determine whether the debug information is present in the file or not.

To generate a .DBG file in this format, you can use REBASE.EXE, which is provided with the Win32 SDK. Please see the Win32 SDK documentation for more details.

Downvoting people who actually try to help you doesn't leave us with a warm fuzzy feeling, neither does it motivate us to help you.

Regards
Espen Harlinn

RedDk · Answer 4 · 2011-01-13T09:02:00

Three questions as answers; try to target all of them at once ...

If you dump your executable into a binary editor you see that the path your compiler uses to assemble and link your program is found there. And not only is the path found once but it's found twice.

Note that a binary search of the segmentone would like to eliiminate will obviously return a regular constituent character's size. But the path is also "characterized" in what appears to be wide size too (hence no search results).

Seems personal enough, yes?

Take "APIHookingSample_Executables.zip" fregzample (Adam Roderick - codeproject) ...

The path (a file):

"F:\Codeproject\LoadLibraryHooking\DLLCheck\Release\DLLCh3eck.pdb"

RedDk · Answer 5 · 2011-01-13T11:48:00

Answer to my question (still can't seem edit this original post). Thanks all for the clues.

I've eliminated both references to personal info (as path). Void all references to any .pdb. You can ignore references to manifests; doesn't seem to affect anything. And the clincher I think -> restart Visual Studio after any tools/options alterations!

I think the second path reference was eliminated once the VERBOSE was set to "Quiet" way back in the beginning after shelling out to the IDE @ step #01!

So ... to repeat a maxim: "Expect good things once a restart is applied"

VS2010 compiled executables AND path segments in the clear

5 solutions

Solution 3

Solution 2

Solution 4

Solution 1

Solution 5

Add your solution here

Preview 0