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

[Real Troll]

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?

[Scott Lurndal]

Post by Real Troll
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.

[Real Troll]

Post by Scott Lurndal

Post by Real Troll
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:

[Jerry Stuckle]

Post by Real Troll

Post by Scott Lurndal

Post by Real Troll
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.
http://youtu.be/3D5FOPOkE5Y

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

[Ken Brody]

Post by Scott Lurndal

Post by Real Troll
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.
http://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".

[s***@casperkitty.com]

Post by Ken Brody
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.

[Jens Stuckelberger]

Post by Real Troll
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.

[Rick C. Hodgin]

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

[Gordon Burditt]

Post by Real Troll
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.

Post by Real Troll
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.

Post by Real Troll
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.

Post by Real Troll
Jesus is not going to help me here, can he?

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

[Lew Pitcher]

Post by Real Troll
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

Post by Real Troll
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.

[David Brown]

Post by Real Troll
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.

[fir]

Post by Real Troll
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

[s***@casperkitty.com]

Post by Real Troll
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.

[Real Troll]

Post by s***@casperkitty.com

Post by Real Troll
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.

[Ken Brody]

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.

[Keith Thompson]

Ken Brody <***@spamcop.net> writes:
[...]

Post by Ken Brody
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.

[Real Troll]

Post by Ken Brody
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

Post by Ken Brody
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.

[Jorgen Grahn]

...

Post by Real Troll

Post by Ken Brody
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

Post by Ken Brody
Hello-World02 Hello_World02 <Module> mscorlib Console ReadLine

...

Post by Real Troll

Post by Ken Brody
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

[Robert Wessel]

Post by Real Troll

Post by Ken Brody
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

Post by Ken Brody
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à‰



Post by Real Troll

Post by Ken Brody
 

T
WrapNonExceptionThrows




Post by Real Troll

Post by Ken Brody
Hello-World02 


Copyright © 2017 )

Post by Real Troll

Post by Ken Brody
$5de8c72a-9cb0-49ee-a263-660854fc0047

1.0.0.0 M

Post by Real Troll

Post by Ken Brody
.NETFramework,Version=v4.5.2

TFrameworkDisplayName.NET Framework

Post by Real Troll

Post by Ken Brody
4.5.2 2¿ÞX


€& € RSDS?>rB}M–š‚3ÿYù

Post by Real Troll

Post by Ken Brody
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.

[Ken Brody]

Post by Ken Brody
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

[...]

Post by Ken Brody
$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.)