特殊字元反編譯

❶ C#反編譯後，隨機字元串一樣的函數，是個什麼情況

中間代碼被混淆了
混淆就是對編譯生成的MSIL中間代碼進行模糊處理，最簡單的混淆是名稱混淆，即將 命名空間名、類名、方法名、欄位名等統統換成特殊符號或其它符號，目的就是讓人看到暈為止，但是並不改變程序執行邏輯。

❷ 如何讓C++寫的dll不被反編譯

簡單回答：
1、理論上不能保證程序不被反編譯。
2、一些加殼軟體可以做到加大被反編譯的難度，迫使操作者先解殼才能做反編譯，但同時會降低程序的運行效率。
3、當前的技術條件下，一般而言，反編譯出的「源代碼」一般而言並不能作學習，參考的源代碼，多數情況下只能用於分析區部片斷分析，主要用於破解或小范圍類修改。
4、一些簡單的加殼軟體：ASPACK、UPX、PECompact等，如果想嘗試，自個去搜索下載後試試。加殼後的軟體還有可能被某些殺軟當成惡意軟體。
5、這也正是很多對安全要求高的系統使用「三層架構」（類似訪問網頁/網站）的原因。因為在三層架構中，核心軟體、數據不被用戶直接接觸。

************以下是相關知識，有耐心可看看************
一、關於反編譯與破解。
1、以當前的技術來說，理論上，所有的程序都存在被反編譯的可能。
2、但是反編譯出來的代碼並不一定能被技術不高的人看懂，因為反編譯出來的「源代碼」與編寫者寫出的原代碼在80%以上是不同的。這是因為反編譯的原理是根據機器碼（或中間碼），讓機算機進行反向生成高級語言，而不是找出編寫者原有的代碼，找出原有的代碼是不可能的。反編譯出來的代碼在可理解性、可閱讀性上，一般而言是非常差的。
3、但是，這並不代碼反編譯出來的「源代碼」沒有價值，對於內行來說，分析反編譯出來的代碼中的某些特定片段，就可以對程序進行破解，找出程序的關鍵點、口令、數據來源等等。因為破壞總是比建設要容易，分析局部比規劃全局要容易得多。
4、如果考慮到被反編譯將關鍵代碼進行特殊處理的話，可能加大相關的難度，比如將特定的字元串分成多個字串在程序中存儲，或是進行加密後存儲，在使用時合成/生成，不用時即時在內存中清除等等……。
5、反編譯後對關鍵部分的定位往往是根據字元串來進行的，比如在用戶沒有注冊時，跳出一行對話，告訴用戶「請注冊後再使用」，破解者就會在反編譯後追查這個字串所在，然後查到這個字串對應的變數與地址，再追查調用這個變數或地址的代碼，然後再延伸查到什麼情況下調用「調用這個變數或地址的代碼」，最後，設定跳過語句。這就是最典型的破解注冊的方法。破解完再將修改了的「源代碼」進行編譯，或是根據「源代碼」直接修正程序中對應的代碼，OK，破解版正式完成。
二、關於加殼。
1、理論上，同樣，沒有破解不了的殼。
2、但是有些加殼軟體使用了一些特別的方法，使得破解殼的難度變得非常難，技術不夠的朋友很難下手，比如將原程序代碼拆分、變型、植入自校驗等等技術。
3、但加殼軟體同樣是程序，它自身就存在被反編的可能，加了殼可以類比成，在一個木箱外面再加個保險櫃。但千萬別以為保險櫃就一定是保險的，面對各種技術開鎖、暴力開箱，再強的保險櫃也只能是加大難度而已。
4、越復雜的加殼，就會使得程序運行時效率降得越低，這是必然的，因為原本只關注目標任務的程序現在還要時時提防著被提取、被監測。

❸ .net（vs環境）接受到一些帶有」/"等的字元後會自動添加一些/來區分一些特殊意義的字元如/n等，怎麼還原

你如果想輸出原始的字元串可以加@或是轉義符\
比如
Console.WriteLine("我要輸出帶\\n的字元串");
Console.WriteLine(@"我要輸出帶\n的字元串");
輸出的結果都是:我要輸出帶\n的字元串

處理過了? 你沒有源代碼了嗎?這可不是好習慣啊, 可以反編譯回來.

❹ 當年的Fc《魂斗羅》《瑪麗》是用什麼工具做的。如何反編譯。

匯編和c都可以，這里有個編程器http://pocket.92wy.com/fc_info_33534.html

任夭堂游戲編程探密(文字版)
第一章 任天堂游戲結構概論
長期以來，由於任天堂公司在技術上的封鎖和國內游戲開發工具的久缺.任天堂游戲
蒙上了一層神密的面紗，中國人只能玩任天堂游戲.而不能象蘋果機、中華學習機那樣了解
游戲程序、自己動手編寫游戲。近年來，隨著任夭堂系列游戲機配套鍵盤的問世，逐步創造了
揭開這層面紗的條件.特別是配有列印機介面的「裕興」、「金字塔」等高檔游戲機鍵盤的陸續
推出，用戶僅僅編寫一個簡單的反匯編程序就可列印出系統軟體的源程序，從而為探索任天
堂游戲軟體的奧秘提供了有效的手段。
有人疑問任夭堂游戲機的中央處理器同中華學習機一樣也是八位的CPU.但為什麼
它能夠產生出如此絢麗多彩的動畫、美妙動聽的音響、栩栩如生的角色，其效果遠遠勝過美
國的「雅達利「，更強過中華學習機的游戲呢?究其原因，關鍵在於任天堂游戲機的設計者們
在傳統的八位機上獨具匠心、另闢蹊徑，從硬體上進行了獨創的改造，在軟體上進行了大膽
的嘗試，使一個CPU發揮了兩個CPU的功效，產生了絕妙非凡的藝術效果.從而以物美價
廉的絕對優勢迅速佔領了游戲機市場，掀起了家庭娛樂領域的第三次浪潮。本文擬從分析任
天堂游戲的軟、硬體特點出發，揭開任天堂游戲編程的秘密.以一與廣大同好切磋。

1·1 任天堂游戲機的硬體特點

1·1·1電路原理框圖
任天堂游戲機的硬體共分兩部分:主要部分是游戲機.從屬部分是游戲卡。游戲機提供
游戲的運行環境，游戲卡提供支持游戲的軟體，其電路原理框圖如圖1一1。
上圖中6527 CPU為中央處理器，田於它的任務是處理程序，所以一般把與它相連的部
件加以前綴"P".故CPU的地址匯流排表示為PADD,數據匯流排表示為PDATA,CPU管理的
存儲器表示為PRAM,PROM等。同樣.6528 PPU的任務是處理圖像，所以凡與它相關的部
件均加以前綴「V」。

1·1·2 中央處理器6527 CPU
1.CPU的內部結構
6527 CPU是一個八位單片機，在它的內部除固化有6502系列的CPU外，還有一個
可編程音響發生器PSG(Programable Sound Generator)和24個八位只寫寄存器，其地址空
間分配為$4000-$4017.主要用於CPU的I/O操作,PSG音響發生器的工作就是由這些
寄存器控制完成的.

1·1·4 游戲卡
1、游戲卡的基本組成
普通的單節目游戲卡一般由兩片ROM或EPROM組成，ROM的容量由游戲程序量的
大小決定.最簡單的任天堂游戲為24K,故這種卡內有塊16K的ROM存放程序，一塊
8K的ROM存圖形字模(目前有軟封裝的IC,它把兩塊ROM封在一起)。典型的任天堂
游戲程序量為40K，它使用一塊32K的ROM存程序、一塊8K的ROM存字模。當程序量大
於40K時則要對ROM進行容量擴充.
2、游戲卡各腳的功能
游戲卡是一60腳的接插件，各腳功能見圖1一4。
3、常用 ROM引腳功能簡介
游戲卡中常用ROM或EPROM的型號有27C64(8 X 8K)、27C128(8X l6K)、27C256(8
X 32K), 27C512 (8 X 64 K ), 27C1000 (8 X 128K),或後綴數字相同而前綴不同的其它公
司產品，盒卡中還有2兆位(8 x 256K)至8兆位(8X 1000K)的晶元。其中27C64~27C512為28
腳的晶元,27C1000或更大容量的晶元為32腳(個別的27C1000仍為28腳，它使用了OE.
CE中的一個腳作為地址線).

1·2 任夭堂游戲軟體的特點
目前流行的任夭堂游戲軟體有數百種，內容已涉及及到政治、經濟、軍事、戰爭、教育、管
理、體育、娛樂等各個領域.可以說任天堂游戲已兼顧了男、女、老、中、青、少、幼各個年齡階
層，深受世界各國人民所喜愛。也許這就是它迅速普及的主要原因。但是，任天堂游戲盡管
內容千變萬化、情節各異，其軟體結構和處理方法則是基本相同的，它們有著共同的特點。

1·2·1 任天堂游戲的軟體結構
歸納起來，任天堂游戲軟體結構可分為兩大類:基本結構和擴展結構.
一、基本結構
基本的任夭堂游戲軟體容分為40K位元組(標准卡標注為LB)。典型游戲如，《1942》、《超
級瑪麗》、《拆屋工》等.其中32k為游戲控製程序，供CPU執行;8K為圖形字模，由PPU處
理。另外還有一種低配置結構，軟體容量為24K{標注為LA)，這是一種早期軟體。其中控制
程序為16K;字模為8K。典型游戲有《火箭車》、《馬戲團》、《金塊Ⅰ、Ⅱ》等。
40K軟體的控製程序存放地址在CPU管理的$8000一$FFFF空間;字模地址在PPU
管理的$0000-$1FFF空間。16K軟體的控製程序存放地址為$C000-$FFFF;字模地
址也是$0000一$1FFF。
二、擴展結構
容量在40K以上的軟體均為擴展結構。它們在基本結構的基礎上或者擴展控製程序
區、或者擴展字模區。擴展方法是在某段地址范圍進行空間存儲體切換。一般程序區在
$8000-$BFFF空間切換;字模區在$0000-$1FFF空間切換。切換種類以軟體容量的
大小略有不同:
對於48K卡(標注為LC〕，其程序部分為32K;宇模部分為16K，分兩個8K存儲體.
典型游戲有《七寶奇謀》、《影子傳說》等。
通常把24k-48K容量的游戲卡稱為低檔卡或低檔游戲。
對於64K卡(標注為LD)有兩種結構:一種是其程序部分為32K;字模部分為32x，分
為四個8K存儲體.典型游戲有《迷宮組曲》，《智慧城》、《沙羅曼蛇一代》、《北斗神拳一代》
等;第二種則是程序與字模共用64k，分為四個存儲體.典型游戲有《米老鼠大冒險》、《冒險
島》、《俄羅斯方塊1、2》等。
80K的游戲不多(標注為LE)，常見的有《中國拳》、《金牌瑪麗》等。其程序部分為48K,
前32K分為兩個16k存儲體;字模部分為32k,分為四個8k存儲體。
通常稱64k、80K的游戲為中檔卡。
對於128K卡(標注為LF)，其程序部分與字模部分棍合共用128k,分為八個16K存儲
體，其中前七個存儲體地址映射於$8000-$BFFF:最後一個存儲體(稱為HOME BANK)
映射於$0000一$FFFF，典型游戲有《魔界村》、《怒》、《火之鳥方》、《未來戰士》、《洛克人》、
《1943》 《1944 》《嵌特殊部隊》、《沖撞霹靂機車》等。
這類游戲卡中一般都配有一塊8K的RAM(動態隨機存儲器〕存儲當前使用的字模。
對於160k卡(標注為LG)，其程序部分為128K;字模部分為32K。典型游戲有《倚天屠
龍記》、《立體大賽車》、《歡樂叮當》等。
對於256K卡(標注為LH)，其程序部分為128K;字模部分為128K。典型游戲有《柯拉
米世界》、《惡魔城》、《雙截龍》、《松鼠歷險記》《人間兵器》、《聯合大作戰)等。另外，還有《魂
斗羅》、《赤色要塞》、《綠色兵團》、《立體籃球》《荒野大鏢客》等256K游戲被壓縮為128K游
戲，目前這類游戲的256K版已不多見，常見的均為128K的壓縮版;
通常稱128K一256K容量的游戲為高檔卡或強卡。
對於高於256K容是的游戲則稱為特卡，如《不動明王傳》,《戰斧》、《孔雀王》，《大旋風》
等游戲容量已達2M-4M。但由於任天堂系列游戲機的CPU的處理速度、畫面的解析度、音
域音色等方面的限制，即使軟體容量再增大，游戲效果也不會提高多少.總達不到街機的水
平，故目前單個游戲的容量大於256K的尚不多見。

1·3 任天堂游戲的圖像處理方法
本節簡要介紹任天堂游戲的圖像處理方法。
1·3·1屏幕顯示原理
任天堂游戲機中的CPU雖然仍屬65系列的CPU，但它的顯示方式與中華學習機截然
不同。其顯示屏幕由三類四層顯示頁面鉤成。三類顯示頁依次為:卡通(角色或動畫)頁、背
景頁、底背景頁。卡通頁用於顯示游戲中的角色，它有兩個頁面:卡通零頁——使角色顯示於
背景之前;卡通一頁——使角色顯示於背景之後。卡通員的顯示解析度為256x240點，卡通
可以點為單位移動。背景頁主要用於游戲畫面的顯示，它共有四個顯示頁面，每頁的兩邊互
相相連並排成「田」字，採取字元顯示方式，顯示解析度為32列* 30行，每幅畫面由$60個
圖形塊構成，游戲中可任取一個頁面顯示。底背景頁主要用於大面積的單色顯示，以襯托出
蘭天、草地、沙漠、大海等效果，顯示解析度為1x1。 四層顯示頁的排列由前向後依次為:卡
通零頁、背景頁、卡通一頁、底背景頁(見圖1一6)。系統默認的排列方式為背景00頁與卡通
賈、底背景頁四層頁面重疊，前面顯示頁的內容可以遮住後面顯示頁的內容，因而很容易構
成具有一定景深次序的立體畫面。

1·3·2背景處理技術
任天堂游戲中的背景畫面顯示採用字元方式，每個字元通常稱為背景圖形塊。每個圖
形塊為8*8點陣，其字模數據存放在由PPU管理的一段內存中，稱為背景字型檔，一般使用
$1000一$1FFF地址，共4K位元組.每個字模由連續的16個單元組成，故一次最多可定義
256個字元，序號依次為0～255.顯示字元時，只要把字元序號置入屏幕對應的顯示單元中
即可。
任關堂游戲中的背景處理由PPU獨立完成，每一個背景頁面對應PPU的1024個單
元，為順序對應關系。背景00頁對應PPU地址為$2000--$23FF，其中$2000一$23BF
對應於960個圖形顯示單元，$23C0--23FF為該顯示頁的配色單元;背景10頁對應的
PPU地址為$2400一$27FF;同樣，後面的兩頁依次對應$2800---$2BFF、$2C00
$2FFF。由於游戲機中只有一塊2K的VRAM(PPU使用的RAM)，故一般只使用前兩個
頁面，通常稱其為背景零頁和背景一頁。游戲中可通過設置軟開關的方法控制畫面的橫、縱
向，以使兩幅面面橫向並列或縱向銜接。
在實際游戲中，要經常用到背景畫面的橫向卷動和縱向滾動。如(魂斗羅，游戲中的卻
一、五、六、七、八關是橫向卷動，第三關則是縱向滾動。這些畫面位移效果是如何實現的呢？
我們知道，中華學習機中的畫面位移是通過反復改寫顯示映射單元的內容而實現的，這種方
法處理速度慢、控製程序冗長。任天堂則採取了截然不同的方法。它通過硬體的待殊處理，
引入了顯示窗口的概念。畫面位移時，每個顯示單元的內容不變，而令顯示窗口向相反的方
向移動，從而實現了畫面的橫向卷動和縱向滾動。如《魂斗羅》中第一關橫向卷動的控制方法
是.令兩個背景頁橫向銜接，游戲開始時，背景零頁繪滿32列，而背景一頁僅繪制12列，令
顯示窗口對正零頁，當游戲中的角色前進到畫面右邊的一定位置時，則令顯示窗口右移一
格，同時繪制一頁的第13列;這樣，顯示窗口每右移一格，畫面繪制一列，從而使游戲畫面連
綿不絕，每移出一頁畫面(32列)令頁數計數器加一，當累計到一定頁數時則令窗口不再移
動，進行關底處理。這一畫面的位移控制極為簡單，僅通過向位移軟開關$2005置入移位數
據就可實現。F BASIC的控製程序為:
POKE &H2005，x:POKE &H2005，0
x為位移參數。其機器語言的控製程序為:
LDA x
STA $ 2005
LDA #$00
STA $ 2005
畫面的縱向位移則更為簡單，如《魂斗羅》的第三關——瀑布天險是一個縱版畫面，角色要從
最底層跳升到最頂層與關底魔頭決斗，游戲進程中畫面隨看角色的跳躍不停的上滾。實際--
這一位移過程是在一頁面面中進行的，控制方法是，每當角色前進到畫面上方某一位置時，
改寫畫面最底行的圖形數據，使其為即將移入畫面的一行.然後令顯示窗口向上移一格，由
於窗口是在一個顯示頁上移動，故最底行即是最頂行(這時可把一頁面面理解為上、下邊連
接的圓筒，顯示窗口是套在畫面圓筒外面稍大的一個圓筒，窗口移動一格就是向上旋轉一
格)。F BASIC控製程序為，
POKE &H2005，0:POKE &H2005，Y
Y為位移參數。相應的機器語言程序為，
LDA #$00
STA $2005
LDA Y
STA $2005
以上畫面的送效、位移操作都是在CPU響應非屏蔽中斷期間完成的(非屏蔽中斷是在
電視機的場回掃期間發出和響應的，這時的電視屏是黑的),所以我們感覺佈道位移的痕跡。
關於任天堂游戲中背景畫面的繪制 移動及畫面的分裂位移和扭曲等效果的實現，將在第六章詳細討論。

1·3·3動畫處理技術
組成任天堂游戲中動畫的最小單位是卡通塊，每個卡通塊為8X8點陣.與一個字元同
樣大小。卡通塊也有一個圖形字型檔，對應的PPU地址為$0000-$OFFF。每個個卡通塊的字
模數據也由連續的16個單元組成，故一次最多可定義256個卡通塊，序號依次為0-255
6527CPU規定.在一幅畫面上只允許同時顯示64個8x8點陣的卡通塊〔這是由PPU
內卡通定義區的RAM分配決定的〕，如《超級瑪麗》中，瑪麗在吃紅蘑菇之前為16x16點
陣大小(即由4個卡通塊組成)，當吃了紅蘑菇之後身體長大一倍，變為32X 32點陣(即由
16個卡通塊組成〕的卡通。但實際游戲中要求顯示的卡通塊數往往遠遠超過這一限制，如目
前較流行的打鬥游戲《街霸》中，一個卡通即為128*64點陣（由128個卡通塊組成)有時還
更大，這是怎麼實現的呢?
原來在實際游戲中，對卡通進行了分時控制。所謂分時控制就是在不同的時間里顯示半
通的不同部分，依靠人眼的視覺惰性產生連續的感覺。如《魂斗羅》游戲中的卡通顯示（兩個
正面角色、敵人、發射的子彈、暗堡的閉合與開啟都是卡通)就是每一次中斷顯示卡通的二分
之一實現的。
卡通的定義操作極其簡單，系統規定一個卡通塊由連續的四個內存單元定義，第一寸
單元指定卡通顯示的Y坐標、第二個為卡通塊在字型檔中的序號、第三個為卡通塊的顯示狀
態〔配色組合、左右翻轉、上下顛倒以及顯示於那個卡通頁面，，第四個為顯示的X坐標。編
程中可任意指定定義卡通的內存頁面(一般選二頁或三頁，即$200一$2FF, $300
$3FF)。
關於任天堂游戲中的卡通的定義及運動控制將在第七章討論。

1·4 任天堂游戲的音響處理

在大部分任天堂游戲的過程始、終，一直伴奏著和諧動聽的背景音樂;隨岩游戲的進行
和角色的動作還不時發出逼真的效果音響，而且這些音響的發出與背景的移動、角色的運動
三者並行工作，互不幹擾，許多朋友玩過中華機上的游戲，如《警察抓小偷》《富士山決戰》
等，這些游戲中的音響發出與角色的動作是不能同時進行的，即角色動作時沒有音響;發出
音響時角色的動作要停下來.任天堂游戲中的音響處理確有獨到之處.由於在6527 CPU內
固化有可編程音響發生器，所以音響控製程序特別簡潔，任天堂游戲的發聲系統由五個聲部
組成，對應於CPU管理的$40DO——$4013二十個單元，每個聲部使用四個單元，它們的作
用依次為音色音量、音形包絡、音調細調、音調粗調。第一、二、三聲部可進行和聲旋律演奏，
也可以選取任一聲部發出效果音，如執行F BASIC程序
POKE &H4015，1:POKE &H4000. 255，255，255，255
就可發出長達三分鍾的頻率由低到高的警報聲。第四聲部可以模仿連續不斷的雜訊，如風
聲 雨聲 鍾生 腳步聲 火車聲等等 第五聲部則可模仿出人的講話聲。任天堂游戲中

背景音樂一般都是使用前三個聲部演奏的，演奏程序也是放在中斷中處理的.五個聲部的發
聲總開關由$4015控制，$4015的D0——D4位依次控制翻第一至第五聲部的工作狀態，置
0關閉、置1開啟。

❺ 如何防止程序員反編譯

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就得跟著這個項目到處走啊！

❻ 更改apk中的文件

帶中文或者特殊字元的文件移動或復制到system文件夾以後，更改許可權，刪除或重命名都統統不管用，刪了還會出現，恢復出廠設置或雙清都沒用。但是，不影響使用，只是看著鬧心罷啦。現在，你要麼刷機，要麼不用管他。至少我沒有找到能解決的其他方法。我的system文件夾里現在就有這么一個惡心的文件。另外，如果你說的那個文件在刪除也不會影響系統的文件夾內，比如鈴聲文件夾等，可以將整個文件夾先備份後以後刪除文件，那麼那個文件也會被刪除啦。要是文件在system文件夾內，就不能刪除整個文件夾，問題還是解決不了。
如何修改apk文件[apk文件修改、圖標、美化、去廣告]完全教程
一、首先搭建jdk環境。
下載完後，點擊安裝。然後設置運行環境參數：
用滑鼠右擊「我的電腦」->屬性->高級->環境變數
系統變數->新建->變數名：JAVA_HOME 變數值：D:\Program Files\Java\jdk1.7.0(這是我的安裝路徑這個不是固定的，比如你安裝到C:\Program Files,就填C:\Program Files\Java\jdk1.7.0)
系統變數->編輯->變數名：Path 在變數值的最前面加上：%JAVA_HOME%\bin;（若已經有Path項，無須另外新建，直接在後面加，但需用;與前面已有的項分隔開）
系統變數->新建->變數名：CLASSPATH 變數值：
.;%JAVA_HOME%\lib;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar;
最後測試下環境變數是否設置成功
點開始菜單-運行-在這里輸入cmd-回車-輸入javac
1.如果出現如下信息：
用法：javac <選項> <源文件>
其中，可能的選項包括：
-g 生成所有調試信息
-g:none 不生成任何調試信息
-g:{lines,vars,source} 只生成某些調試信息
-nowarn 不生成任何警告
-verbose 輸出有關編譯器正在執行的操作的消息
-deprecation 輸出使用已過時的 API 的源位置
-classpath <路徑> 指定查找用戶類文件的位置
-cp <路徑> 指定查找用戶類文件的位置
-sourcepath <路徑> 指定查找輸入源文件的位置
-bootclasspath <路徑> 覆蓋引導類文件的位置
-extdirs <目錄> 覆蓋安裝的擴展目錄的位置
-endorseddirs <目錄> 覆蓋簽名的標准路徑的位置
-d <目錄> 指定存放生成的類文件的位置
-encoding <編碼> 指定源文件使用的字元編碼
-source <版本> 提供與指定版本的源兼容性
-target <版本> 生成特定 VM 版本的類文件
-version 版本信息
-help 輸出標准選項的提要
-X 輸出非標准選項的提要
-J<標志> 直接將 <標志> 傳遞給運行時系統
恭喜，你的Java環境變數配置成功了！
2.如果出現：
'javac' 不是內部或外部命令，也不是可運行的程序
或批處理文件。
說明這Java環境變數配置出錯了，仔細檢查下吧！
二、下載APKTools工具包（裡麵包含：APKTools反編譯工具、APKSign簽名工具）。下載Notepad代碼編輯器（可以修改smali和xml文件）。
在修改之前首先對APK文件內部結構有個了解：
AndroidManifest.xml 程序全局配置文件
classes.dex 這是Dalvik位元組碼
resources.arsc 編譯後的二進制資源文件
META-INF\ 該目錄下存放的是簽名信息
res\ 該目錄存放資源文件
assets\ 該目錄可以存放一些配置文件
對應這些文件和目錄做些基本的注釋和介紹：
AndroidManifest.xml
該文件是每個應用程序都必須定義和包含的文件，它描述了應用程序的名字、版本、許可權、引用的庫文件等等信息。需要解包後才能加以閱讀。
classes.dex文件
classes.dex是java源碼編譯後生成的java位元組碼文件。dex是Dalvik VM executes的全稱，即Android Dalvik執行程序，並非Java ME的位元組碼而是Dalvik位元組碼。
resources.arsc
編譯後的二進制資源文件。
META-INF目錄
META-INF目錄下存放的是簽名信息，用來保證apk包的完整性和系統的安全。在eclipse編譯生成一個apk包時，會對所有要打包的文件做一個校驗計算，並把計算結果放在META-INF目錄下。這就保證了apk包里的文件不能被隨意替換。比如拿到一個apk包後，如果想要替換裡面的一幅圖片，一段代碼， 或一段版權信息，想直接解壓縮、替換再重新打包，基本是不可能的。如此一來就給病毒感染和惡意修改增加了難度，有助於保護系統的安全。
res目錄
res目錄存放資源文件。包括圖片，字元串等等。
解包後，幾乎所有可能的修改和編輯工作基本都在這里。
assets目錄
assets目錄可以存放一些配置文件，這些文件的內容在程序運行過程中可以通過相關的API獲得。
APK文件修改，首先要對APK文件解包（也就是反編譯），打開apktool.exe，如圖：

左邊APK反編譯區，選擇APK文件，選擇文件保存目錄，點反編譯APK按鈕，得到解包文件。
三、開始修改
1. 如果只是對圖像進行替換，沒有必要進行解包和打包。用WinRAR打開APK文件，直接做替換就可以了。但是，如果要對文字和其它非圖像類內容進行修改，那隻能通過解包了，改好後，再編譯回來，最後簽名才能放進手機安裝。下面介紹幾個對APK進行解包和打包的案例。
2. 漢化APK軟體
在res文件夾中，我們可以看到有很多values-***的文件夾，這就是語言包。values是英文語言包，values-zh是中國地區語言包（包含港澳台及內地），values-zh-rCN是中文簡體語言包（只包含內地），values-zh-rTW是中文繁體語言包（港澳台）。除此以外，其它地區的語言包都是精簡的對象，可以不過多了解。
在values文件夾里，通常有arrays.xml、strings.xml等語言文件，要作漢化就要對這些文件進行修改。有時也需要修改其它xml文件，一個一個地認真查看。改好後，打包，簽名，OK。
3. 修改桌面圖標名稱(標簽)
每一個APK文件都有一個「圖標標簽」。將APK程序安裝進手機後，在圖標下面顯示圖標標簽文字。這個圖標標簽的內容是可以修改的。在\res\values下找到strings.xml，修改其中的一行：
圖標標簽
例如：靜音啟動
同理，如果是窗口小插件，要修改widget_name。
注意：system/app下的apk不宜修改，因為要同時修改對應的odex文件。
改好後，打包，簽名，OK。
4. 去掉APK中的廣告
有很多APK應用都帶有廣告。為了去掉程序中的廣告，要修改main.xml文件與廣告有關的內容。在\res目錄下找到文件main.xml。通常在\layout目錄下，有時也被放在其它目錄下。甚至，有時不存在main.xml文件，廣告行被放在其它xml文件內。只能細心逐個文件進行查找。無論哪一種情況，查看其內容，你會看到有一項類似的命令如下。這就是廣告顯示。

將其改為：

可以看到，關鍵是要把fill_parent改為0.0dip，把wrap_content改為0.0dip，其它保持不變即可。這種改法就是不給廣告顯示空間，當然你就看不到廣告了。
改好後，打包，簽名，OK。
5. 修改顯示電池為1%精度
舉個例子比如在摩托羅拉XT502上，默認顯示只有7檔: 0%，10%，20%，40%，60%，80% 和100%。通過修改framework-res.apk，可以改變顯示精度。但是在一些手機上，實踐證明最好可能達到的現實精度只有10%。修改工作如下：
(1) 對framework-res.apk進行解包
(2) 修改和增加電池狀態圖標
(3) 修改文件stat_sys_battery.xml
(4) 修改文件stat_sys_battery_charge.xml
(5) 打包
(6) 提取stat_sys_battery.xml，stat_sys_battery_charge.xml，resources.arsc和一個圖標目錄：drawable-mdpi
(7) 重新裝配framework-res.apk
6. 狀態欄信息通知文字顏色修改
狀態欄信息通知文字顏色，是由framework-res.apk文件里res\values下的colors.xml文件控制的，所以我們只需修改colors.xml文件就可以了。另外，此文件還控制下拉欄的文字顏色，可以修改。
用文本編輯器打開colors.xml文件，找到
#ff000000
將這句修改為：#ffffffff
這狀態欄信息通知文字顏色由黑色改為白色。
改好後，打包，簽名，OK。

❼ 為什麼有的電子書反編譯後得到的文本里有亂碼

應該是有些特殊字元吧，反編譯後才出現亂碼。

❽ word轉換成pdf亂碼怎麼辦

word轉換成pdf亂碼出現的原因：
word含特殊字元，而pdf不存在該字元集，比如word是繁體的，而pdf沒有裝繁體庫，顯示不了繁體，從而出現亂碼。
解決方法：
出現這種情況，直接對亂碼的pdf文件是無法處理讓其正常顯示的，只能換其他的轉換方式，對word文檔重新進行轉換，下面推薦幾種出現亂碼幾率較低的轉換方法。
1、使用Word
2010、2007可以直接另存Word文檔為PDF，支持中文，一般不會出現亂碼的情況。
2、使用wps2010和2012將word轉換成pdf出現亂碼的幾率也比較低，直接點擊【文件】【輸出pdf】就可以了。
3、上傳到Google
Docs，然後下載為PDF，一般也不會出現亂碼的情況。