當前位置:首頁 » 編程軟體 » c防止反編譯

c防止反編譯

發布時間: 2022-01-08 11:36:38

A. c語言編譯求教

你好,網上有不少mips反編譯的軟體,不過都是只能反編譯獲得對應的匯編代碼。沒有可以輸出c語言的。

B. 如何防止程序員反編譯

java從誕生以來,其基因就是開放精神,也正因此,其可以得到廣泛愛好者的支持和奉獻,最終很快發展壯大,以至於有今天之風光!但隨著java的應用領域越來越廣,特別是一些功能要發布到終端用戶手中(如Android開發的app),有時候,公司為了商業技術的保密考慮,不希望這裡面的一些核心代碼能夠被人破解(破解之後,甚至可以被簡單改改就發布出去,說嚴重點,就可能會擾亂公司的正常軟體的市場行為),這時候就要求這些java代碼不能夠被反編譯。

這里要先說一下反編譯的現象。因為java一直秉持著開放共享的理念,所以大家也都知道,我們一般共享一個自己寫的jar包時,同時會共享一個對應的source包。但這些依然與反編譯沒有什麼關系,但java的共享理念,不只是建議我們這樣做,而且它自己也在底層上「強迫」我們這么做!在java寫的.java文件後,使用javac編譯成class文件,在編譯的過程,不像C/C++或C#那樣編譯時進行加密或混淆,它是直接對其進行符號化、標記化的編譯處理,於是,也產生了一個逆向工程的問題:可以根據class文件反向解析成原來的java文件!這就是反編譯的由來。

但很多時候,有些公司出於如上述的原因考慮時,真的不希望自己寫的代碼被別人反編譯,尤其是那些收費的app或桌面軟體(甚至還有一些j2ee的wen項目)!這時候,防止反編譯就成了必然!但前面也說過了,因為開放理念的原因,class是可以被反編譯的,那現在有這樣的需求之後,有哪些方式可以做到防止反編譯呢?經過研究java源代碼並進行了一些技術實現(結果發現,以前都有人想到過,所以在對應章節的時候,我會貼出一些寫得比較細的文章,而我就簡單闡述一下,也算偷個懶吧),我總共整理出以下這幾種方式:

代碼混淆

這種方式的做法正如其名,是把代碼打亂,並摻入一些隨機或特殊的字元,讓代碼的可讀性大大降低,「曲線救國」似的達到所謂的加密。其實,其本質就是打亂代碼的順序、將各類符號(如類名、方法名、屬性名)進行隨機或亂命名,使其無意義,讓人讀代碼時很累,進而讓人乍一看,以為這些代碼是加過密的!

由其實現方式上可知,其實現原理只是擾亂正常的代碼可讀性,並不是真正的加密,如果一個人的耐心很好,依然可以理出整個程序在做什麼,更何況,一個應用中,其核心代碼才是人們想去了解的,所以大大縮小了代碼閱讀的范圍!

當然,這種方式的存在,而且還比較流行,其原因在於,基本能防範一些技術人員進行反編譯(比如說我,讓我破解一個混淆的代碼,我寧願自己重寫一個了)!而且其實現較為簡單,對項目的代碼又無開發上的侵入性。目前業界也有較多這類工具,有商用的,也有免費的,目前比較流行的免費的是:proguard(我現象臨時用的就是這個)。

上面說了,這種方式其實並不是真正加密代碼,其實代碼還是能夠被人反編譯(有人可能說,使用proguard中的optimize選項,可以從位元組流層面更改代碼,甚至可以讓JD這些反編譯軟體可以無法得到內容。說得有點道理,但有兩個問題:1、使用optimize對JDK及環境要求較高,容易造成混淆後的代碼無法正常運行;2、這種方式其實還是混淆,JD反編譯有點問題,可以有更強悍的工具,矛盾哲學在哪兒都是存在的^_^)。那如何能做到我的class代碼無法被人反編譯呢?那就需要我們下面的「加密class」!

加密class

在說加密class之前,我們要先了解一些java的基本概念,如:ClassLoader。做java的人已經或者以後會知道,java程序的運行,是類中的邏輯在JVM中運行,而類又是怎麼載入到JVM中的呢(JVM內幕之類的,不在本文中闡述,所以點到為止)?答案是:ClassLoader。JVM在啟動時是如何初始化整個環境的,有哪些ClassLoader及作用是什麼,大家可以自己問度娘,也不在本文中討論。

讓我們從最常見的代碼開始,揭開一下ClassLoader的一點點面紗!看下面的代碼:

Java代碼

  • publicclassDemo{

  • publicstaticvoidmain(String[]args){

  • System.out.println(「helloworld!」);

  • }

  • }

  • 上面這段代碼,大家都認識。但我要問的是:如果我們使用javac對其進行編譯,然後使用java使其運行(為什麼不在Eclipse中使用Runas功能呢?因為Eclipse幫我們封閉,從而簡化了太多東西,使我們忽略了太多的底層細節,只有從原始的操作上,我們才能看到本質),那麼,它是怎麼載入到JVM中的?答案是:通過AppClassLoader載入的(相關知識點可以參考:http://hxraid.iteye.com/blog/747625)!如果不相信的話,可以輸出一下System.out.println(Thread.currentThrea().getContextLoader());看看。

    那又有一個新的問題產生了:ClassLoader又是怎樣載入class的呢?其實,AppClassLoader繼承自java.lang.ClassLoader類,所以,基本操作都在這個類裡面,讓我們直接看下面這段核心代碼吧:



    看到這里,已經沒有必要再往下面看了(再往下就是native方法了,這是一個重大伏筆哦),我們要做的手腳就在這里!

    手腳怎麼做呢?很簡單,上面的代碼邏輯告訴我們,ClassLoader只是拿到class文件中的內容byte[],然後交給JVM初始化!於是我們的邏輯就簡單了:只要在交給JVM時是正確的class文件就行了,在這之前是什麼樣子無所謂!所以,我們的加密的整個邏輯就是:

  • 在編譯代碼時(如使用ant或maven),使用插件將代碼進行加密(加密方式自己選),將class文件裡面的內容讀取成byte[],然後進行加密後再寫回到class文件(這時候class文件裡面的內容不是標準的class,無法被反編譯了)

  • 在啟動項目代碼時,指定使用我們自定義的ClassLoader就行了,而自定義的部分,主要就是在這里做解密工作!

  • 如此,搞定!以上的做法比較完整的闡述,可以仔細閱讀一下這篇文章:https://www.ddtsoft.com/#developerworks/cn/java/l-secureclass/文章中的介紹。

    通過這個方法貌似可以解決代碼反編譯的問題了!錯!這里有一個巨大的坑!因為我們自定義的ClassLoader是不能加密的,要不然JVM不認識,就全歇菜了!如果我來反編譯,呵呵,我只要反編譯一下這個自定義的ClassLoader,然後把裡面解密後的內容寫到指定的文件中保存下來,再把這個加了邏輯的自定義ClassLoader放回去運行,你猜結果會怎樣?沒錯,你會想死!因為你好不容易想出來的加密演算法,結果人家根本不需要破解,直接就繞過去了!

    現在,讓我們總結一下這個方法的優缺點:實現方式簡單有效,同時對代碼幾乎沒有侵入性,不影響正常開發與發布。缺點也很明顯,就是很容易被人破解!

    當然啦,關於缺點問題,你也可以這么干:先對所有代碼進行混淆、再進行加密,保證:1、不容易找到我們自定義的那個ClassLoader;2、就算找到了,破解了,代碼可讀性還是很差,讓你看得吐血!(有一篇文章,我覺得寫得不錯,大家可以看一看:http://www.scjgcj.com/#blog/851544)

    嗯,我覺得這個方法很好,我自己也差點被這個想法感動了,但是,作為一個嚴謹的程序員,我真的不願意留下一個隱患在這里!所以,我繼續思索!

    高級加密class

    前面我們說過有個伏筆來著,還記得吧?沒錯,就是那個native!native定義的方法是什麼方法?就是我們傳說中的JNI調用!前面介紹過的有一篇文章中提到過,其實jvm的真實身份並不是java,而是c++寫的jvm.dll(windows版本下),java與dll文件的調用就是通過JNI實現的!於是,我們就可以這樣想:JNI可以調用第三方語言的類庫,那麼,我們可不可以把解密與裝載使用第三方語言寫(如C++,因為它們生成的庫是不好反編譯的),這樣它可以把解密出來的class內容直接調jvm.dll的載入介面進行初始化成class,再返回給我們的ClassLoader?這樣,我們自定義的ClassLoader只要使用JNI調用這個第三方語言寫的組件,整個解密過程,都在黑盒中進行,別人就無從破解了!

    嗯,這個方法真的很不錯的!但也有兩個小問題:1.使用第三方語言寫,得會第三方語言,我說的會,是指很溜!2.對於不同的操作系統,甚至同一操作系統不同的版本,都可能要有差異化的代碼生成對應環境下的組件(如window下是exe,linux是so等)!如果你不在乎這兩個問題,我覺得,這個方式真的挺不錯的。但對於我來說,我的信條是,越復雜的方式越容易出錯!我個人比較崇尚簡潔的美,所以,這個方法我不會輕易使用!

    對了,如果大家覺得這個方法還算可行的話,可以推薦一個我無意中看到的東西給大家看看(我都沒有用過的):jinstall,

    更改JVM

    看到這個標題,我想你可能會震驚。是的,你沒看錯,做為一個程序員,是應該要具有懷疑一切、敢想敢做的信念。如果你有意留心的話,你會發現JVM版本在業界其實也有好幾個版本的,如:Sun公司的、IBM的、Apache的、Google的……

    所以,不要阻礙自己的想像力,現在沒有這個能力,並不代表不可能。所以,我想到,如果我把jvm改了,在裡面對載入的類進行解密,那不就可以了嗎?我在設計構思過程中,突然發現:人老了就是容易糊塗!前面使用第三方語言實現解密的兩個問題,正好也是更改JVM要面對的兩個問題,而且還有一個更大的問題:這個JVM就得跟著這個項目到處走啊!

C. C#如何防止被別人反編譯

C# 編寫的代碼通過VS編譯器生成 dll 或 exe ,很容易被一些反編譯工具查看到源碼或對源碼進行修改。
為防止代碼被反編譯或被篡改,我們可以進行一定的防範措施。但不能杜絕,因為DotNet編寫代碼運行必須編譯成IL 中間語言,IL是很規則,同時也很好反編譯。

反編譯防範措施:

  • 設置項目代碼反匯編屬性

  • 混淆

  • 方法一:防止 Ildasm.exe(MSIL 反匯編程序) 反匯編程序集

    方法很簡單在項目文件AssemblyInfo.cs中增加SuppressIldasm屬性。

    效果很明顯,很難看出反編譯代碼所寫的真正邏輯。

    缺點:
    C#代碼通過混淆工具生成後,增加了很多轉換過程。這使得反編譯工具無法很直觀看到源碼真正邏輯。但源碼代碼過多轉換會使軟體本身運行效率降低,甚至會出現報錯情況。

D. 如何防止代碼被反編譯

由於apk是Android虛擬機載入的,它有一定的規范,加密apk後Dalvik無法識別apk了。完全避免是不可能的,總有人能夠破解你的代碼。但是有幾種方式來提高被反編譯取代碼的難度。
1 關鍵代碼使用jni調用本地代碼,用c或者c++編寫,因此相對比較難於反編譯

2 混淆java代碼。混淆是不改變代碼邏輯的情況下,增加無用代碼,或者重命名,使反編譯後的源代碼難於看懂。 網上開源的java代碼混淆工具較多,一般是用ant的方式來編譯的。

1 . 在工程文件project.properties中加入下proguard.config=proguard.cfg , 如下所示:
target=android-8
proguard.config=proguard.cfg
Eclipse會通過此配置在工程目錄生成proguard.cfg文件

2 . 生成keystore (如已有可直接利用)
按照下面的命令行 在D:\Program Files\Java\jdk1.6.0_07\bin>目錄下,輸入keytool -genkey -alias android.keystore -keyalg RSA -validity 100000 -keystore android.keystore
參數意義:-validity主要是證書的有效期,寫100000天;空格,退格鍵 都算密碼。
命令執行後會在D:\Program Files\Java\jdk1.6.0_07\bin>目錄下生成 android.keystore文件。

3. 在Eclipce的操作
File -> Export -> Export Android Application -> Select project -> Using the existing keystore , and input password -> select the destination APK file

經過混淆後的源代碼,原先的類名和方法名會被類似a,b,c。。。的字元所替換,混淆的原理其實也就是類名和方法名的映射。
但4大組件並沒有混淆(所有在清單文件定義的組件不能被混淆),因為系統需要通過清單文件來查找和運行應用程序。

proguard.cfg 文件代碼解讀
-optimizationpasses 5 ->設置混淆的壓縮比率 0 ~ 7
-dontusemixedcaseclassnames -> Aa aA
- ->如果應用程序引入的有jar包,並且想混淆jar包裡面的class
-dontpreverify
-verbose ->混淆後生產映射文件 map 類名->轉化後類名的映射

-optimizations !code/simplification/arithmetic,!field/*,!class/merging/* ->混淆採用的演算法.

-keep public class * extends android.app.Activity ->所有activity的子類不要去混淆
-keep public class * extends android.app.Application
-keep public class * extends android.app.Service
-keep public class * extends android.content.BroadcastReceiver
-keep public class * extends android.content.ContentProvider
-keep public class * extends android.app.backup.BackupAgentHelper
-keep public class * extends android.preference.Preference
-keep public class com.android.vending.licensing.ILicensingService

-keepclasseswithmembernames class * {
native <methods>; -> 所有native的方法不能去混淆.
}

-keepclasseswithmembers class * {
public <init>(android.content.Context, android.util.AttributeSet);
-->某些構造方法不能去混淆
}

-keepclasseswithmembers class * {
public <init>(android.content.Context, android.util.AttributeSet, int);
}

-keepclassmembers class * extends android.app.Activity {
public void *(android.view.View);
}

-keepclassmembers enum * { -> 枚舉類不能去混淆.
public static **[] values();
public static ** valueOf(java.lang.String);
}

-keep class * implements android.os.Parcelable { -> aidl文件不能去混淆.
public static final android.os.Parcelable$Creator *;
}

E. 怎樣防止編譯後的C語言文件被反編譯

app反編譯後防止介面泄露的方法,就是使用谷歌提供的混淆工具,將不要反編譯的文件保留,其他的都進行混淆,這樣之後反編譯看到的都是一些亂碼,例如abc之類的。

F. 我寫的C/S程序怎麼輕易就被人反編譯了:(

這很正常了,沒有混淆什麼的

~~~~~~~~

G. 哪位大哥研究過UNIX下C的反編譯,敬請指點

C/C++和C#、JAVA不一樣。像C#、JAVA這種解釋型語言是運行在虛擬機上的,建立在虛擬機規范之上,反編譯過程較容易實現。
而C/C++更接近底層系統實現和依賴於編譯器,不同編譯器生成的二進制代碼會相對不同平台有所區別,甚至同一操作系統不同系列的編譯器都會有一點差異,比如在linux下編譯C/C++得到的二進制代碼就很難或無法運行在windows平台上,反之亦然
所以反編譯很困難,現在大多數反編譯軟體都只能反編譯成匯編。有一些號稱可以反編譯成C或者C++的工具,但反編譯出來的結果大多看不明白,還不如用匯編。

H. 如何阻止APK反編譯查看源代碼

apk如何防止反編,就用反編譯工具來舉例,例如dex2jar和JD-GUI。dex2jar是將APK中的classes.dex轉化成Jar文件,而JD-GUI是一個反編譯工具,可以直接查看Jar包的源代碼。

具體步驟:首先將APK文件後綴改為zip,解壓,得到其中的classes.dex,它就是java文件編譯再通過dx工具打包而成的;解壓下載的
dex2jar,將classes.dex復制到dex2jar.bat所在目錄。在命令行下定位到dex2jar.bat所在目錄(在DOS命令下CD
目錄)。運行dex2jar.bat classes.dex生成classes.dex.dex2jar.jar
運行JD-GUI(jd-gui.exe),打開上面生成的jar包,即可看到源代碼了。
apk如何防止反編,現在大多開發者已經意識到了App加密保護的重要性,愛加密正是順應行業的發展,對APK進行加密保護,防止反編譯,保護開發者的創意不再被剽竊的第三方加密服務平台。
加密原理:通過對源碼進行加殼保護,然後生成類似虛像的DEX殼文件,即使反編譯也無法看到APK包的源碼,達到防止反編譯的目的。

另外,愛加密的三層加密保護技術:DEX加殼保護,DEX指令動態載入保護,高級混淆保護,可以保證App的動態安全和靜態安全,年前推出的SO庫保
護,使C/C++層面的代碼得到了專業保護,讓APK包無懈可擊。並且,不斷加強對App的保護力度,強力遏制打包黨的橫行,凈化Android應用市
場,打造一個綠色的移動互聯網生態鏈。

I. 為何C和C++編寫生成的可執行程序不可反編譯回源程序

因為不同的源程序經過編譯可能得到相同的可執行程序,因此如果反向操作就存在二義性了

J. c語言怎麼防止別人抄襲

這個問題嘛。不太好解決。
以下方法僅供參考:
1、做注釋,在注釋中寫明author,一般來說都放在函數前。每個c文件也應該在開頭部分這樣做
2、在變數名稱中嵌入自己的名字簡寫或者直接就是名字
3、C測試數據中使用的數據用與自己相關的數據。
4、在C語言中設置類似水印的東西,例如,在某些程序的某些地方,悄悄的輸出自己的名字(當然,你不能讓別人知道你都什麼地方輸出了這些信息)。

暫時就想到這么多,如果,一個人能把上面的所有東西都改掉,那麼,我感覺他還不如自己做一個呢。。。
就是,你確定一個宗旨,讓他們改起來比做起來更加浪費時間和精力就ok了!

熱點內容
教室系統管理員如何幫助更改密碼 發布:2024-12-24 09:44:19 瀏覽:597
ip廣播伺服器安裝 發布:2024-12-24 09:33:56 瀏覽:942
路由器如何配置ss 發布:2024-12-24 09:06:14 瀏覽:425
安卓lol怎麼登錄 發布:2024-12-24 08:54:11 瀏覽:701
安卓車機怎麼更改軟體解析度 發布:2024-12-24 08:38:12 瀏覽:291
以圖形化界面的方式執行存儲過程 發布:2024-12-24 08:37:26 瀏覽:912
在哪裡找得到退出存儲卡 發布:2024-12-24 08:25:23 瀏覽:483
安卓上哪裡下大型游戲 發布:2024-12-23 15:10:58 瀏覽:189
明日之後目前適用於什麼配置 發布:2024-12-23 14:56:09 瀏覽:56
php全形半形 發布:2024-12-23 14:55:17 瀏覽:829