jana
asked on
Protecting vb6 & .Net code Obfuscation
Hi talking with colleagues was informed that there is a way to protect our code vb6 and vb.net; something called Obfuscation. We looked it up and there is a lot of confusing info not quite understand. Can an EE tell us if this Obfuscation is the way to go in protecting our code? Please advice.
ASKER
We know nothing is 100% but we are looking for is to maybe protect the EXE files; can you elaborate a bit more on obfuscation maybe in more simple terms?
Our Total Visual CodeTools product offers a wide range of tools to help VB6 and VBA developers
It's VBA/VB6 Code Delivery feature lets you obfuscate your variable names, remove comments, blank lines, line continuation characters, etc. so that someone who gets the raw source code or reverse engineers the code from the EXE would have much more difficulty. It also adds line numbers to all your code which is very helpful if your error handler reports the line number where crashes occur. A basic requirement when we deliver solutions.
Hope this helps.
It's VBA/VB6 Code Delivery feature lets you obfuscate your variable names, remove comments, blank lines, line continuation characters, etc. so that someone who gets the raw source code or reverse engineers the code from the EXE would have much more difficulty. It also adds line numbers to all your code which is very helpful if your error handler reports the line number where crashes occur. A basic requirement when we deliver solutions.
Hope this helps.
What kind of "protection" do you seek for your exe files?
ASKER
So obfuscate means that the said apps would somehow rename:
- variable names
- remove comments
- blank lines
- line continuation characters, etc
???
The "protection" we seek in our exe files are 2 (in our limited expierence):
Hope this provide our scope of what we want.
please advice
- variable names
- remove comments
- blank lines
- line continuation characters, etc
???
The "protection" we seek in our exe files are 2 (in our limited expierence):
- Limit or make dificult reverse engineering.
This for obvious reasons and we think we understand by obfuscate.
- Constant values like letters, for example variable="Expert Exchange" not be visible with a hex editor.
This is because we were told that if we place a line like DisplayCompanyNameLicensed To="Expert Exchange", an individual can use a hex editor and change that value. So when run, the apps will say it's license to someone else and legally since it says it in the apps
Hope this provide our scope of what we want.
please advice
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Obfuscation will make it a bit harder to read code to is not 100% hack-free. There is not much you can do in the Windows world to really protect .Net code other than having the code to run from a remote server.
Also, if you are using the Reflection feature, your app won't run if obfuscated.
Also, if you are using the Reflection feature, your app won't run if obfuscated.
ASKER
Yes, that is what we concluded here "include a function to decode-and-decrypt those strings" (as a matter of fact we place another question on this).
In other words, if we encrypt a string we want to display on the form, we would make a function that we would send the encrypted data and the function would decrypted and display it.
Can you provide an example?
Eric, what do you mena by Reflection feature?
In other words, if we encrypt a string we want to display on the form, we would make a function that we would send the encrypted data and the function would decrypted and display it.
Can you provide an example?
Eric, what do you mena by Reflection feature?
Some things to ask yourself:
1. How many versions of the software will we sell/license?
2. How much effort ($$$) will we spend protecting our program?
3. How often do new versions get distributed?
1. How many versions of the software will we sell/license?
2. How much effort ($$$) will we spend protecting our program?
3. How often do new versions get distributed?
ASKER
Answers:
1. How many versions of the software will we sell/license? - for now 1 and at this point it's on trial with the site; hopefully more subsequently (this will be our first time)
2. How much effort ($$$) will we spend protecting our program? -we have one person working on it; we are no knowledgeble on the matter but want to se how viable to incorporate this practice
3. How often do new versions get distributed? -for now 1
1. How many versions of the software will we sell/license? - for now 1 and at this point it's on trial with the site; hopefully more subsequently (this will be our first time)
2. How much effort ($$$) will we spend protecting our program? -we have one person working on it; we are no knowledgeble on the matter but want to se how viable to incorporate this practice
3. How often do new versions get distributed? -for now 1
How are you handling the licensing? (Lease, purchase, other ________, by PC/server, by domain)
ASKER
We are not there yet. Unfortunately this is a project that our boss just threw on us due to a bad move by the customer and now we must implement but want to protect anything we send over during this period. So for now, we don't know what the next sale will be like; Lease, purchase, etc.
Looks like this has gone beyond the technical to the issue of trust with the client, since this is a one customer issue right now. Not sure what the price/value of your solution is, but in most cases, delivering an EXE in VB6 or .NET is sufficient to protect the source code. It's a separate issue if you're trying to hide specific secure information (e.g. passwords and connection strings) versus the source code.
If there's fear about the client reverse engineering from the EXE, that raises all sorts of other issues beyond obfuscation. First, that would require considerable effort. Second, they would need to have the technical expertise to do something with it.
Is the fear they won't pay you? Or that they'll take your work and resell it or compete against you? One needs to understand what you're trying to protect/prevent in order to come up with the right solution.
If there's fear about the client reverse engineering from the EXE, that raises all sorts of other issues beyond obfuscation. First, that would require considerable effort. Second, they would need to have the technical expertise to do something with it.
Is the fear they won't pay you? Or that they'll take your work and resell it or compete against you? One needs to understand what you're trying to protect/prevent in order to come up with the right solution.
ASKER
Hi Éric,
Hi LukeChung,
read your link and it seems that it's for obtaining information about loaded assemblies.
How does that help us?
thanx.
How does that help us?
thanx.
Hi LukeChung,
We are trying to protect the EXE from their techs so they do not either reverse engineer or view the EXE with some sort of hex-viewer and identify certain values as strings so on.
You can use Reflection to call methods or get/set properties that are not known at compile time. If you obfuscate your code, all the names will be changed and reflection won't be able to work.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanx! Great Info! We are working on it right now!!!
http://www.oreans.com/
They take obfuscation a step (or three) further than code obfuscation.