remotesoft
Mon Aug 16 13:15:20 CDT 2004
I think MSIL code is the hardcore feature, if you think that is not
important, then it is tough to argue.
ILMerge does NOT selectively link MSIL code, there is absolutely NO other
tool can link an EXE with framework class libraries (DLLs). Please try your
best to link the Scribble.exe with ILMerge, it won't work, say nothing of
the size. Salamander linker is the only tool that can link an EXE with all
required framework MSIL code. The original Scribble.exe is about 50KB, the
linked exe is 2.6MB without any compression. ILMerge or other tools just
can't do that. Show me an example if you think otherwise. ILMerge is good
for merging (not selectively link) your own DLLs into your own exe, but it
doesn't resolve type conflicts. In addition, there are much more need to be
done besides msil code, resources, serialization, config section handlers,
etc. In short, my statement, "salamander linker is the only tool that can
link framework assemblies", holds true at the moment.
Another thing about ILMerge is its license, it meant only for educational
and research use.
As for pre-ngening assemblies with Thinstall, I definitely don't think it is
going to work. Ngened images must be done on installation time since it
needs the target CPU and OS info, I don't see how pre-packing
ngened-assemblies will work.
Our linker/minideployment tool contains an virtual registry which handle all
COM/ActiveX registration. You can include whatever unmanaged components, for
instance, Crystal reports runtime, MDAC, etc., into the mini-deployed app,
and the app can be launched from a CD. There is no system changes at all.
I can say, the only difference is that Thinstall performs additional step of
putting everything into an exe, while our linker tool generates a directory
package, all of the other features are about the same. Once we provide the
option of wrapping averything into a single exe, I don't see difference.
However, as I stated before, our tool provides a unique feature of
selectively linking MSIL code together.
One of the most popular site is implementing our linker/mini-deployment
tool, I don't know why it is not suitable for professional use.
As for code protection, since our linker tool links framework libraries into
your exe, so those public APIs can be renamed after obfuscation. This is not
to do which obfuscator to use, it rather introduces a unique feature to
reduce vonerable spots. Again, our linker is the only tool can do this. Show
me an example if there is another tool that can safely remove
System.Windows.Forms APIs from your exe.
If the underlying files are all protected well against reverse engineering,
I don't know why they can not be seen.
Well, this is a rather long message. I'll stop here. As for the size of our
company, we have an office in Santa Clara with 2 full time employees and
several parttime developers. We also have another office with several full
time developers in Beijing. We are continuing to grow.
Thanks,
Huihong
"Jonathan Clark" <jonathanclarkcom@gmail.com> wrote in message
news:51b38f9a.0408152357.75405102@posting.google.com...
> > (1) impossible (or very difficult) to update the contained files
>
> It's quite easy:
>
http://thinstall.com/help/updating_netapplicationsaft.htm
> Thinstall offers 3 different methods of updating files. The most
> secure method is to use patch files, then the user never has access to
> your assemblies.
>
> Thinstall allows all the files to be located on the hard drive (in
> this manner it's exactly the same as remotesoft's linker), simply by
> selecting the option "Extract on Start" or "Extract on Install". But
> this is bad security-wise. It's very easy to modify assemblies,
> change the configuration files, and cause the application to load
> other assemblies and/or do things it shouldn't. When .NET 2.0 is
> released, you can upgrade your application to use .NET 2.0 on the
> user's computer by replacing a single file, that's pretty attractive
> in my book.
>
> The thing with remotesoft linker is that anyone can look at the
> directory listing and immediately tell 2 things even without pulling
> out a disassembler:
>
> 1. This application uses .NET and I can edit config files or decompile
> DLLs
> 2. This application uses remote soft linker
>
> With local security, obscurity is the most important thing. That's
> the only defense you have against 1. Hackers trying to break your
> software, 2. Protecting your IP from theft, 3. Protecting your company
> from IP litigation. All local security can be broken, no one disputes
> that. But with Thinstall people don't know you are using it or that
> you are using .NET - because all they see is a single encrypted EXE.
>
> > (2) impossible to support NGEN utility. Since it requires dynamic
generation
> > of native code based on the target CPU,s you can't include the ngen-ed
> > files inside the "self-extracting" EXE.
>
> Not so, you can call ngen.exe directly from your application and the
> resulting ngen'ed assemblies will be generated on the hard drive.
> Alternatively you can package pre- jit'ed EXE/DLL files. The native
> image directory is stored under
> %installPath%\framework_files\native_images
>
> > (1) When we say linking, it means the MSIL code of multiple
> > assemblies/modules are linked into one file, just as the C/C++ linker
does;
> > Thinstall doesn't do this.
>
> I don't see this as important, one can use a free utility from
> Microsoft called ILMerge to accomplish the same thing. Thinstall is
> completely compatible with .NET applications created by ILMerge.
>
http://research.microsoft.com/research/downloads/#ILMerge
>
> This functionality is available in Widbey, so using an outside tool
> will just mean headaches when you upgrade to the new version of .NET.
> It's a good idea, but it's better to use microsoft's tool to do it
> rather than remotesoft's, since I trust MS to do a better job.
>
http://blogs.msdn.com/grantri/archive/2004/06/01/145724.aspx
>
> Thinstall now has alpha support for Whidbey / .NET 2.0, and it will be
> ready when MS "goes gold".
>
> > Therefore, I can safely say our tool
> > always generate smaller package than Thinstall does.
>
> You probably haven't check your sizes. Thinstall can generate a
> helloworld.exe of 2.5MB, what is the smallest program produced by
> remotesoft linker? With remotesoft linker it would be several times
> larger and then you have to use a separate ZIP/installer program.
> These are not going to compress as well as Thinstall.
>
> > (2) Our linker/mini-deployment tool supports managed DLLs, for example,
you
> > can mini-deploy an Office addin, or an IE windows forms user controls,
etc.
> > Thinstall does not support DLL.
>
> Thinstall supports packaging DLLs, there are samples on our website.
> The only thing Thinstall doesn't support is ASP.NET, and middle-ware
> .NET DLLs sold as tools to other developers, and I don't think yours
> does either.
>
> > (4) Since our tools can link/embed system framework libraries (e.g.,
> > System.Windows.Forms.dll, System.Data.dll) into your own managed exe,
you
> > can now perform an obfuscation that removes public APIs, thus
fundamentally
> > increases security against reverse engineering. This is the first tool
that
> > allows framework libraries to be linked into your own code.
>
> As I mentioned ILMerge and Whidbey provide similar functionality when
> combined with any obfuscator. Thinstall can be used in combination
> with 100% of all obfuscators, including Remotesoft's products and
> Dotfuscator.
>
> My main questions as developer would be:
>
> 1. Do I want people to know I'm using .NET and a linker?
> 2. Do I want people to be able to modify my application without my
> permission?
> 3. Do I want to deploy solutions as a single file or a big list of
> files?
> 4. Do I need to link 3rd party libraries written in different
> languages such as c++ and VB?
> 5. Do I need use COM & ActiveX controls without registration (on
> Guest/Restricted user accounts).
> 6. Do I want the ability to upgrade to .NET 2.0 by replacing a single
> file?
>
> If these issues weren't important and I was creating a simple Freeware
> application, then I might use Remotesoft's linker because it's
> cheaper. I understand that for small developers the price is very
> important and Thinstall is targeted at professional developers. We
> help some of the biggest customers in the world, but we also have a
> lot of 1 person software companies who depend on Thinstall. When you
> are doing something a little non-standard, you'll want to make sure
> you are have a company that's going to support you and stick around.
> Jitit has been in business since 1998 and has four fulltime employees
> (all developers) with offices in Downtown San Francisco.
>
http://thinstall.com/help/customerquotes.htm
>
> Jonathan Clark
> President / Jitit