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...

--
Timothy Casey GPEMC! >11950 is the nu****@fieldcraft.com.au 2email
Terms & conditions apply. See www.fieldcraft.biz/GPEMC
www.fieldcraft.biz & www.speed-reading-comprehension.com
www.geologist-1011.com & www.web-design-1011.com

[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" <nu****@fieldcraft.biz>
schreef in bericht news:46***********************@news.optusnet.com.a u...

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...

--
Timothy Casey GPEMC! >11950 is the nu****@fieldcraft.com.au 2email
Terms & conditions apply. See www.fieldcraft.biz/GPEMC
www.fieldcraft.biz & www.speed-reading-comprehension.com
www.geologist-1011.com & www.web-design-1011.com

[Number 11950 - GPEMC! Replace number with 11950]

"Cor Ligthert[MVP]" <no************@planet.nlwrote in message
news:D0**********************************@microsof t.com...

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...

--
Timothy Casey GPEMC! >11950 is the nu****@fieldcraft.com.au 2email
Terms & conditions apply. See www.fieldcraft.biz/GPEMC
www.fieldcraft.biz & www.speed-reading-comprehension.com
www.geologist-1011.com & www.web-design-1011.com

[=?Utf-8?B?Q2hhcmxpZQ==?=]

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.

[=?Utf-8?B?Q2hhcmxpZQ==?=]

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

[Number 11950 - GPEMC! Replace number with 11950]

"Charlie" <cfarrier at charlesfarriersoftware.comwrote in message
news:FD**********************************@microsof t.com...

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/dotne...g-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...
--
Timothy Casey GPEMC! >11950 is the nu****@fieldcraft.com.au 2email
Terms & conditions apply. See www.fieldcraft.biz/GPEMC
www.fieldcraft.biz & www.speed-reading-comprehension.com
www.geologist-1011.com & www.web-design-1011.com

[=?Utf-8?B?Q2hhcmxpZQ==?=]

"Number 11950 - GPEMC! Replace number wit" wrote:

"Charlie" wrote in message
news:FD**********************************@microsof t.com...

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

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.

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/dotne...g-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.

>
Thanks in Advance...
--
Timothy Casey GPEMC! >11950 is the nu****@fieldcraft.com.au 2email
Terms & conditions apply. See www.fieldcraft.biz/GPEMC
www.fieldcraft.biz & www.speed-reading-comprehension.com
www.geologist-1011.com & www.web-design-1011.com

[Number 11950 - GPEMC! Replace number with 11950]

"Charlie" <c2farrATyahoo.comwrote in message
news:91**********************************@microsof t.com...

>

"Number 11950 - GPEMC! Replace number wit" wrote:

[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...???

--
Timothy Casey GPEMC! >11950 is the nu****@fieldcraft.com.au 2email
Terms & conditions apply. See www.fieldcraft.biz/GPEMC
www.fieldcraft.biz & www.speed-reading-comprehension.com
www.geologist-1011.com & www.web-design-1011.com

[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.
--
Rinze van Huizen
C-Services Holland b.v

[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

[Number 11950 - GPEMC! Replace number with 11950]

"Chris Dunaway" <du******@gmail.comwrote in message
news:11**********************@o80g2000hse.googlegr oups.com...

[SNIP]

>
Maybe this will be of interest:

[SNIP]

Thank you Chris, I have had a look. It's inspiring to say the least,
although diagramatic representation(?) of an obfuscation technique without
the textual explanation seems a bit unusual.

There has been a start to this with the definition of specific "Setup"
behaviours in VB2005 - however, program behaviour also needs to be modified
in trial versions necessitating either a component or wrapper.

One of the problems with encrypted code is that it winds up decrypted in
memory somewhere, and knowing virtual memory, somewhere on the disk as well.
This is what happens to served material that's run client side but
"protected" - just sitting in a temporary directory - a potential issue with
SAAS based approached to IP protection.

I plan to run a pilot study on respective conversion rates of straight
versus obfuscated trial locking mechanism, using a simplified application
based purchasing system in otherwise identical products referenced at
random. I'll publish the results on my site when the study hits three
months, probably early January next year...

Anyway, I've sent Microsoft an email to see where they are at with SLP.

Thanks again...

--
Timothy Casey GPEMC! >11950 is the nu****@fieldcraft.com.au 2email
Terms & conditions apply. See www.fieldcraft.biz/GPEMC
www.fieldcraft.biz & www.speed-reading-comprehension.com
www.geologist-1011.com & www.web-design-1011.com