2008-08-15 52 views
24

我確定很多讀者都使用Lutz Roeder的.NET反射器來反編譯他們的.NET代碼。 我很驚訝我們的源代碼可以從我們編譯的程序集中重建得有多準確。我應該擔心混淆我的.NET代碼嗎?

我很想聽聽你們中有多少人使用模糊處理以及什麼類型的產品?

我確定這是一個更重要的問題,例如,您提供的通過互聯網下載的.NET應用程序,而不是爲特定客戶端定製的東西。

回答

19

我不會擔心太多。我寧願專注於推出令人敬畏的產品,獲得良好的用戶基礎,並對待客戶,而不是擔心盜用您的代碼或查看源代碼的最低用戶百分比。

+0

除非軟件包含**應受**保護的敏感數據(如私鑰和密碼) – marcolopes 2014-03-09 17:08:38

+2

@marcolopes:私鑰永遠不應隨應用程序一起提供......您可能意味着公鑰......而且密碼應該被散列,反正也不清楚文字... – 2014-12-30 10:22:05

+1

你還有什麼其他解決方案可以存儲私有密鑰?服務器訪問?如果沒有互聯網連接? – marcolopes 2015-01-03 03:17:52

3

容易我 - 如果你需要保護知識產權 - obfuicate - 如果不是。

易於使用正確的工具。

2

我認爲在一定程度上,我們都應該擔心我們的IP :)

好問題,雖然它的東西,我很希望更多地瞭解(我目前做模糊處理)。

經過與我的經理在工作中的一些討論,他說他沒有模糊,但NGEN安裝,顯然這應該足以阻止Reflector在你的組件上工作,但我不知道這是否屬實到什麼程度,所以請不要把它當作福音:)

問得好:) +1

+4

NGen不會以任何方式影響Reflector。使用NGen工具不會從系統中刪除原始組件。 – 2008-09-17 13:51:25

7

儘管我們是一家向少數客戶銷售專業軟件的小型服裝,但我們目前對所有產品進行了混淆。

我們做出這個決定有一個簡單的原因 - 我們發現一位心懷不滿的前僱員正在積極接近我們的客戶請求二進制文件 - 他有一些擔心,他打算對新功能進行反向工程以提供競爭功能。

當然,如果他使用該軟件,他仍然可以做到這一點,但沒有理由讓他輕鬆。

5

沒有新的困惑,但是很多編譯器的技巧,因爲1.1

每次使用匿名類型你IL,編譯背部採用了漂亮的晦澀的名字時

例如。每次使用yield時,都會得到一個全新的類,它實現了IEnumerable和IEnumerator(巧妙的優化,不可讀的代碼)。每當你使用匿名委託時,你會得到一個新的方法,其名稱在我知道的每一種.Net語言中都是無效的,但在IL中沒有問題。

4

@Rob庫珀

曾與我在工作 經理一些討論,他說,他不 模糊處理,但確實NGEN上安裝, apparantly應該足以 停止工作反射您 組件,但我不知道,如果這 是真實的,到什麼程度,所以請 不要把它當作福音:)

做這沒有提供任何形式的反彙編保護。首先我想像它很可能從任何安裝包(如MSI或CAB文件)中提取原始文件。

但更重要的是,Ngen在安裝程序集後運行在客戶機上。 Ngen只是迫使程序集現在編譯而不是稍後使用JIT。原始組件保持不變,並且未經修改,因爲Ngen可能無法編譯整個組件,所以它必須保持不變。

Ngen是爲了性能,而不是安全性,並沒有做任何事情來防止反彙編或使其更加困難。

+0

「我想它很可能從任何安裝包中提取原始文件,如MSI或CAB文件。」 - 是:http://superuser.com/questions/307678/how-to-extract-files-from-msi-package – 2013-05-30 03:28:03

10

請記住,混淆不是加密。恕我直言,如果有人認爲逆向工程代碼的價值,他們會做到這一點。對於託管代碼或本地代碼而言,這是真實的,不管是否混淆。當然,混淆阻礙了偶然的觀察者,但是你的生意是否真的受到了這些人的威脅?我見過的每種.NET混淆方法都讓你的開發人員變得更加艱難。

有些服務提供真正的加密功能,例如Microsoft提供的SLPS。請參閱http://www.microsoft.com/slps/default.aspx

0

模糊效果受到限制,它可能會讓隨便的人遠離。最有效的晦澀難題是隻能爲用戶提供最少量的代碼。如果可以的話,讓你的應用程序在很大程度上依賴胖服務器運行。

2

我們不使用混淆處理「非公開」應用程序,但我們將其用於公共可用應用程序。混淆的應用程序包含大量高度複雜的代碼,這使我們花費了大量的時間來編寫代碼,這就是讓我認爲混淆是必須的原因 - 至少在這種情況下。

0

同意,大多數知道如何編碼甚至一點點的人都不需要竊取您的代碼!

相關問題