Protect IL Code

[YK]

All,

What is the best way to protect IL code?

---------------------------------------------------
Typical scenario:

Visual Studio .NET 2003 includes Dotfuscator Community Edition, which intends to protect IL code. However, many .NET applications use data binding in UI forms. For example:

Employee e = new Employee();
txtName.DataBin dings.Add("Text ", e, "Name");
txtAddress.Data Bindings.Add("T ext", e, "Address");

In this scenarion, property names are coded as string to be resolved at runtime. After obfuscation, the property names in the Employee class have changed, but the string in the data binding code retained.

We can configure obfuscator tool with a list of exception names that the tool will not process. However, this maintains the property names, which eventually reveal the actual logic.

---------------------------------------------------

Thanks
-YK

[YK]

Hi Hank,

I'm working on a standalone desktop application, in which all layers of the applications are running on a single machine.

However, when this application is deployed to customers, it's important to prevent the IL code from being decompiled.

Thanks.
-YK

"Hank Coffin" wrote:

Hi YK,

Did you check out the upgraded versions of Dotfuscator? They get more advanced and I think will encrypt strings like that.

You could encrypt the strings yourself.

Also, where is this code running? Are you doing database stuff on the client app? In that case you might consider doing remoting.

Hank

"YK" wrote:

All,

What is the best way to protect IL code?

---------------------------------------------------
Typical scenario:

Visual Studio .NET 2003 includes Dotfuscator Community Edition, which intends to protect IL code. However, many .NET applications use data binding in UI forms. For example:

Employee e = new Employee();
txtName.DataBin dings.Add("Text ", e, "Name");
txtAddress.Data Bindings.Add("T ext", e, "Address");

In this scenarion, property names are coded as string to be resolved at runtime. After obfuscation, the property names in the Employee class have changed, but the string in the data binding code retained.

We can configure obfuscator tool with a list of exception names that the tool will not process. However, this maintains the property names, which eventually reveal the actual logic.

---------------------------------------------------

Thanks
-YK

[Sean Bright]

No amount of obfuscation in a IL language like MSIL or Java will stop
reverse engineering, it simply slows the process.

If there are truly pieces of your application that absolutely cannot be
compromised, then you should write those pieces in native code and use
interop, but even then, an enterprising individual can figure out what
is going on.

YK wrote:

Hi Hank,

I'm working on a standalone desktop application, in which all layers of the applications are running on a single machine.

However, when this application is deployed to customers, it's important to prevent the IL code from being decompiled.

Thanks.
-YK

"Hank Coffin" wrote:

Hi YK,

Did you check out the upgraded versions of Dotfuscator? They get more advanced and I think will encrypt strings like that.

You could encrypt the strings yourself.

Also, where is this code running? Are you doing database stuff on the client app? In that case you might consider doing remoting.

Hank

"YK" wrote:

All,

What is the best way to protect IL code?

---------------------------------------------------
Typical scenario:

Visual Studio .NET 2003 includes Dotfuscator Community Edition, which intends to protect IL code. However, many .NET applications use data binding in UI forms. For example:

Employee e = new Employee();
txtName.DataBin dings.Add("Text ", e, "Name");
txtAddress.Data Bindings.Add("T ext", e, "Address");

In this scenarion, property names are coded as string to be resolved at runtime. After obfuscation, the property names in the Employee class have changed, but the string in the data binding code retained.

We can configure obfuscator tool with a list of exception names that the tool will not process. However, this maintains the property names, which eventually reveal the actual logic.

---------------------------------------------------

Thanks
-YK

[Huihong Luo]

You can take a look of our salamander suite for source
code protection. The best protection would be to emulate
something similar to what a traditional c/c++
compiler/linker does, namely, to change symbol names to
memory locations, to staticly link public libraries, to
emit x86 machine code, etc.

(1) http://www.remotesoft.com/salamander/obfuscator.html
(an obfuscator is like a C++ compiler to change symbol
names -> memory location)

(2) http://www.remotesoft.com/linker.html
(This tool acts as a C++ linker to link public APIs into
your .NET assembly)

(3) http://www.remotesoft.com/salamander/protector.html
(This tool converts MSIL code into x86 machine code as
the c++ compiler does in the code generation phase, also
performs literal string encrytion).

After these 3 phase of process, the resulting code is
virtually impossible to decompile. This is the best way I
can ever think of.

These three tools can be used either independently or in
consective order depending on what level of protection you
are looking for.

Thanks,

Huihong

-----Original Message-----
All,

What is the best way to protect IL code?

---------------------------------------------------
Typical scenario:

Visual Studio .NET 2003 includes Dotfuscator Community Edition, which intends to protect IL code. However,
many .NET applications use data binding in UI forms. For
example:
Employee e = new Employee();
txtName.DataBin dings.Add("Text ", e, "Name");
txtAddress.Data Bindings.Add("T ext", e, "Address");

In this scenarion, property names are coded as string to be resolved at runtime. After obfuscation, the property
names in the Employee class have changed, but the string
in the data binding code retained.
We can configure obfuscator tool with a list of exception names that the tool will not process. However, this
maintains the property names, which eventually reveal the
actual logic.
---------------------------------------------------

Thanks
-YK

.

[Huihong]

The URL for the linker tool is:
(2) http://www.remotesoft.com/linker

-----Original Message-----
You can take a look of our salamander suite for source
code protection. The best protection would be to emulate
something similar to what a traditional c/c++
compiler/linker does, namely, to change symbol names to
memory locations, to staticly link public libraries, to
emit x86 machine code, etc.

(1) http://www.remotesoft.com/salamander/obfuscator.html
(an obfuscator is like a C++ compiler to change symbol
names -> memory location)

(2) http://www.remotesoft.com/linker.html
(This tool acts as a C++ linker to link public APIs into
your .NET assembly)

(3) http://www.remotesoft.com/salamander/protector.html
(This tool converts MSIL code into x86 machine code as
the c++ compiler does in the code generation phase, also
performs literal string encrytion).

After these 3 phase of process, the resulting code is
virtually impossible to decompile. This is the best way I
can ever think of.

These three tools can be used either independently or in
consective order depending on what level of protection youare looking for.

Thanks,

Huihong

-----Original Message-----
All,

What is the best way to protect IL code?

---------------------------------------------------
Typical scenario:

Visual Studio .NET 2003 includes Dotfuscator CommunityEdition, which intends to protect IL code. However,
many .NET applications use data binding in UI forms. For
example:

Employee e = new Employee();
txtName.DataBin dings.Add("Text ", e, "Name");
txtAddress.Data Bindings.Add("T ext", e, "Address");

In this scenarion, property names are coded as string to

be resolved at runtime. After obfuscation, the property
names in the Employee class have changed, but the string
in the data binding code retained.

We can configure obfuscator tool with a list of

exceptionnames that the tool will not process. However, this
maintains the property names, which eventually reveal the
actual logic.

---------------------------------------------------

Thanks
-YK

.

.

[Hank Coffin]

You need to figure out what level of risk your are comfortable with relative to potential loss.
What are you trying to protect?
Are you connecting to a database? How about using stored procedures?

You might want to check out the Pro version of Dotfuscator (I'm not affiliated with Preemptive Solutions in any way except as a user of Community Edition). That might slow them down enough.

"Sean Bright" wrote:

No amount of obfuscation in a IL language like MSIL or Java will stop
reverse engineering, it simply slows the process.

If there are truly pieces of your application that absolutely cannot be
compromised, then you should write those pieces in native code and use
interop, but even then, an enterprising individual can figure out what
is going on.

YK wrote:

Hi Hank,

I'm working on a standalone desktop application, in which all layers of the applications are running on a single machine.

However, when this application is deployed to customers, it's important to prevent the IL code from being decompiled.

Thanks.
-YK

"Hank Coffin" wrote:

Hi YK,

Did you check out the upgraded versions of Dotfuscator? They get more advanced and I think will encrypt strings like that.

You could encrypt the strings yourself.

Also, where is this code running? Are you doing database stuff on the client app? In that case you might consider doing remoting.

Hank

"YK" wrote:
All,

What is the best way to protect IL code?

---------------------------------------------------
Typical scenario:

Visual Studio .NET 2003 includes Dotfuscator Community Edition, which intends to protect IL code. However, many .NET applications use data binding in UI forms. For example:

Employee e = new Employee();
txtName.DataBin dings.Add("Text ", e, "Name");
txtAddress.Data Bindings.Add("T ext", e, "Address");

In this scenarion, property names are coded as string to be resolved at runtime. After obfuscation, the property names in the Employee class have changed, but the string in the data binding code retained.

We can configure obfuscator tool with a list of exception names that the tool will not process. However, this maintains the property names, which eventually reveal the actual logic.

---------------------------------------------------

Thanks
-YK

[Jonathan Pierce]

> >>

Employee e = new Employee();
txtName.DataBin dings.Add("Text ", e, "Name");
txtAddress.Data Bindings.Add("T ext", e, "Address");

In this scenarion, property names are coded as string to

be resolved at runtime. After obfuscation, the property
names in the Employee class have changed, but the string
in the data binding code retained.

We can configure obfuscator tool with a list of exception

names th

Thanks
-YK

at the tool will not process. However, thismaintains the property names, which eventually reveal the
actual logic.

You may want to consider using our Decompiler.NET product to protect
your code. It includes full obfuscation capability and replaces string
literals with references and stores their values within an encrypted
embedded resource. Also, make sure to declare classes and member names
as internal rather than public if you want their names to be
obfuscated and they don't need to be accessible outside your assembly.
You can download a free trial version of Decompiler.NET from
http://www.junglecreatures.com/

Jonathan Pierce
President
Jungle Creatures, Inc.
http://www.junglecreatures.com/