How do I remove MSIL from my native executable?

[Number 11950 - GPEMC! Replace number with 11950]

Hi all,

Playing VS2005 was more fun than Doom III, and I do enjoy my games. Anyway,
it's back to work for me and I'm bogged down in my familiar VB6 stomping
grounds because I don't want my secrets exposed to casual inspection via
MSIL. VB6 doesn't do this to me, whereas, if I read Balena correctly, VB2005
always will.

The one single and only issue holding up my migration is this matter of IP
security, and I'm sorry folks but no variation on MSIL ("obfuscated" or
otherwise) will cut it for me. What I want is to compile to true native code
with NO MSIL whatsoever. Is this possible to achieve? If so how is it done?

Please don't take this the wrong way, but this is a technical query, not a
product query. I paid more than a grand for VS2005 on the expectation that
I'd get a real compiler, and I don't intend to spend another cent,
especially for a feature that comes for FREE with old and "obsolete" VB6! So
please don't tell me to go spend another grand on "product X", because I
already feel that I didn't get what I paid for in the first place.

All I want is location and/or specification of the executable features that
will allow me to remove any and all MSIL from the binary of a VS2005
compiled "native" executable without disabling it. That'd be a cinch for
those of you who know 8086 & x64 architecture...

Anyway, Thanks in advance of your assistance...

 

[Cor Ligthert[MVP]]

The answer is simple,

AFAIK you can only generate with Visual Studio to the native dotNet code.
Not to the native OS code. However as there has a runtime to be installed,
your program is never completely build in true machine code. (The programs
would be enourmous and terrible slow).

As far as I know can VB6 programs (or Java or whatever) not run without a
runtime, therefore you have to make your programs with Intel Assembler or by
instance true C.

One of the advantages of dotNet is that the runtime is a part of the Net
framework (in fact a windows version independable OS extention) and
therefore programs build in whatever Windows dotNet languages will run on
that. There is as well a (Mono) framework for Linux, however that needs the
Mono software to build applications.

Cor

 

[Number 11950 - GPEMC! Replace number with 11950]

The answer is simple,

AFAIK you can only generate with Visual Studio to the native dotNet code.
Not to the native OS code. However as there has a runtime to be installed,
your program is never completely build in true machine code. (The programs
would be enourmous and terrible slow).

Without IP security at least equivalent to or better than that of VB6,
VB2005 has no advantages, period. It's like an office application suite that
can neither save nor export to standard file formats - pretend software -
and we've all seen plenty of that junk around the traps.

If I read Balena correctly, the "native" executable by VB2005 has two parts.
The first is the MSIL which it can run without because the second part is
not MSIL and this does all the work. So I'm looking for information on how
these two parts are specified.

How do I remove that first MSIL part of the executable to the maximum extent
possible to make it as difficult to decompile as a VB6 application...?

How is this done without paying twice for .NET?
I cannot migrate without an answer to this question.

Thanks in advance...

 

[Guest]

There is no way to bypass MSIL with managed code. Forget it. There is a
built in obfuscator in VS 2005. Also, Desaware sells an online book for
about $60?? written by Dan Appleman about obfuscation. The book provides a
link to an open source obfuscator created by Desaware.

 

[Guest]

Cor, would you mind taking a look at my question on Word Automation
Compatability? Please...

 

[Number 11950 - GPEMC! Replace number with 11950]

There is no way to bypass MSIL with managed code. Forget it.

What is "bypass MSIL with managed code"?

There is a
built in obfuscator in VS 2005. Also, Desaware sells an online book for
about $60?? written by Dan Appleman about obfuscation. The book provides a
link to an open source obfuscator created by Desaware.

Ok, done some hunting. According to:
http://www.improve.dk/articles/dotnet/securing-dotnet-code/

by compiling to a native dll and using an external reference from the
executable, source code buried in the dll can be protected...?

Is this really true?
I thought VB2005 compiled DLLs to MSIL as well, or have I misread something?

Thanks in Advance...

 

[Guest]

in message


What is "bypass MSIL with managed code"?

With managed code...VB.net, C#.net, etc, the code, whether dll or exe, will
always be compiled to MSIL. When that file is run, the JIT compiler compiles
to native.
C++ compiles directly to native.

Ok, done some hunting. According to:
http://www.improve.dk/articles/dotnet/securing-dotnet-code/

by compiling to a native dll and using an external reference from the
executable, source code buried in the dll can be protected...?

Is this really true?
I thought VB2005 compiled DLLs to MSIL as well, or have I misread something?

The article you cited suggested writing the code you want to protect in C++,
which compiles to native and therefore does not decompile to MSIL, which
makes it more difficult to reverse engineer. C++ is part of VS, so be my
guest.

The article also suggested obfuscation. Dotfuscator comes free with VS 2003
and 2005, but it is a limited version. The full blown version is $$$pricey.

This link covers a lot of the obfuscators on the market:

http://www.howtoselectguides.com/dotnet/obfuscators/

They mention xenocode, but because xenocode did not reply to their request
to submit their product, it did not get reviewed. You might want to check
xenocode's website to see what they offer...Look for their discount code if
you decide to buy their product. If the discount code's s not available now,
it is usually offered around major U.S. holidays.

 

[Number 11950 - GPEMC! Replace number with 11950]

:
[SNIP]

by compiling to a native dll and using an external reference from the
executable, source code buried in the dll can be protected...?

Is this really true?
I thought VB2005 compiled DLLs to MSIL as well, or have I misread

something?

The article you cited suggested writing the code you want to protect in C++,
which compiles to native and therefore does not decompile to MSIL, which
makes it more difficult to reverse engineer. C++ is part of VS, so be my
guest.

[SNIP]

So what happens if I compile VB to a DLL & externally reference it? Are you
telling me that VB can't reference an external DLL or compile to MSIL-free
DLL while VC++ can? I thought VB could do everything all the other languages
in VS could do...???

 

[Number 11950 - GPEMC! Replace number with 11950]

There is no way to bypass MSIL with managed code. Forget it. There is a
built in obfuscator in VS 2005. Also, Desaware sells an online book for
about $60?? written by Dan Appleman about obfuscation. The book provides a
link to an open source obfuscator created by Desaware.

3 d4n't w1nt t4 4bf5sc1t2 th2 c4d2. 1s y45 c1n s22, 3t's 1s 5s1f5l 1s 1n
1shtr1y 4n 1 m4t4rb3k2!

The above text is obfuscated .NET style, not encrypted, and not even
enciphered. It may look disorienting at first glance, but go ahead; take
more than a glance. It's really very easy to ready without even resorting to
statistical analysis. Sure, no-one looks at the confusing original
substituents, but just run a little application to find and reduce all
substituents to cribs and ideographic characters (as demonstrated in the
above paragragh) - that's all it takes - then it reads like above which
reads like below - at least to anyone that reads alot. If you're a team
player and used to commented code, that's one thing, but a seasoned ISV
deals with enough uncommented material to make seeing through obfuscation of
MSIL child's play only if starving for espresso! Otherwise, too easy to even
be interesting.

I don't want to "bypass" but remove MSIL code altogether leaving only the
Win32 Native portion of the compilation - http://eziriz.com/comparison.htm
can do it, and I want to do what http://eziriz.com/ do: What do I do to the
native .NET compiled EXE to remove the MSIL altogether and leave only the
native Win32 code?

Thanks in Advance...

 

[Patrice]

AFAIK you can't because MSIL is used for .NET framework security
verifications.

If this is a very strong requirement IMO you can't use .NET for what you are
trying to do (depending what you want to protect you could only do the part
that needs an increased protection with another tool but there are also
AFAIK VB6 decompilers and though a long time pretty capable disassemblers so
you raise the bar but this is not still 100% protected).

Sorry for the bad news...

"Number 11950 - GPEMC! Replace number with 11950" <[email protected]> a
écrit dans le message de [email protected]...

 

[C-Services Holland b.v.]

Number 11950 - GPEMC! Replace number with 11950 schreef:

Hi all,

Playing VS2005 was more fun than Doom III, and I do enjoy my games. Anyway,
it's back to work for me and I'm bogged down in my familiar VB6 stomping
grounds because I don't want my secrets exposed to casual inspection via
MSIL. VB6 doesn't do this to me, whereas, if I read Balena correctly, VB2005
always will.

The one single and only issue holding up my migration is this matter of IP
security, and I'm sorry folks but no variation on MSIL ("obfuscated" or
otherwise) will cut it for me. What I want is to compile to true native code
with NO MSIL whatsoever. Is this possible to achieve? If so how is it done?

Please don't take this the wrong way, but this is a technical query, not a
product query. I paid more than a grand for VS2005 on the expectation that
I'd get a real compiler, and I don't intend to spend another cent,
especially for a feature that comes for FREE with old and "obsolete" VB6! So
please don't tell me to go spend another grand on "product X", because I
already feel that I didn't get what I paid for in the first place.

All I want is location and/or specification of the executable features that
will allow me to remove any and all MSIL from the binary of a VS2005
compiled "native" executable without disabling it. That'd be a cinch for
those of you who know 8086 & x64 architecture...

Anyway, Thanks in advance of your assistance...

AFAIK you can't remove it, but you could make it inaccessable by
wrapping it up in a security envelope like HASP. But that would require
more money.

 

[Number 11950 - GPEMC! Replace number with 11950]

AFAIK you can't because MSIL is used for .NET framework security
verifications.

Security??? MSIL & native machine code face the same security paradoxes like
when is a disk access dodgy? MSIL doesn't answer this in any way that cannot
just as easily be answered in assembler, so whatever the reason MSIL is
used, "security" most definitely is NOT it.

If this is a very strong requirement IMO you can't use .NET for what you are
trying to do (depending what you want to protect you could only do the part
that needs an increased protection with another tool but there are also
AFAIK VB6 decompilers and though a long time pretty capable disassemblers

so

Only if you compile to pcode. I don't. Only "native" code for me, and I'm
yet to find a VB6 decompiler that will do native code at all. I find it
alarming that VB2005 "native" executables are almost "designed" to be
decompiled. Now if eziriz can pull the plug on MSIL, what is the problem
with anyone else doing just that?

The fact is that VB6 is no longer supported. There is no other forwards
compatible alternative to VB.NET, unless I choose to ditch Microsoft
development tools altogether and migrate to RealBasic or PowerBasic. Maybe I
should consider learning C but I never did like the redundant architecture,
or the proneness of documentation to errors and oversights.

 

[rowe_newsgroups]

Now if eziriz can pull the plug on MSIL, what is the problem

with anyone else doing just that?

Perhaps you don't understand - there may be a way to "pull the plug on
MSIL" but apparently we here don't know how to do it - and most of us
don't care about it. If you really want this functionality pay eziriz
the $169 licensing fee for it - or take the time to figure it out
yourself. We're not here to develop a solution for you because you
feel jipped by Microsoft. Sorry for being rude, but you seem to be
getting upset at people who have no control over a feature of the
software.

Also, if you don't mind me asking, what type of software are you
creating that must be so secure? Don't take this the wrong way, but is
the software you are writing even worth the effort of disassembling,
rewriting, and redistributing?

Thanks,

Seth Rowe

 

[Patrice]

I meant that the .NET framework itself does some security verification on
the MSIL code before launching the application. Try for example :
http://msdn2.microsoft.com/en-us/library/aa302369.aspx#netframesecover_topic3

This could explain why you (IMO and AFAIK) just can't strip the MSIL part.
It has a role in the whole design. And AFAIK the MSIL code is still
included in NGENed applications (ngen is a tool that compiles MSIL to native
code once for all).

As you already established that even obsfucated code would be too easily
usable by third party, this left you with switching to whatever tool best
fit your need (either just for sensitive parts or for the whole
application).

 

[Patrice]

Or just buy the http://eziriz.com/comparison.htm package ? I missed this
part. Sorry.

From the description page ("NET Reactor builds a native code wall between
potential hackers and your .NET assemblies by producing a file which cannot
be understood *directly* as CIL") my understanding is *not* that they remove
the MSIL code but rather than they further obscure the original .NET exe and
append a loader making the MSIL code unreachable from an external tool.

Then when the app is launched, the loader part loads the .NET exe part as if
it were unchanged (this means also that this could be available somewhere in
memory at this time).

At least this is my understanding of how it could work from the info
provided...

 

[Number 11950 - GPEMC! Replace number with 11950]

Perhaps you don't understand - there may be a way to "pull the plug on
MSIL" but apparently we here don't know how to do it - and most of us
don't care about it. If you really want this functionality pay eziriz
the $169 licensing fee for it - or take the time to figure it out
yourself. We're not here to develop a solution for you because you
feel jipped by Microsoft. Sorry for being rude, but you seem to be
getting upset at people who have no control over a feature of the
software.

Eziriz is one of the best I've seen, but the point has been made that some
of what these packages do may not be such a good idea. I may not agree with
the pitch about security and SOA that's been made this past five years, but
I cannot ignore advice implying that removing MSIL's not a good idea either.
I may be stuck between a rock and a hard place, but considering that my
major is geology, that should come as no surprise!

I apologise if I upset anyone, but I thought someone here would know the
answer. I'm not looking for a solution. I'm just after whatever I presume I
missed in the documentation, or failing this a reference to some literature
that says something more about the internal workings of MSIL and native code
than the official documentation. A lot of the material I've been reading on
the web (and some of it by some very qualified people) has either just been
using the whole issue to promote a move to SAAS (not competetive) or just
regurgitating what's already in the documentation anyway (most bottom lining
the reason why one spaghetti source MSIL could make a mess of an otherwise
CLR view to SOA and interoperable multi-platform compatibility :^)

I've always' taken VB6's security for granted, and it was quite a shock to
discover that a VB2005 "native" executable packed a little more than what
I'd come to expect! :^) Especially considering that two versions of
the same program (one MSIL the other "native") are, combined, up to ten
times smaller than the previous VB6 native. It's most impressive, but I'd
really like to know more.

I get a little expressive when an explanation doesn't make sense to me.
Sorry if I gave the impression of getting grumpy. I appreciate the fact that
so many of you have made the effort to encourage me to think about some of
the less obvious issues.

Also, if you don't mind me asking, what type of software are you
creating that must be so secure? Don't take this the wrong way, but is
the software you are writing even worth the effort of disassembling,
rewriting, and redistributing?

It's either all been done before, or else that one grain of originality is
too hard to find amongst all the lines of code that look familiar but no,
they all seem a bit strange too! :^) You have a point! The easiest way is
just to dump the target on a test bed, note the bugs, and rebuild from
specification up. The buggier the software, the more transparent the
methodology.

I think the IP security issues mostly concern shareware - The problem is not
so much competition (this is always easiest done from scratch) or even
"trade secrets" (generally too hard to pick out from the all the "standard"
code that get's destandardised by specific requirements anyway) so much as
people cracking the trial-locking mechanism if it's too easy to see what's
going on. You get enthusiasts who'll do it in some of the harder executables
just for fun but they aren't the problem. It's when it's too easy, it's just
human nature to ahh, slip through the cracks.

Around the year of the second .NET, I started an experiement by giving away
spaghetti source for the trial-locking with and applied to a compiled
application. It got 100 downloads per month for three years and no sales!
:^) No evidence anybody even bothered to publish a crack, but the interest
didn't die off. So I'm not sure the considerably better structured MSIL
coded trial-locking mechanisms will last much longer. This leaves me
wondering what realistic options there are for shareware developers (or
"ISV"s in modernspeak) other than risking one of the most important
advantages .NET offers on unsupported IP security methodology. It would be
worth knowing more on this point, particularly with respect to what methods
make for the best balance between IP security and interoperability. What are
the pitfalls?

Thanks in advance...

 

[Number 11950 - GPEMC! Replace number with 11950]

Or just buy the http://eziriz.com/comparison.htm package ? I missed this
part. Sorry.

From the description page ("NET Reactor builds a native code wall between
potential hackers and your .NET assemblies by producing a file which cannot
be understood *directly* as CIL") my understanding is *not* that they remove
the MSIL code but rather than they further obscure the original .NET exe and
append a loader making the MSIL code unreachable from an external tool.

Then when the app is launched, the loader part loads the .NET exe part as if
it were unchanged (this means also that this could be available somewhere in
memory at this time).

At least this is my understanding of how it could work from the info
provided...

[SNIP]

No apology necessary! Thanks for sharing your understanding - very much.
Given your suggestions, perhaps not such a good idea to strip out the MSIL,
until the model evolves. In the meantime, maybe better for me to seek
compromise rather than to remove the MSIL altogether (although the problem
is a tempting challenge). This leaves the questions of what constitutes the
best balance between security and interoperability in terms of various
methods employed. What literature would you suggest...?

Thanks in advance...

 

[Number 11950 - GPEMC! Replace number with 11950]

[SNIP]

AFAIK you can't remove it, but you could make it inaccessable by
wrapping it up in a security envelope like HASP. But that would require
more money.

[SNIP]

Thank you for the suggestion. So far, what I've gleaned from my enquiries
are that:

a) Executables native to x86 & x64 architecture are all but an open book to
anyone with access to a bitpicker.
b) Obfuscation is weak in theory, but redundancy of features in MSIL
attachment to the native executable are what make the attached native code
friendlier to reverse engineers than properly obfuscated or rather corrupted
MSIL.
c) One of the unexpected but equally vital issues regarding "obfuscation"
concerns limitations to forwards compatibility and interoperability implicit
in one way obfuscation techniques that remove distinction between references
in MSIL not theoretically utilised by client operating system. The problem
here as with HTML, is that undocumented compatibility can change without
notice.

So my conclusion at this stage of my IP security inquisition is that strong
obfuscation and IP security may well be achieved at the expense of long term
software reliabilty and compatibility, and this is an issue yet to be
addressed in the documentation of many products used to protect VS2005
source code.

I'd be very interested to hear any other thoughts on this...
Thanks in Advance....

 

[C-Services Holland b.v.]

Number 11950 - GPEMC! Replace number with 11950 schreef:

[SNIP]

AFAIK you can't remove it, but you could make it inaccessable by
wrapping it up in a security envelope like HASP. But that would require
more money.

[SNIP]

Thank you for the suggestion. So far, what I've gleaned from my enquiries
are that:

a) Executables native to x86 & x64 architecture are all but an open book to
anyone with access to a bitpicker.

It's all about how hard you make it. Native code is pretty hard to
reverse engineer. You can decompile it to assembly and there are tools
that create some sort of readable code from it, but it's alot of work,

b) Obfuscation is weak in theory, but redundancy of features in MSIL
attachment to the native executable are what make the attached native code
friendlier to reverse engineers than properly obfuscated or rather corrupted
MSIL.

With obfuscation you get all the code, but it's 'unreadable' to various
degrees (depending whether you use encryption etc). But IMO it's easier
to get code from that than from native code. However, it does require
alot of work to get some readable code. It's good enough to protect
against the casual cracker, but a determined one will get it.

Unobfuscated code basically comes down to releasing your program as open
source. Anyone using reflector can look at your source and even review
the code in the language they prefer.

c) One of the unexpected but equally vital issues regarding "obfuscation"
concerns limitations to forwards compatibility and interoperability implicit
in one way obfuscation techniques that remove distinction between references
in MSIL not theoretically utilised by client operating system. The problem
here as with HTML, is that undocumented compatibility can change without
notice.

I don't really expect problems with that, since a new version of the
framework usually requires a recompile at the least. With that comes a
new obfuscation step which then is compatible with that new version. But
ofcourse I could be wrong.

So my conclusion at this stage of my IP security inquisition is that strong
obfuscation and IP security may well be achieved at the expense of long term
software reliabilty and compatibility, and this is an issue yet to be
addressed in the documentation of many products used to protect VS2005
source code.

I'd be very interested to hear any other thoughts on this...
Thanks in Advance....

I do agree that, out of the box, VS does little to really protect your IP.

Going back to the HASP solution I mentioned. That is what we're using
for protecting our IP and for licensing. Not only does it obfuscate and
crypt the MSIL, it also wraps up the whole executable into a security
envelope which can only be decrypted by the key (be it a hardlock or a
softlock). That envelope also uses various defense techiques against
decompiling/debugging tools so it's very hard to get at the IP inside it.

I won't say it's unbreakable, because nothing really is. But it's
probably your best bet if you're hardpressed to protect your IP. It's
just that much harder to break.

 

[Chris Dunaway]

Number 11950 - GPEMC! Replace number with 11950 schreef:

[SNIP]

AFAIK you can't remove it, but you could make it inaccessable by
wrapping it up in a security envelope like HASP. But that would require
more money. [SNIP]

Thank you for the suggestion. So far, what I've gleaned from my enquiries
are that:

a) Executables native to x86 & x64 architecture are all but an open book to
anyone with access to a bitpicker.

It's all about how hard you make it. Native code is pretty hard to
reverse engineer. You can decompile it to assembly and there are tools
that create some sort of readable code from it, but it's alot of work,

b) Obfuscation is weak in theory, but redundancy of features in MSIL
attachment to the native executable are what make the attached native code
friendlier to reverse engineers than properly obfuscated or rather corrupted
MSIL.

With obfuscation you get all the code, but it's 'unreadable' to various
degrees (depending whether you use encryption etc). But IMO it's easier
to get code from that than from native code. However, it does require
alot of work to get some readable code. It's good enough to protect
against the casual cracker, but a determined one will get it.

Unobfuscated code basically comes down to releasing your program as open
source. Anyone using reflector can look at your source and even review
the code in the language they prefer.

c) One of the unexpected but equally vital issues regarding "obfuscation"
concerns limitations to forwards compatibility and interoperability implicit
in one way obfuscation techniques that remove distinction between references
in MSIL not theoretically utilised by client operating system. The problem
here as with HTML, is that undocumented compatibility can change without
notice.

I don't really expect problems with that, since a new version of the
framework usually requires a recompile at the least. With that comes a
new obfuscation step which then is compatible with that new version. But
ofcourse I could be wrong.

So my conclusion at this stage of my IP security inquisition is that strong
obfuscation and IP security may well be achieved at the expense of long term
software reliabilty and compatibility, and this is an issue yet to be
addressed in the documentation of many products used to protect VS2005
source code.

I'd be very interested to hear any other thoughts on this...
Thanks in Advance....

I do agree that, out of the box, VS does little to really protect your IP.

Going back to the HASP solution I mentioned. That is what we're using
for protecting our IP and for licensing. Not only does it obfuscate and
crypt the MSIL, it also wraps up the whole executable into a security
envelope which can only be decrypted by the key (be it a hardlock or a
softlock). That envelope also uses various defense techiques against
decompiling/debugging tools so it's very hard to get at the IP inside it.

I won't say it's unbreakable, because nothing really is. But it's
probably your best bet if you're hardpressed to protect your IP. It's
just that much harder to break.

Maybe this will be of interest:

http://www.softwarepotential.com/code-protection.html

I'm not exactly sure how it will work or if it will cost, but it's
worth a look.

Chris