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

"Damien" <Damien_The_Unbelie***@hotmail.com> wrote in message
news:1146122135.157815.95660@y43g2000cwc.googlegroups.com...
| 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
|

"William Stacey [MVP]" <william.sta***@gmail.com> wrote in message
news:ObRaXglaGHA.3304@TK2MSFTNGP04.phx.gbl...
> 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]
>
> "Damien" <Damien_The_Unbelie***@hotmail.com> wrote in message
> news:1146122135.157815.95660@y43g2000cwc.googlegroups.com...
> | 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.

> > 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.
>
> Göran Andersson wrote:
>>> 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 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.
>
> Huihong wrote:
> > 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.
> >
> > Göran Andersson wrote:
> >>> 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.
> >

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

> Göran Andersson wrote:
>> 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.
>>
>> Huihong wrote:
>>> 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.
>>>
>>> Göran Andersson wrote:
>>>>> 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.
>

> Huihong wrote:
> > 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?
>
> 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.
>
> 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.
>
> 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.
>
>
> > Göran Andersson wrote:
> >> 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.
> >>
> >> Huihong wrote:
> >>> 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.
> >>>
> >>> Göran Andersson wrote:
> >>>>> 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.
> >

> Huihong wrote:
> > Göran Andersson wrote:
> >> 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.
> >
> > 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.
> >
>
> 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.

> Göran Andersson wrote:
>> Huihong wrote:
>>> Göran Andersson wrote:
>>>> 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.
>>> 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.
>>>
>> 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.
>