Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #107506 > unrolled thread

How to stop Reverse Engineer a C, C++, VB or C# application?

Back to article view | Back to comp.lang.c

Contents

  How to stop Reverse Engineer a C, C++, VB or C# application? Real Troll <real.troll@trolls.com> - 2017-03-30 12:59 -0500
    Re: How to stop Reverse Engineer a C, C++, VB or C# application? scott@slp53.sl.home (Scott Lurndal) - 2017-03-30 18:45 +0000
      Re: How to stop Reverse Engineer a C, C++, VB or C# application? Real Troll <real.troll@trolls.com> - 2017-03-30 16:45 -0500
        Re: How to stop Reverse Engineer a C, C++, VB or C# application? Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-30 18:53 -0400
        Re: How to stop Reverse Engineer a C, C++, VB or C# application? Ken Brody <kenbrody@spamcop.net> - 2017-03-31 13:56 -0400
          Re: How to stop Reverse Engineer a C, C++, VB or C# application? supercat@casperkitty.com - 2017-03-31 11:49 -0700
    Re: How to stop Reverse Engineer a C, C++, VB or C# application? Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2017-03-30 20:29 +0000
    Re: How to stop Reverse Engineer a C, C++, VB or C# application? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-03-30 14:06 -0700
    Re: How to stop Reverse Engineer a C, C++, VB or C# application? gordonb.1bihd@burditt.org (Gordon Burditt) - 2017-03-30 18:52 -0500
    Re: How to stop Reverse Engineer a C, C++, VB or C# application? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2017-03-30 20:01 -0400
    Re: How to stop Reverse Engineer a C, C++, VB or C# application? David Brown <david.brown@hesbynett.no> - 2017-03-31 09:38 +0200
    Re: How to stop Reverse Engineer a C, C++, VB or C# application? fir <profesor.fir@gmail.com> - 2017-03-31 00:56 -0700
    Re: How to stop Reverse Engineer a C, C++, VB or C# application? supercat@casperkitty.com - 2017-03-31 08:59 -0700
      Re: How to stop Reverse Engineer a C, C++, VB or C# application? Real Troll <real.troll@trolls.com> - 2017-03-31 12:00 -0500
    Re: How to stop Reverse Engineer a C, C++, VB or C# application? Ken Brody <kenbrody@spamcop.net> - 2017-03-31 13:51 -0400
      Re: How to stop Reverse Engineer a C, C++, VB or C# application? Keith Thompson <kst-u@mib.org> - 2017-03-31 12:29 -0700
      Re: How to stop Reverse Engineer a C, C++, VB or C# application? Real Troll <real.troll@trolls.com> - 2017-03-31 16:59 -0400
        Re: How to stop Reverse Engineer a C, C++, VB or C# application? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-04-01 06:05 +0000
        Re: How to stop Reverse Engineer a C, C++, VB or C# application? Robert Wessel <robertwessel2@yahoo.com> - 2017-04-01 01:35 -0500
        OT: private info in .exe files from VS (was Re: How to stop Reverse Engineer a C, C++, VB or C# application?) Ken Brody <kenbrody@spamcop.net> - 2017-04-03 12:39 -0400

#107506 — How to stop Reverse Engineer a C, C++, VB or C# application?

Is there any way to stop an application from bundling all the debug info 
in the executables so that people can't reverse engineer the file?

I was watching a yourTube video and somebody showed a way to reverse the 
exe file and extract the source code from it and the guy created a 
keyGen from it so that now everybody can use the programs without buying 
it.  Surely, there must be a way to stop this or at least make it harder 
for amateurs from doing this.

I create the "Release" versions of my toy applications and when I opened 
the exe file in WordPad, I could see almost most things that are 
supposed to be private.

Jesus is not going to help me here, can he?

[toc] | [next] | [standalone]

#107509

Real Troll <real.troll@trolls.com> writes:
>
>Is there any way to stop an application from bundling all the debug info 
>in the executables so that people can't reverse engineer the file?

Windows?  Solaris?  Linux?  MCP? Exec/1100?  Z/OS?

Certainly most of the aforementioned operating environments provide
mechanisms to remove information not required at runtime.   The
unix 'strip' command comes to mind.

However, so long as one can read the machine code, one can disassemble it
and reverse engineer it, and one generally needs to read the code
to be able to load it into memory and execute it.

There may also be information such as the RTTI tables used in C++
applications that are necesssary at run-time for proper operation.

Encrypting and signing the binary using a trusted OS is likely the only
rational solution.

[toc] | [prev] | [next] | [standalone]

#107523

On 30/03/2017 19:45, Scott Lurndal wrote:
> Real Troll <real.troll@trolls.com> writes:
>> Is there any way to stop an application from bundling all the debug info
>> in the executables so that people can't reverse engineer the file?
> Windows?  Solaris?  Linux?  MCP? Exec/1100?  Z/OS?
>
This is Windows system using Visual Studio Community Edition and/or 
Express Edition.

The video I watched is this:

<https://youtu.be/3D5FOPOkE5Y>

[toc] | [prev] | [next] | [standalone]

#107526

On 3/30/2017 5:45 PM, Real Troll wrote:
> On 30/03/2017 19:45, Scott Lurndal wrote:
>> Real Troll <real.troll@trolls.com> writes:
>>> Is there any way to stop an application from bundling all the debug info
>>> in the executables so that people can't reverse engineer the file?
>> Windows?  Solaris?  Linux?  MCP? Exec/1100?  Z/OS?
>>
> This is Windows system using Visual Studio Community Edition and/or
> Express Edition.
> 
> The video I watched is this:
> 
> <https://youtu.be/3D5FOPOkE5Y>
> 
> 

That's a Visual Basic file, not a C file.  Entirely different animal.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#107546

On 3/30/2017 5:45 PM, Real Troll wrote:
> On 30/03/2017 19:45, Scott Lurndal wrote:
>> Real Troll <real.troll@trolls.com> writes:
>>> Is there any way to stop an application from bundling all the debug info
>>> in the executables so that people can't reverse engineer the file?
>> Windows?  Solaris?  Linux?  MCP? Exec/1100?  Z/OS?
>>
> This is Windows system using Visual Studio Community Edition and/or Express
> Edition.
>
> The video I watched is this:
>
> <https://youtu.be/3D5FOPOkE5Y>

I didn't watch the whole video, but that looks like a Visual BASIC program 
on the screen.  It's possible that VB compiles things in a way that allow 
easy "de-compiling".

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#107547

On Friday, March 31, 2017 at 12:56:23 PM UTC-5, Ken Brody wrote:
> I didn't watch the whole video, but that looks like a Visual BASIC program 
> on the screen.  It's possible that VB compiles things in a way that allow 
> easy "de-compiling".

Both .NET and Java translate source code to an intermediate language form which is stored in an executable.  When a program is run, a "just-in-time compiler" (JIT) converts that to machine code.  This makes it possible to have an executable that can run on many different platforms, and allows many semantic advantages as well.  The intermediate form, however, is by design rather easy to reverse-engineer.

[toc] | [prev] | [next] | [standalone]

#107518

On Thu, 30 Mar 2017 12:59:00 -0500, Real Troll wrote:

> I was watching a yourTube video and somebody showed a way to reverse the
> exe file and extract the source code from it 

	It would be more like recreating a version of the source code 
from it. The compilation process discards data present in the original 
source code, especially when attempting to optimize the code. Recovering 
the original C source code from an executable is impossible.

[toc] | [prev] | [next] | [standalone]

#107521

On Thursday, March 30, 2017 at 1:58:38 PM UTC-4, Real Troll wrote:
> Is there any way to stop ... reverse engineer the file?
> ...
> Jesus is not going to help me here, can he?

Actually, He can, RT.  He would ask you to release the product as not
only open source, but with full rights for others to take what you've
produced and build upon it.

In that way, nobody can reverse-engineer your product, because they have
the full source code.

It is what I do with all of my software, releasing it with a type of
modified Public Domain license where I ask the recipient to honor my
request to keep the software open, and to release any augments to it.
I do not demand this through our legal system, but leave it in the
court of God, such that they have received my content, received the
license, understood my request, and get to choose for themselves
whether they will honor it or not.

It's what God did when He gave man this planet.  And for all who
have not honored His requests, there is a day of judgment coming.
I leave the same end up to Him, and not up to man's legal system:

    http://www.libsf.org/licenses/

    My server's down for maintenance right now, but it should be
    back up later this evening.  And here is my source code repo:

    http://www.libsf.org:8990/projects/LIB/repos/libsf/browse

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#107528

> Is there any way to stop an application from bundling all the debug info 
> in the executables so that people can't reverse engineer the file?

Don't distribute the executable, and you won't have this problem.
Better yet, don't create crippled software in the first place.

> I was watching a yourTube video and somebody showed a way to reverse the 
> exe file and extract the source code from it and the guy created a 
> keyGen from it so that now everybody can use the programs without buying 
> it.  Surely, there must be a way to stop this or at least make it harder 
> for amateurs from doing this.

It's easy:  make sure that your program does not ask for a key.

> I create the "Release" versions of my toy applications and when I opened 
> the exe file in WordPad, I could see almost most things that are 
> supposed to be private.

gcc has various flags like -g to include debugging info.  Don't use them.
However, I am not sure how applicable this is to a Windows platform.
 
> Jesus is not going to help me here, can he?

No, because you're working for the other side.

[toc] | [prev] | [next] | [standalone]

#107529

Real Troll wrote:

> 
> Is there any way to stop an application from bundling all the debug info
> in the executables

Sure. "strip" the executables of debug info during the link phase

> so that people can't reverse engineer the file?

No. Classic DRM problem - the information (in this case, executable code) 
that you need to "use" the file (run the app) is also the same information 
necessary in order to "reverse engineer" the app.

Of course, you can make it difficult to reverse engineer the code, but you 
can't make it impossible, without also preventing legitimate execution of 
the code as well.


-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[toc] | [prev] | [next] | [standalone]

#107533

On 30/03/17 19:59, Real Troll wrote:
> 
> Is there any way to stop an application from bundling all the debug info
> in the executables so that people can't reverse engineer the file?
> 
> I was watching a yourTube video and somebody showed a way to reverse the
> exe file and extract the source code from it and the guy created a
> keyGen from it so that now everybody can use the programs without buying
> it.  Surely, there must be a way to stop this or at least make it harder
> for amateurs from doing this.
> 
> I create the "Release" versions of my toy applications and when I opened
> the exe file in WordPad, I could see almost most things that are
> supposed to be private.
> 
> Jesus is not going to help me here, can he?
> 
> 

As others have pointed out, make sure you build without debug
information, and run "strip" on the executable to take out any extra
linking or debug symbols that are not needed.

Prefer to use static linking where possible, rather than dynamic
linking.  This lets you keep more of the function and symbol names
internal, and they will be removed by "strip".

Use link-time optimisation.  This will blur the boundaries between
functions on a much wider scale, making it much harder for reverse
engineering.  In general, high optimisation levels make it harder to
follow the logic of code from a disassembly.

Beyond that, you can look at obfuscation.  If you have got lots of
strings in the code, try to find a way to "munge" them.  This is
probably best done with the help of some external scripts.  Something as
simple as xor'ing each letter with a fixed value will be quite effective
at ruining an attempt at running "strings" on the file.

Finally, there are obfuscation utilities that intentionally jumble up
code by inserting extra jumps, splitting up functions, etc.  Note that
these may slow down the code - sometimes quite significantly, as you
lose a lot of locality in your code.

[toc] | [prev] | [next] | [standalone]

#107535

W dniu czwartek, 30 marca 2017 19:58:38 UTC+2 użytkownik Real Troll napisał:
> Is there any way to stop an application from bundling all the debug info 
> in the executables so that people can't reverse engineer the file?
> 
> I was watching a yourTube video and somebody showed a way to reverse the 
> exe file and extract the source code from it and the guy created a 
> keyGen from it so that now everybody can use the programs without buying 
> it.  Surely, there must be a way to stop this or at least make it harder 
> for amateurs from doing this.
> 
> I create the "Release" versions of my toy applications and when I opened 
> the exe file in WordPad, I could see almost most things that are 
> supposed to be private.
> 
> Jesus is not going to help me here, can he?

this is veeery lame question, how could you code something not knowing that? as to c, team of engeeneers
at laboratory could probably fully reverse application, 
(without restoring names)
but try it yourself to see how easy it is ;c crackers usually afaik only reverse some small parts, this can be done quicker 

[toc] | [prev] | [next] | [standalone]

#107542

On Thursday, March 30, 2017 at 12:58:38 PM UTC-5, Real Troll wrote:
> Is there any way to stop an application from bundling all the debug info 
> in the executables so that people can't reverse engineer the file?

A useful approach may be to express parts of your logic as data (e.g.
use an interpreted or scripting language), and store that data only
in encrypted format.  If your code takes half of the activation code
and decrypts it using a public half of a public-private key pair, xors
the result with the other half of the activation code, and decrypts that
again with the public half of the key pair, and then uses the final
result as a decryption key to decrypt everything else, someone who reverse
engineers your code and released an activation key might be able to hack
it so as not to require an activation key, without leaving any trace of
the activation key that had been used to decrypt it, but someone who only
had the released executable without at least one working activation code
would not be able to decrypt the data necessary to make the logic work.

[toc] | [prev] | [next] | [standalone]

#107544

On 31/03/2017 16:59, supercat@casperkitty.com wrote:
> On Thursday, March 30, 2017 at 12:58:38 PM UTC-5, Real Troll wrote:
>> Is there any way to stop an application from bundling all the debug info
>> in the executables so that people can't reverse engineer the file?
> A useful approach may be to express parts of your logic as data (e.g.
> use an interpreted or scripting language), and store that data only
> in encrypted format.  If your code takes half of the activation code
> and decrypts it using a public half of a public-private key pair, xors
> the result with the other half of the activation code, and decrypts that
> again with the public half of the key pair, and then uses the final
> result as a decryption key to decrypt everything else, someone who reverse
> engineers your code and released an activation key might be able to hack
> it so as not to require an activation key, without leaving any trace of
> the activation key that had been used to decrypt it, but someone who only
> had the released executable without at least one working activation code
> would not be able to decrypt the data necessary to make the logic work.

I have found that Microsoft compilers might be defective in this respect 
because even their VS 2017 has been cracked already and it was released 
about two weeks ago.  An Indian programmer has already released a keyGen 
for VS 2017 professional and Enterprise.  I guess this can be done when 
the software doesn't require online activation like Office or Windows.  
Visual Studio doesn't require activation so only a product key is needed 
to make it a licensed product.

[toc] | [prev] | [next] | [standalone]

#107545

On 3/30/2017 1:59 PM, Real Troll wrote:
>
> Is there any way to stop an application from bundling all the debug info in
> the executables so that people can't reverse engineer the file?
>
> I was watching a yourTube video and somebody showed a way to reverse the exe
> file and extract the source code from it and the guy created a keyGen from
> it so that now everybody can use the programs without buying it.  Surely,
> there must be a way to stop this or at least make it harder for amateurs
> from doing this.
>
> I create the "Release" versions of my toy applications and when I opened the
> exe file in WordPad, I could see almost most things that are supposed to be
> private.
[...]

In the general sense, you can't generate source code from an executable 
file.  (You can't turn hamburger back into a cow.)  In some cases, it may be 
possible, if you know a lot about the compiler and environment used to build 
it.  (And debug info helps with that.)

I'm curious what sort of "private" things could you see in the release 
version of the program.  Unless your compiler/makefile/whatever is not 
configured properly, a "release" build should have no extra debug info in 
the file.

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#107549

Ken Brody <kenbrody@spamcop.net> writes:
[...]
> In the general sense, you can't generate source code from an executable 
> file.  (You can't turn hamburger back into a cow.)  In some cases, it may be 
> possible, if you know a lot about the compiler and environment used to build 
> it.  (And debug info helps with that.)

Well, in principle it should be possible (but perhaps very difficult)
to generate source code that can be compiled to produce an identical,
or at least functionally identical, executable file.  The derived
source code isn't likely to bear much resemblance to the original.
(If you don't insist on portability, it can just be a C source file
consisting almost entirely of inline assembler.)  It's likely to
be impossible to derive local variable names or the exact forms of
constant expressions.  This:
    int x = 0;
    x ++;
and this:
    int foo = 1-1;
    foo = foo + 7/5;
are likely to generate exactly the same machine code.

And any source code you generate is not likely to be useful.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#107552

On 31/03/2017 18:51, Ken Brody wrote:
>
>
> In the general sense, you can't generate source code from an 
> executable file.  (You can't turn hamburger back into a cow.)  In some 
> cases, it may be possible, if you know a lot about the compiler and 
> environment used to build it.  (And debug info helps with that.)
>
> I'm curious what sort of "private" things could you see in the release 
> version of the program.  Unless your compiler/makefile/whatever is not 
> configured properly, a "release" build should have no extra debug info 
> in the file.
>

File folders etc in which they can see my real name because I use my 
real name when working on a windows system or at work.  Something like this:

> Hello-World02 Hello_World02 <Module> mscorlib Console ReadLine 
> WriteLine GuidAttribute DebuggableAttribute ComVisibleAttribute 
> AssemblyTitleAttribute AssemblyTrademarkAttribute 
> TargetFrameworkAttribute AssemblyFileVersionAttribute 
> AssemblyConfigurationAttribute AssemblyDescriptionAttribute 
> CompilationRelaxationsAttribute AssemblyProductAttribute 
> AssemblyCopyrightAttribute AssemblyCompanyAttribute 
> RuntimeCompatibilityAttribute Hello-World02.exe 
> System.Runtime.Versioning Program System Main System.Reflection .ctor 
> System.Diagnostics System.Runtime.InteropServices 
> System.Runtime.CompilerServices DebuggingModes args Object  H e l l 
> o   W o r l 
> d ! €*tˆæÌI™þƒØnÄD#  

  
 

 

 

 

  ·z\V4à‰ 


 
>      
 
 TWrapNonExceptionThrows

      

> Hello-World02  
    
 Copyright ©  2017  )
 
> $5de8c72a-9cb0-49ee-a263-660854fc0047  
  1.0.0.0  M
 
> .NETFramework,Version=v4.5.2
 TFrameworkDisplayName.NET Framework 
> 4.5.2       2¿ÞX       
  €&  € RSDS>rB}M–š‚3ÿYù
   
> c:\users\xxxxxxxxxxx\documents\visual studio 
> 2017\Projects\Hello-World02\Hello-World02\obj\Release\Hello-World02.pdb 


Sometimes I post real working programs on some crack sites and now I am 
worried that people would know who is the real person distributing them.

[toc] | [prev] | [next] | [standalone]

#107554

On Fri, 2017-03-31, Real Troll wrote:
> On 31/03/2017 18:51, Ken Brody wrote:
...
>> I'm curious what sort of "private" things could you see in the release 
>> version of the program.  Unless your compiler/makefile/whatever is not 
>> configured properly, a "release" build should have no extra debug info 
>> in the file.
>>
>
> File folders etc in which they can see my real name because I use my 
> real name when working on a windows system or at work.  Something like this:
>
>> Hello-World02 Hello_World02 <Module> mscorlib Console ReadLine 
...
>> c:\users\xxxxxxxxxxx\documents\visual studio 
>> 2017\Projects\Hello-World02\Hello-World02\obj\Release\Hello-World02.pdb 
>
>
> Sometimes I post real working programs on some crack sites and now I am 
> worried that people would know who is the real person distributing them.

Privacy.  That's actually a valid concern.

I think that on Unix, I'd create a second user account for such
things. Let that user clone the source code and build it, and hope the
toolchain doesn't put my host name, IP address or MAC address in the
binary.

A search for 'Visual Studio privacy' produces some hits.

On the other hand, I would never run an executable produced by someone
anonymous and placed on a crack site.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#107558

On Fri, 31 Mar 2017 16:59:00 -0400, Real Troll <real.troll@trolls.com>
wrote:

>On 31/03/2017 18:51, Ken Brody wrote:
>>
>>
>> In the general sense, you can't generate source code from an 
>> executable file.  (You can't turn hamburger back into a cow.)  In some 
>> cases, it may be possible, if you know a lot about the compiler and 
>> environment used to build it.  (And debug info helps with that.)
>>
>> I'm curious what sort of "private" things could you see in the release 
>> version of the program.  Unless your compiler/makefile/whatever is not 
>> configured properly, a "release" build should have no extra debug info 
>> in the file.
>>
>
>File folders etc in which they can see my real name because I use my 
>real name when working on a windows system or at work.  Something like this:
>
>> Hello-World02 Hello_World02 <Module> mscorlib Console ReadLine 
>> WriteLine GuidAttribute DebuggableAttribute ComVisibleAttribute 
>> AssemblyTitleAttribute AssemblyTrademarkAttribute 
>> TargetFrameworkAttribute AssemblyFileVersionAttribute 
>> AssemblyConfigurationAttribute AssemblyDescriptionAttribute 
>> CompilationRelaxationsAttribute AssemblyProductAttribute 
>> AssemblyCopyrightAttribute AssemblyCompanyAttribute 
>> RuntimeCompatibilityAttribute Hello-World02.exe 
>> System.Runtime.Versioning Program System Main System.Reflection .ctor 
>> System.Diagnostics System.Runtime.InteropServices 
>> System.Runtime.CompilerServices DebuggingModes args Object  H e l l 
>> o   W o r l 
>> d ! €*tˆæÌI™þƒØnÄD#  


  
 

 

 


 


  ·z\V4à‰ 


 
>>      
 
 T
WrapNonExceptionThrows

 
     

>> Hello-World02  
    
 Copyright ©  2017  )
 
>> $5de8c72a-9cb0-49ee-a263-660854fc0047  
  1.0.0.0  M
 
>> .NETFramework,Version=v4.5.2
 TFrameworkDisplayName.NET Framework 
>> 4.5.2       2¿ÞX    
   
  €&  € RSDS?>rB}M–š‚3ÿYù
   
>> c:\users\xxxxxxxxxxx\documents\visual studio 
>> 2017\Projects\Hello-World02\Hello-World02\obj\Release\Hello-World02.pdb 
>
>
>Sometimes I post real working programs on some crack sites and now I am 
>worried that people would know who is the real person distributing them.


At least that can be removed on semi-current versions of VS with the
/pdbpath or /pdbaltpath linker option.

[toc] | [prev] | [next] | [standalone]

#107678 — OT: private info in .exe files from VS (was Re: How to stop Reverse Engineer a C, C++, VB or C# application?)

On 3/31/2017 4:59 PM, Real Troll wrote:
> On 31/03/2017 18:51, Ken Brody wrote:
>>
>>
>> In the general sense, you can't generate source code from an executable
>> file.  (You can't turn hamburger back into a cow.)  In some cases, it may
>> be possible, if you know a lot about the compiler and environment used to
>> build it.  (And debug info helps with that.)
>>
>> I'm curious what sort of "private" things could you see in the release
>> version of the program.  Unless your compiler/makefile/whatever is not
>> configured properly, a "release" build should have no extra debug info in
>> the file.
>>
>
> File folders etc in which they can see my real name because I use my real
> name when working on a windows system or at work.  Something like this:
>
[...]
>> $5de8c72a-9cb0-49ee-a263-660854fc0047  
  1.0.0.0  M

>> .NETFramework,Version=v4.5.2
 TFrameworkDisplayName.NET Framework
>> 4.5.2       2¿ÞX       
  €&  € RSDS>rB}M–š‚3ÿYù

>> c:\users\xxxxxxxxxxx\documents\visual studio
>> 2017\Projects\Hello-World02\Hello-World02\obj\Release\Hello-World02.pdb
>
>
> Sometimes I post real working programs on some crack sites and now I am
> worried that people would know who is the real person distributing them.

We're getting into very compiler-specific things here, which should probably 
go into one of the Microsoft groups.  However, a quick test here on my copy 
of Visual Studio shows that even the "release" version defaults to having 
debug info generated.

Right-click the project, select "properties".  Then, under configuration 
properties, linker, debugging, make sure "generate debug info" is set to "no".

If there are still some "private" things remaining, you may walso want to 
set configuration properties, linker, manifest file, generate manifest to 
"no".  (No path names were in my test .exe within the manifest.  YMMV.)

-- 
Kenneth Brody

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web