Running .Net 2.0 Application without having .Net Framework installed

  • Thread starter Thread starter schworer
  • Start date Start date
S

schworer

I have an odd question.

Is it possible to run a .Net 2.0 Applicaiton on a machine that does not
have the .Net Framework installed on it? If it is, please provide
details on how to accomplish this.

Thanks,
Andy
 
Yes, you can do this, using the following means:

1. Purchase our linker/native compiler tool.
http://www.remotesoft.com/linker/
It can even natively compile your .exe to x86 code, and runs without
..NET Framework. The resulting package guarantee you the following:

(1) The best performance and best startup time. It beats any
competition.
(2) Simply the best source code protection. All code are in native x86
format. Guaranteed that your code is not able to be reverse engineered.
No other product can achieve this. For more info, check out:
http://www.remotesoft.com/deprotector

2. If you want to do it on your own for free, you can use the following
undocumented features to deploy your app with a subset of Microsoft
..NET Framework included. This is only usefuk for simple windows
application. For complex apps, you will need to implement a virtual
registry system to include some registry setting:

(1) set COMPLUS_InstallRoot environment variable to your appdir. This
is not public API, but it works.
(2) copy the framework directory
c:\windows\microsoft.net\framework\v1.14322, or v2.0.50727 into your
application dir. You can remove unused files by launching your
application
(3) create a local GAC dir inside your application dir, and copy all
GAC assemblies into your local gac.

Huihong
RemoteSoft, Inc.
 
Huihong said:
Yes, you can do this, using the following means:

1. Purchase our linker/native compiler tool.
http://www.remotesoft.com/linker/
It can even natively compile your .exe to x86 code, and runs without
.NET Framework. The resulting package guarantee you the following:

(1) The best performance and best startup time. It beats any
competition.
(2) Simply the best source code protection. All code are in native x86
format. Guaranteed that your code is not able to be reverse engineered.
No other product can achieve this. For more info, check out:
http://www.remotesoft.com/deprotector

2. If you want to do it on your own for free, you can use the following
undocumented features to deploy your app with a subset of Microsoft
.NET Framework included. This is only usefuk for simple windows
application. For complex apps, you will need to implement a virtual
registry system to include some registry setting:

(1) set COMPLUS_InstallRoot environment variable to your appdir. This
is not public API, but it works.
(2) copy the framework directory
c:\windows\microsoft.net\framework\v1.14322, or v2.0.50727 into your
application dir. You can remove unused files by launching your
application
(3) create a local GAC dir inside your application dir, and copy all
GAC assemblies into your local gac.

Huihong
RemoteSoft, Inc.
Click to expand...
It has to be said, I still don't get why so many people seem to want to
do this. Yes, requiring a 23MB download may seem prohibitively
expensive... IF your application is the only .NET application installed
on a users machine. But consider how much space you're saving the user
if you and 20 other applications all install the bits of .NET framework
they need as separate copies...

Then, of course, when a security bug is found in the framework, but the
user hasn't installed the framework by this point, you have 20
unpatched copies of the framework installed on the users machine (not
sure whether, if the framework is properly installed, then that version
will be used or not)

So my recommendation is - if you're developing a downloaded
application, point users at window update. If you're a CD or DVD based
app, bung the redistributable on it. In the long run, the users will
thank you for leaving them with a *standard* setup.

Damien
 
Agree. Plus these "compiled" options are much bigger exe's. If everyone
did this, they would end up being bigger then the framework on your HD.

--
William Stacey [MVP]

| Huihong wrote:
| > Yes, you can do this, using the following means:
| >
| > 1. Purchase our linker/native compiler tool.
| > http://www.remotesoft.com/linker/
| > It can even natively compile your .exe to x86 code, and runs without
| > .NET Framework. The resulting package guarantee you the following:
| >
| > (1) The best performance and best startup time. It beats any
| > competition.
| > (2) Simply the best source code protection. All code are in native x86
| > format. Guaranteed that your code is not able to be reverse engineered.
| > No other product can achieve this. For more info, check out:
| > http://www.remotesoft.com/deprotector
| >
| > 2. If you want to do it on your own for free, you can use the following
| > undocumented features to deploy your app with a subset of Microsoft
| > .NET Framework included. This is only usefuk for simple windows
| > application. For complex apps, you will need to implement a virtual
| > registry system to include some registry setting:
| >
| > (1) set COMPLUS_InstallRoot environment variable to your appdir. This
| > is not public API, but it works.
| > (2) copy the framework directory
| > c:\windows\microsoft.net\framework\v1.14322, or v2.0.50727 into your
| > application dir. You can remove unused files by launching your
| > application
| > (3) create a local GAC dir inside your application dir, and copy all
| > GAC assemblies into your local gac.
| >
| > Huihong
| > RemoteSoft, Inc.
| >
| >
| It has to be said, I still don't get why so many people seem to want to
| do this. Yes, requiring a 23MB download may seem prohibitively
| expensive... IF your application is the only .NET application installed
| on a users machine. But consider how much space you're saving the user
| if you and 20 other applications all install the bits of .NET framework
| they need as separate copies...
|
| Then, of course, when a security bug is found in the framework, but the
| user hasn't installed the framework by this point, you have 20
| unpatched copies of the framework installed on the users machine (not
| sure whether, if the framework is properly installed, then that version
| will be used or not)
|
| So my recommendation is - if you're developing a downloaded
| application, point users at window update. If you're a CD or DVD based
| app, bung the redistributable on it. In the long run, the users will
| thank you for leaving them with a *standard* setup.
|
| Damien
|
 
Guaranteed that your code is not able to be reverse engineered.

Excuse me, but that is nonsense. If the code can be executed, it can
also be reverse engineered.
 
I guess what I meant here is not able to convert to source code using
any decompilers. Of course, you can disassemble the x86 instructions,
and follow the debugger to extract certain info, but there is no
decompiler available to turn that into source code. The original .NET
images, before native compilation, can be very easily decompiled. If
you think you have better ways than native code to defend against
reverse engineering, I would be deadly suprised. This is the BEST
protection.
 
True. But most of the time the goal is not so much to protect the source
(that is one goal), but to protect the license logic to prevent free
distros. That is still easy to do with a debugger on native code to create
a patch to jump around stuff. That said, that will always be possible TMK.

--
William Stacey [MVP]

I guess what I meant here is not able to convert to source code using
any decompilers. Of course, you can disassemble the x86 instructions,
and follow the debugger to extract certain info, but there is no
decompiler available to turn that into source code. The original .NET
images, before native compilation, can be very easily decompiled. If
you think you have better ways than native code to defend against
reverse engineering, I would be deadly suprised. This is the BEST
protection.
 
It's not really HD space that's the problem - disks are huge and cheap these
days. Memory, on the other hand, i still relatively small and expensive.

The main problem is that you can use up more memory runing several apps that
would otherwise share DLLs.

I can see the point of turning an app into an exe but I don't see why one
would want to statically link in the framework. As mentioned, it prevents
the use of bug fixes in the framework and the framework dlls are already
precompiled and likely to be shared with other apps. I suppose that it makes
it that bit harder to reverse engineer but the cost doesn't seem worth it
and (unless they mess with the x86 code itself) a decompiler could easily
deduce the framework calls by comparing code in the exe with the dlls.
 
I have seen far better protection, like code that is decrypted in
realtime as it is executed. There you have something that is really hard
to reverse engineer. Native code is childs play in comparison, and
hardly the BEST.
 
You are again talking about a different thing. I said the BEST
protection against people to get back the source code from .NET
assemblies.

Let's do this: give me some .NET assembly that you think is better
protected and decrypted at runtime, I will get the source code for you.
In turn, I will give you a native compiled .NET assembly, I bet you
just won't be able to get the source code back. Is this simple?

All you are talking about is to prevent some kind of license key
hacking and cracking piece of the code.

In terms of encrypt and decrypt at runtime, it's nothing to protect
..NET code, may be good for native code. You don't see that the CLR
engine needs to be feeded with IL code, no matter how fancy you do with
the encryption, by the time code is executed, it MUST be in IL code
format. I can easily dump them out at that moment. If that is what you
think the best protection, that's nonsense.

The encryption/decryption/anti-debugging/anti-tracing/memory protection
on top of native code is another layer of protection, but only after
native code is available, which is what exactly our tool does right
now. Without native code, those means don't make sense.

There are so many people claim that native code is as easy decompiled
as Java/.NET, I just don't buy it. It is a totally false statement, and
very deceiving. The scale and easiness of decompilation is so much
different. Give you a 5 MB native exe, you will be overwhelmed by
disassembling, the most one can do is to crack some keys. On the other
hand, give you a 5 MB .NET assembly, one can easily dump out all source
code.
 
Huihong said:
You are again talking about a different thing. I said the BEST
protection against people to get back the source code from .NET
assemblies.

Let's do this: give me some .NET assembly that you think is better
protected and decrypted at runtime, I will get the source code for you.
In turn, I will give you a native compiled .NET assembly, I bet you
just won't be able to get the source code back. Is this simple?
Click to expand...

Of course one can't get the source code back. That is impossible as soon
as you compile the code without including debug information. You don't
need to compile it to native code for that.
All you are talking about is to prevent some kind of license key
hacking and cracking piece of the code.

In terms of encrypt and decrypt at runtime, it's nothing to protect
.NET code, may be good for native code. You don't see that the CLR
engine needs to be feeded with IL code, no matter how fancy you do with
the encryption, by the time code is executed, it MUST be in IL code
format. I can easily dump them out at that moment. If that is what you
think the best protection, that's nonsense.

The encryption/decryption/anti-debugging/anti-tracing/memory protection
on top of native code is another layer of protection, but only after
native code is available, which is what exactly our tool does right
now. Without native code, those means don't make sense.
Click to expand...

Of course I was not talking about encrypted managed code. That would be
pointless. I am surprised that you even thought that I did.

When you are talking about compiling to native code as the BEST
protection, it sounds like there is nothing more advanced that you could
ever do. I merely pointed out that I have seen protection that go far
beyond that.
There are so many people claim that native code is as easy decompiled
as Java/.NET, I just don't buy it. It is a totally false statement, and
very deceiving. The scale and easiness of decompilation is so much
different. Give you a 5 MB native exe, you will be overwhelmed by
disassembling, the most one can do is to crack some keys. On the other
hand, give you a 5 MB .NET assembly, one can easily dump out all source
code.
Click to expand...

Decompiling native code doesn't differ much from decompiling IL code.
The process to produce the native code is reversible in the same manner
that the process to produce IL code is.
 
In theory, native assembly instructions can be put back to c/c++ code,
but there is no good decompiler for native code yet, and I doubt that
it will be ever available. The reason is the lacking of metadata, not
due to the difficulty of control flow analysis. Suppose someday,
someone come up with a very good native decompiler, the best can do is
to have some good c code with all symbol names based on memory
addresses, with no meaningful class/method names, the quality is still
much much poorer than those from decompiling java and .NET, as the
latter contains all class/method names. Therefore, I always believe
native code is much much more difficult than java/.net in terms of
decompilation. Believe me, I've been working on
decompilers/obfuscators/protectors for a few years, and that's my
foundings. (I am actually working on a native decompiler for x86,
without debugging symbols, still overwhelmed by the huge amount of c
code).
 
Göran Andersson said:
Of course one can't get the source code back. That is impossible as soon
as you compile the code without including debug information. You don't
need to compile it to native code for that.
Click to expand...

How? I don't see any way except encryption/decryption to do that.
If you don't compile Java or .NET bytecode to native code, no way to
stop getting source code back. The debug info is not needed at all for
these byte code, since the .NET assemblies and java classes themself
contains everything even if release build with optimization is done.
 
Huihong said:
How? I don't see any way except encryption/decryption to do that.
If you don't compile Java or .NET bytecode to native code, no way to
stop getting source code back. The debug info is not needed at all for
these byte code, since the .NET assemblies and java classes themself
contains everything even if release build with optimization is done.
Click to expand...

You can create source code that does the same thing as the original
source code, but you can't get the original source code back.
 
Are you saying that you can rewrite manualyl to mimic the
functionality? Now, this is very different from our topic on
decompilation. No one can stop you from doing that: rewriting from
scratch after studying a program's behavior and functionality.

As long as highly readable source code can be retrieved, who cares
whether or not the decompiled source code is exactly same as the
original. If you try our .NET Decompiler, you will see how closely a
decompiler can go. Most of the constructs are same after decompilation.


So you agree without native compilation, there is no way to stop people
from getting source code from .NET assemblies (and Java classes, or
other byte code based formats)!
 
Huihong said:
Are you saying that you can rewrite manualyl to mimic the
functionality? Now, this is very different from our topic on
decompilation. No one can stop you from doing that: rewriting from
scratch after studying a program's behavior and functionality.
Click to expand...

No, that's not what I am saying.
As long as highly readable source code can be retrieved, who cares
whether or not the decompiled source code is exactly same as the
original. If you try our .NET Decompiler, you will see how closely a
decompiler can go. Most of the constructs are same after decompilation.


So you agree without native compilation, there is no way to stop people
from getting source code from .NET assemblies (and Java classes, or
other byte code based formats)!
Click to expand...

No. Don't try to put words in my mouth.

I am saying that reverse engineering can be done even if you do a native
compilation. There is nothing magical that is done. The process is
automatic and deterministic, just as compiling to IL code, and therefore
it can be reversed.
 
Then show me some example, or list some tools that can automatically
decompile native code to source code, same or even poor quality than C#
assemblies. In pratice, people need to rewrite the program after
cracking some algorithms from naitve compiled code, the scale and
easiness is totally different from decompiling C# and Java. You can't
just claim native code is easily decompilable without any real
substance. If you can use a tool to decompile the simple Notepad.exe in
windows directory, and show me the source code, we will see! I can do
it very easily for even larger C# executable files.
 
Huihong said:
Then show me some example, or list some tools that can automatically
decompile native code to source code, same or even poor quality than C#
assemblies. In pratice, people need to rewrite the program after
cracking some algorithms from naitve compiled code, the scale and
easiness is totally different from decompiling C# and Java. You can't
just claim native code is easily decompilable without any real
substance. If you can use a tool to decompile the simple Notepad.exe in
windows directory, and show me the source code, we will see! I can do
it very easily for even larger C# executable files.
Click to expand...

I don't think that'd be a good idea, since that would almost certainly
break the windows EULA (which contains a provision prohibiting the
reverse engineering of the software)

Damien
 
| "Damien said:
| It has to be said, I still don't get why so many people seem to want to
| do this. Yes, requiring a 23MB download may seem prohibitively
| expensive... IF your application is the only .NET application installed
| on a users machine. But consider how much space you're saving the user
| if you and 20 other applications all install the bits of .NET framework
| they need as separate copies...
Click to expand...
:
Agree. Plus these "compiled" options are much bigger exe's. If everyone
did this, they would end up being bigger then the framework on your HD.
Click to expand...

Unfortunately, this is a huge problem for any vendor wishing to sell .NET
software. This is by far our biggest complaint about Microsoft. It's
inconceivable that Microsoft would invest so much in the excellent .NET
platform and then fail to ensure that it's installed on every PC. Our only
guess is that Microsoft is leery of forcing an install because then they may
be also forced to install the JavaVM.

We have spent the past few years (as part of Mini-Tools and my previous
company) dealing with the .NET issue. Now that the issue of having .NET 1.1
installed is finally waning, here we go again with .NET 2.0. We are unable
to upgrade and take advantage of the many new features and bug fixes in VS
2005 and .NET 2.0 because (from our data) less than 10% of our target
customers have .NET 2.0 installed, and less than half of those without are
willing to download the framework. Last week I bought a new HP PC for my
father at Best Buy, and even though it's seven months after the release of
..NET 2.0, only .NET 1.1 was pre-installed. As informed programmers, we all
know that .NET 2.0 is a benign & beneficial download, but try telling a
customer on dialup that they need to download a 20+MB file just to run our
program. We are losing downloads, evaluations and sales because of our
support for .NET.

Microsoft, if you are listening, the single most important thing that you
can do to help ISVs supporting the Microsoft .NET platform is to force
install .NET 2.0 on every PC as part of the next Windows update. Pretty
please with sugar on top!!
 
Back
Top