如此.NET 何来商机？.NET程式可以被轻易反组译吗？

astral

如果真的有"自己独特的技术"。。。那就patent 它。。。然后等别人去偷用后再sue他

sson

原帖由 haryewkun 于 19-8-2005 12:49 AM 发表
翻版和公开源代码是不一样的事情吧。。。
翻版，别人只能够 copy binary EXE 档，无法理解你的技术是什么，也无法自行改变。任何人都很清楚他是翻版而不是原创者。
公开源代码，别人就可以明白你的技术，并 ...

确实是不一样，
不过如果别人可以轻易的“透视”你的代码，那么就和开源没什么两样。
闭源的主要目的一般都是因为中心技术

原帖由 flashang 于 19-8-2005 01:03 AM 发表
其实只要你写过的 code 的够多，
你可以轻易的从软件的控制及功能“看“到它是怎么做的，
根本不需要 decompile。

如果是要学习，open source 有太多看不完的 source code 让你下载。

一般上，看别人的 c ...

翻抄与改良的前提是：你知道其中心技术（proprietary）；否则也只是抄个表面，改良更甭说了。
中心技术是看得到，可是你无法轻易抄袭的。
就像 MAYA 和 3D Studio MAX
大家都知道其技术，可是却无法仿效，更甭说抄了。
单单编的码多是不足够的。

原帖由 astral 于 19-8-2005 06:19 AM 发表
如果真的有"自己独特的技术"。。。那就patent 它。。。然后等别人去偷用后再sue他

很多东西不是说 patent 了就可以，
没记错的话，现时流行的影像压缩编码 **** 是基于 WMV（旧版本） 外泄代码改良的。
而且要控告也不是要就成，
Sony PSX 可以控告 Bleem!（PSX 模拟器，指控关系已经停止开发），但却无法控告 ePSXe（开源 PSX 模拟器）
Connectix VGS 似乎也是 Sony 关系而停止开发（Connectix 公司将其 Virtual PC 售给微软后就“好像”不存在了，其实是被微软吞并了吧？）。
其中的种种关系、法律问题，不是三言两语说就行的。

～纯个人见解，开罪请原谅，有误请指正～

白日梦

微软吞并技术在叉屁(XP)用的有Zip压缩，Roxio光碟烧录，MP3。
好处是不像Win98SE那般麻烦又要安装WinZip，WinAmp一大堆shareware才能启动。

我每天使用的XP家和S*m**t*c/N**t*n Anti-Virus也需很常patch，有时挺烦地~
所以我才知晓这些大型软件是如何去保障（讲好听点），抓住（讲难听点）顾客的招数教你们。

白日梦

原帖由 flashang 于 19-8-2005 01:03 AM 发表
其实只要你写过的 code 的够多，
你可以轻易的从软件的控制及功能“看“到它是怎么做的，
根本不需要 decompile。

对，我就是其中一个

如果是要学习，open source 有太多看不完的 source code 让你下载。

还要有学习的精神，取人之长，补己之短。升级自制的原代码程式库，就如虎添翼。

一般上，看别人的 code 是一件很不愉快的事，你可能一面看一面比中。。。

你看别人的软件，旁观者清，当然可以写出比别人好，但有无想过，前人种树后人荫，拾便宜。

白日梦

原帖由 astral 于 19-8-2005 06:19 AM 发表
如果真的有"自己独特的技术"。。。那就patent 它。。。然后等别人去偷用后再sue他

没用的，编程不像音乐，某段相同就给别人告。

最近本地一大堆会计软件争市场，一个用VFP写，一个VB写，做同样工作 - 会计，不同的菜单，表格和开发工具就没得告。这就是表里不一法则！！！

市场上的商业用途软件，换个名字就可以争生意了。
比如 My Accounting，产品注册为 XYZ Accouting

白日梦

原帖由 haryewkun 于 18-8-2005 05:19 PM 发表
专门为个人的需求或者公司的需求而编写的软件不怕人家翻版，因为其他人得物也所用。不过共享软件的世界，也能够这样搞吗？

如果可以不断地出更新版，似乎意味着之前的版本都没有做好，都没有做到够好。

如果 ...

楼主，你可以如我般“量身订作” <- 谢 sson 取的名词，tailor made。
有固定市场，有经济保障。

haryewkun

原帖由 flashang 于 19-8-2005 01:03 AM 发表
其实只要你写过的 code 的够多，
你可以轻易的从软件的控制及功能“看“到它是怎么做的，
根本不需要 decompile。

如果是要学习，open source 有太多看不完的 source code 让你下载。

一般上，看别人的 c ...

还是有本质上的差异。只要给高手时间及资源，高手能够写出任何程式。但是，要多少时间、多少资源？测试、BUG 的时间呢？你投入的时间，是否值得这样做？

如果开放自己的源代码(source code)，即使一个普通的程式员，都有能力把你的程式码复制在他的程式里面，而他所需要的成本是零。

能够在社会上面站稳脚步的公司，一定有自己的竞争优势，也就是别人无法做到的东西。可能是掌握某些技术，可能是在某些领域已经有长远的研究成功，可能是做某些事情特别好。

open source 的 community 也不是万能的。

如果我写一个共享软件(shareware)要拿来卖钱，我不可能会写 open source community 里面已经有公开的源代码的 project，而且 open source 的比我更好。这样除非我要拿来骗骗外行人，否则那里能够卖得出去？

所以，如果我写了一个共享软件，我一定要有些东西是 open source community 里面所没有的。也许 community 里面有，但是我的是有比他们更强的技术，或者更好的界面、更快的速度等等。

这也是市场价格设定的来源。。。

我用两个月的时间写共享软件，由于花了我两个月的时间，我的成本就是六千元。如果我预估这个软件会有一百名客户，那么我只要定价马币六十元，就能够弥补成本。

我的竞争对手看到我推出这样的软件，立刻开始模仿。高手只看对方的功能或者界面，就能够推测出里面要怎么实现。他照着我的功能去写，用了一个多月，造出和我完全一模一样的产品，由于他使用的时间比较短，他的成本只有四千五百元。但是由于我的产品比较早推出，我已经争取掉了一些客户，他还能够争取的客户量就比较少。而我在这一个多月里面，又可能研发出 version 2.

但是如果无法阻止别人反编译会怎样？

我今天刚推出产品，明天竞争对手就反编译我的程式码，然后稍微修改就可以当成他们自己的。竞争对手的成本是零。即使只定价马币 10 元，他们依然很划算。这样，对花时间去研究的原作者，是绝对不公平的。他也绝对无法收回成本。

最不公平的是，客户并不知道，反而会因此而质疑你的价格。为什么别人只卖 10 元，你却要卖 60 元那么贵？

量身定做有量身定做的特点，共享软件有共享软件也有自己的特点。

目前市面上解决 C# 反编译的问题最多的解决方法，是放弃。不要做共享软件，而是把程式放在 server 上面。这是唯一别人无法反编译的方法。但这是完全另一回事了。

真奇怪，为什么 Microsoft 在推出 C# 的时候不想办法把它 compile 成 native code 呢？只要加个壳、用 native code，即使能够 crack，也无法 decompile 成 original 的 source code 了。

白日梦

真奇怪，为什么 Microsoft 在推出 C# 的时候不想办法把它 compile 成 native code 呢？只要加个壳、用 native code，即使能够 crack，也无法 decompile 成 original 的 source code 了。

电邮去向他们反映为什么那么笨的。

fxam

因主题相似，已将sson和haryewkun两帖合并。

大家可看看Remotesoft的linker，用来缩小及保护.net程式，并免除安装.net framework的麻烦。
http://www.remotesoft.com/linker/intro.html

[ 本帖最后由 fxam 于 20-8-2005 08:52 PM 编辑 ]

sson

原帖由 白日梦 于 19-8-2005 02:04 PM 发表

电邮去向他们反映为什么那么笨的。

也不能酱说，重点是它的 IL 设计，还是有其优势的。


fxam 大哥推荐的不外是个好东西，不过就不知道其对 DotNet 的执行影响有多大？
毕竟 DotNet 讲求的一个重点概念是 managed

meemee

如果这么容易被decompile，那我倒有个提议。
假设你有一个A.exe和一个B.dll连用，那么你可以编写另一个z程序把这两个档案先encrypt，然后又编写一个c程序decrypt这两个档案。用c程序来做主执行程序，decrypt之后再执行A程序。

如果怕别人会decompile你的c程序，你可以用upx之类的packer软件把它pack起来。
然后再用winrar把这3个档案作成self-extractor。

haryewkun

原帖由 meemee 于 21-8-2005 02:48 PM 发表
如果这么容易被decompile，那我倒有个提议。
假设你有一个A.exe和一个B.dll连用，那么你可以编写另一个z程序把这两个档案先encrypt，然后又编写一个c程序decrypt这两个档案。用c程序来做主执行程序，decrypt之后 ...

也就是自己做壳程序吧。

不过问题还是用 C 程序怎样包装 C# 的程序，然后可以让 C# 程序可以在执行的时候解开，并让 CLI 可以读到及执行，这个才是问题吧。

meemee

原帖由 haryewkun 于 21-8-2005 03:33 PM 发表


也就是自己做壳程序吧。

不过问题还是用 C 程序怎样包装 C# 的程序，然后可以让 C# 程序可以在执行的时候解开，并让 CLI 可以读到及执行，这个才是问题吧。

CLI是什么？common language interface，不过我不知道这东东有什么作用。
.net frame的link library?还是.......

原则上我觉得它是行得通，不过还有些弱点(当然还有你说的难题)。
假设你篇程的“壳程序”可以被decompile，那些加密过“子程序”就没有保障。
所以我有多提议你用upx这软件来包装“壳程序”。

upx是用来包装exe档，不知道你们有没有用过或听过。
不过我不肯定它的效果是不是比Dotfuscator差，还是好。

goatstudio

原帖由 haryewkun 于 21-8-2005 03:33 PM 发表


也就是自己做壳程序吧。

不过问题还是用 C 程序怎样包装 C# 的程序，然后可以让 C# 程序可以在执行的时候解开，并让 CLI 可以读到及执行，这个才是问题吧。

之前在 Java 市场上不乏这种公司, 但之后个个似乎都销声匿迹了.
我想也许 Java / .Net 都一样有种因素而难以达到满意的效果吧.
其中一个也许就是 Java/.Net 都靠着安装在客户端(或 server 端) 的强大 library 运行吧, 要是把它们转去 native code, 整个软件会变的很大... library 也许也会不完整... 更不用说正常运行了.

sson

原帖由 meemee 于 21-8-2005 02:48 PM 发表
如果这么容易被decompile，那我倒有个提议。
假设你有一个A.exe和一个B.dll连用，那么你可以编写另一个z程序把这两个档案先encrypt，然后又编写一个c程序decrypt这两个档案。用c程序来做主执行程序，decrypt之后 ...

加密和加壳其实并不能真正达到良好的效果，反之还会降低效率。
小章鱼用加壳来说：
简单的加壳，其实就是把原文件（加密处理或没有）包含在壳程式中，运行时壳程式把原文件取出（解密处理）然后再执行
酱的话，如有加密，密码必定在壳程式中，要取之对高手不是一件艰难的事。
不过无论有没有加密，运行必定要把原文件取出，取出后原文件就是赤裸裸的了，
Windows 中为了确保必定可写的地方不外那几个（像 temparary folder），只要监视那几个地方就可以了。
当然，不否认还有其它方法，如直接在记忆体中执行原文件等等
haryewkun 朋友介绍的 MaxtoCode 似乎就是这类。

总的来说，简单的加壳并没有达到效果，与其花时间、精力来做，倒不如直接用 InstallShield、InstallMaker、NSIS，
或直接就 self-extractor 就可以了。
至于复杂的加壳，要用如此的时间和金钱、精力来开发额外的壳程式，还不如直接用 C/C++ 来开发更好不是？

原帖由 goatstudio 于 23-8-2005 12:08 AM 发表
之前在 Java 市场上不乏这种公司, 但之后个个似乎都销声匿迹了.
我想也许 Java / .Net 都一样有种因素而难以达到满意的效果吧.
其中一个也许就是 Java/.Net 都靠着安装在客户端(或 server 端) 的强大 libra ...

其实变得很大对独立发售的产品来讲不是问题吧
即使把整个 WindowsXP 包含也不过一张光碟(700MB)罢了

其实小章鱼觉得要把 JAVA/DotNet 产品 compile 成 native code 应该是可以的
最多是少一些功能罢吧？而在有 framework 安装的状况下，应该是没有任何问题呀。

或许小章鱼的理解层面还不够……

haryewkun

原帖由 sson 于 26-8-2005 03:45 PM 发表
加密和加壳其实并不能真正达到良好的效果，反之还会降低效率。
小章鱼用加壳来说：
简单的加壳，其实就是把原文件（加密处理或没有）包含在壳程式中，运行时壳程式把原文件取出（解密处理）然后再执行
酱的话，如有加密，密码必定在壳程式中，要取之对高手不是一件艰难的事。
不过无论有没有加密，运行必定要把原文件取出，取出后原文件就是赤裸裸的了，
Windows 中为了确保必定可写的地方不外那几个（像 temparary folder），只要监视那几个地方就可以了。
当然，不否认还有其它方法，如直接在记忆体中执行原文件等等
haryewkun 朋友介绍的 MaxtoCode 似乎就是这类。

不见得，这要看怎样做。如果是 JIT 解压缩的话，速度不但不会比本来慢，还会更快，因为直接跳过从 MSIL 转 Native Code 这个阶段。至于原文件，防止的方法多的是，很少人会直接把程式解压到 directory 的啦！多数人的做法，都是把程式解压到 memory 里面，或者甚至动态解压，需要用那个模组的时候才解压，用完了又动态消除掉。MaxtoCode 听说就是动态解压的，可惜我无缘一试。动态解压的再加上反跟踪的技巧，能破解的人就少得多了。

原帖由 sson 于 26-8-2005 03:45 PM 发表
其实变得很大对独立发售的产品来讲不是问题吧
即使把整个 WindowsXP 包含也不过一张光碟(700MB)罢了

问题是一个 EXE 就几十 MB，你怎么看？不是安装程式大，是执行程式大，那个才是问题。而且 shareware 多数都是通过网际网路下载的，程式那么大，谁要去使用你的 shareware？这个就是问题了。

goatstudio

原帖由 sson 于 26-8-2005 03:45 PM 发表

其实变得很大对独立发售的产品来讲不是问题吧
即使把整个 WindowsXP 包含也不过一张光碟(700MB)罢了

其实小章鱼觉得要把 JAVA/DotNet 产品 compile 成 native code 应该是可以的
最多是少一些功能罢吧？而在有 framework 安装的状况下，应该是没有任何问题呀。

或许小章鱼的理解层面还不够……

在改装成 native code 的前提条件是, 要摆脱安装 JVM/Framework 的困境.
如果安装了这些 virtual machine, 那么改成 native code 还有什么意义呢?

如果改装后, 软件变成很"大块", 这就要看各种条件下的考量了, 例如是否放在 CD-ROM/DVD-ROM 一起发售? 是否是 shareware? ... 等等...

flashang

如果想把程式变成 native code, 首先不能用 eval 或把 variable name 当做特殊 reference 的功能，还有一些 function 可能要重写。

其次就是你所用的 .net framework 或 library 也可以变成一个 dll 或加在自己的 exe 里。

然后就是用一些 converter 把 code 变成 c / c++

这是我从 SourceForge 一些 basic -> c, xbase -> c, ?? ->, ?? -> pascal 所看到可能的做法。

haryewkun

原帖由 flashang 于 28-8-2005 09:55 PM 发表
然后就是用一些 converter 把 code 变成 c / c++

有 converter 可以把 C# 转换成 C/C++ 吗？

我倒是从未想过这个方法，所以不知道可行与否。

flashang

原帖由 flashang 于 28-8-2005 09:55 PM 发表
如果想把程式变成 native code, 首先不能用 eval 或把 variable name 当做特殊 reference 的功能，还有一些 function 可能要重写。

其次就是你所用的 .net framework 或 library 也可以变成一个 dll 或加在自己 ...

有 converter 可以把 C# 转换成 C/C++ 吗？

我倒是从未想过这个方法，所以不知道可行与否。

就算有 c# => c/c++， 那么你的 .net framework 也许要重写。。。