dll內存反編譯
Unity3D主要使用C#語法和開源mono運行開發商的代碼邏輯，所有代碼都不是編譯到EXE，而是位於{APP}\build\game_Data\Managed\Assembly-CSharp.dll。而且mono執行原理跟微軟.NET Framework兼容但是執行原理完全不一樣。傳統的.NET Framework加殼全部失效，因為Assembly-CSharp.dll不是PE格式的動態庫也不是.NET的動態庫，無法從 .NET Framework 載入，而是由mono.dll讀取 Assembly-CSharp.dll的裡面C#腳本解釋執行。
Virbox Protector 對 Assembly-CSharp.dll 做加密，無需手動加密 Assembly-CSharp.dll 代碼，自動編譯 mono， Assembly-CSharp.dll 代碼按需解密，只有調用到才會在內存解密，不調用不解密，黑客無法一次解出所有的代碼。一鍵加密代碼邏輯，無法反編譯，無法mp內存。不降低游戲幀數，自帶反黑引擎，驅動級別反調試，秒殺市面的所有調試器。
Uinty3D 主要的游戲資源都在 resources.assets ，游戲裡面所有放在 resources 文件夾下的東西都會放在這里，DSProtector工具可以對Unity軟體中的 .resS和resources等資源文件進行加密防止軟體或游戲中的資源被非法提取。
② 如何防止Unity3D代碼被反編譯
加密原理(無需Unity源碼):
1. IDA Pro打開libmono.so, 修改mono_image_open_from_data_with_name為
mono_image_open_from_data_with_name_0,
2. 替換實現mono_image_open_from_data_with_name,
extern mono_image_open_from_data_with_name_0(...);
mono_image_open_from_data_with_name(...) {
MonoImage *img = mono_image_open_from_data_with_name_0(...);
//發現數據文件頭不是DLL前綴則解密 img->raw_data, 相應修改img->raw_data_len
return img;
}
3. 重新打包libmono.so; 替換Unity3D中的android下的版本.
4. 另外寫個加密的工具，植入構建環境(MonoDeveloper或VS，添加一個打包後Build Phase來加密DLL); (IOS下禁用JIT固採用AOT編譯，DLL中沒有邏輯代碼，所以無需操心);
從AndroidManifest.xml中可以看出，騰訊的改造應該是修改並替換了入口的classes.dex，把以前的入口 UnityPlayerProxyActivity替換為com.tencent.tauth.AuthActivity. 然後去載入了自定義的幾個so: libNativeRQD.so. 周全考慮，為了防止第三方委託libmono去做解密而做了防護措施. 具體實現我還沒做深入分析, 應該也是老套路.
libmono.so中的mono_image_open_from_data_with_name也被替換成了mono_image_open_from_data_with_name_0.
解密(android):
方法一: ROOT android系統(最好是一部手機，別搞模擬器，慢死), 掛載LD_PRELOAD的API hook來實現.
方法二: 內存特徵碼提取，簡單高效無敵; 機器能讀，你就能讀;
③ C# dll 文件有什麼好的混淆工具防止反編譯
首先 C#沒有任何辦法反編譯其次 C#只能混淆代碼，起到一定的功效最後 C#混淆工具很多，VS自帶的並不強大，可以用些比如Dotfuscator、xeoncode、foxit等等
④ C#編寫的DLL如何加密
c# dll 加密最快的方法使用加殼工具Virbox Protector，直接加密，Virbox Protectorke可以對dll進行性能分析，分析每個函數的調用次數，對每個函數選擇保護方式如：混淆/虛擬化/碎片化/代碼加密等；每種加密方法的特點是什麼呢？
代碼加密（X86）：
針對X86匯編代碼：一種代碼自修改技術（SMC）保護代碼。把當前代碼加密存儲為密文，存儲起來，當程序運行到被保護函數時候自動解密並且執行，執行之後再擦除代碼，運行到哪裡才解密哪裡的代碼，黑客無法獲得原始機器指令和內存完整性的代碼，由於是純內存操作所以運行速度快， 性價高的保護手段，建議全加
代碼加密(IL)
針對dotNet程序，保護IL代碼：一種動態運行方法解密被保護代碼。把當前代碼加密存儲為密文，存儲起來，當程序運行到被保護函數時候自動解密並且執行，執行之後再擦除代碼，執行之後再擦除代碼，運行到哪裡才解密哪裡的代碼，黑客無法獲得原始的中間語言的指令和內存完整性的代碼，由於是純內存操作所以運行速度快， 性價高的保護手段，建議全加
類似zip等壓縮軟體把代碼和數據段壓縮，由於帶有動態密碼，沒有任何工具可以自動脫殼，是防止反編譯和反匯編關鍵手段。
代碼混淆（IL）：
將代碼中的各種元素，如變數，函數，類的名字改寫成無意義的名字。比如改寫成單個字母，或是簡短的無意義字母組合，甚至改寫成「__」這樣的符號，使得閱讀的人無法根據名字猜測其用途。
a)重寫代碼中的部分邏輯，將其變成功能上等價，但是更難理解的形式。比如將for循環改寫成while循環，將循環改寫成遞歸，精簡中間變數，等等。
b) 打亂代碼的格式。比如刪除空格，將多行代碼擠到一行中，或者將一行代碼斷成多行等等。
c) 添加花指令，通過特殊構造的指令來使得反匯編器出錯，進而干擾反編譯工作的進行。
代碼混淆器也會帶來一些問題。主要的問題包括：· 被混淆的代碼難於理解，因此調試除錯也變得困難起來。開發人員通常需要保留原始的未混淆的代碼用於調試。· 對於支持反射的語言，代碼混淆有可能與反射發生沖突。· 代碼混淆並不能真正阻止反向工程，只能增大其難度。因此，對於對安全性要求很高的場合，僅僅使用代碼混淆並不能保證源代碼的安全。
代碼混淆的特點是安全度低、不會影響效率。
代碼虛擬化：
針對X86代碼： 是指將機器代碼翻譯為機器和人都無法識別的一串偽代碼位元組流；在具體執行時再對這些偽代碼進行一一翻譯解釋，逐步還原為原始代碼並執行。 這段用於翻譯偽代碼並負責具體執行的子程序就叫作虛擬機VM（好似一個抽象的CPU）。它以一個函數的形式存在，函數的參數就是位元組碼的內存地址。 由於虛擬機代碼和虛擬機CPU的實現可以做到每次都是隨機設計和隨機執行 並且代碼每次可以隨機變化，包括一些邏輯上的等價變化可以參考硬體N個與非門NOT-AND實現各種邏輯門，演算法和訪問內存形式的變化，包括數學上的非等價變化，代碼體積幾乎可以膨脹達到100到10000倍，造成機器無法做演算法還原到原有邏輯。
代碼虛擬化的特點是：安全度中、不會影響效率。
代碼碎片化：
深思自主知識產權的最新技術：基於 LLVM 和 ARM 虛擬機技術，自動抽取海量代碼移入 SS 內核態模塊，極大的降低了使用門檻， 不再需要手動移植演算法，可移植的演算法從有限的幾個增長到幾乎無限多，支持的語言也不再限於 C， 這是加密技術的一次綜合應用，效果上類似於將軟體打散執行，讓破解者無從下手。
安全度高、建議關鍵函數或調用加密鎖方法；使用太多會影響效率
⑤ 如何讓C++寫的dll不被反編譯
簡單回答：
1、理論上不能保證程序不被反編譯。
2、一些加殼軟體可以做到加大被反編譯的難度，迫使操作者先解殼才能做反編譯，但同時會降低程序的運行效率。
3、當前的技術條件下，一般而言，反編譯出的「源代碼」一般而言並不能作學習，參考的源代碼，多數情況下只能用於分析區部片斷分析，主要用於破解或小范圍類修改。
4、一些簡單的加殼軟體：ASPACK、UPX、PECompact等，如果想嘗試，自個去搜索下載後試試。加殼後的軟體還有可能被某些殺軟當成惡意軟體。
5、這也正是很多對安全要求高的系統使用「三層架構」（類似訪問網頁/網站）的原因。因為在三層架構中，核心軟體、數據不被用戶直接接觸。
************以下是相關知識，有耐心可看看************
一、關於反編譯與破解。
1、以當前的技術來說，理論上，所有的程序都存在被反編譯的可能。
2、但是反編譯出來的代碼並不一定能被技術不高的人看懂，因為反編譯出來的「源代碼」與編寫者寫出的原代碼在80%以上是不同的。這是因為反編譯的原理是根據機器碼（或中間碼），讓機算機進行反向生成高級語言，而不是找出編寫者原有的代碼，找出原有的代碼是不可能的。反編譯出來的代碼在可理解性、可閱讀性上，一般而言是非常差的。
3、但是，這並不代碼反編譯出來的「源代碼」沒有價值，對於內行來說，分析反編譯出來的代碼中的某些特定片段，就可以對程序進行破解，找出程序的關鍵點、口令、數據來源等等。因為破壞總是比建設要容易，分析局部比規劃全局要容易得多。
4、如果考慮到被反編譯將關鍵代碼進行特殊處理的話，可能加大相關的難度，比如將特定的字元串分成多個字串在程序中存儲，或是進行加密後存儲，在使用時合成/生成，不用時即時在內存中清除等等……。
5、反編譯後對關鍵部分的定位往往是根據字元串來進行的，比如在用戶沒有注冊時，跳出一行對話，告訴用戶「請注冊後再使用」，破解者就會在反編譯後追查這個字串所在，然後查到這個字串對應的變數與地址，再追查調用這個變數或地址的代碼，然後再延伸查到什麼情況下調用「調用這個變數或地址的代碼」，最後，設定跳過語句。這就是最典型的破解注冊的方法。破解完再將修改了的「源代碼」進行編譯，或是根據「源代碼」直接修正程序中對應的代碼，OK，破解版正式完成。
二、關於加殼。
1、理論上，同樣，沒有破解不了的殼。
2、但是有些加殼軟體使用了一些特別的方法，使得破解殼的難度變得非常難，技術不夠的朋友很難下手，比如將原程序代碼拆分、變型、植入自校驗等等技術。
3、但加殼軟體同樣是程序，它自身就存在被反編的可能，加了殼可以類比成，在一個木箱外面再加個保險櫃。但千萬別以為保險櫃就一定是保險的，面對各種技術開鎖、暴力開箱，再強的保險櫃也只能是加大難度而已。
4、越復雜的加殼，就會使得程序運行時效率降得越低，這是必然的，因為原本只關注目標任務的程序現在還要時時提防著被提取、被監測。
⑥ 如何防止程序員反編譯
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!」);
}
}
在編譯代碼時（如使用ant或maven），使用插件將代碼進行加密（加密方式自己選），將class文件裡面的內容讀取成byte[]，然後進行加密後再寫回到class文件（這時候class文件裡面的內容不是標準的class，無法被反編譯了）
在啟動項目代碼時，指定使用我們自定義的ClassLoader就行了，而自定義的部分，主要就是在這里做解密工作！
上面這段代碼，大家都認識。但我要問的是：如果我們使用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文件就行了，在這之前是什麼樣子無所謂！所以，我們的加密的整個邏輯就是：
如此，搞定！以上的做法比較完整的闡述，可以仔細閱讀一下這篇文章：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就得跟著這個項目到處走啊！
⑦ 如何反編譯exe內的連接
你好。
反編譯 得到匯編代碼 定位到連接字串那裡 直接修改該地址內存 就可以實現了
反匯編可以用debug等工具。
但程序是用什麼語言編的，看不到。就像「Good afternoon.」是從哪種語言翻譯成英語的一樣。
如果導入了msvcr100.dll之類的，很可能是vc編的，如果資源里有TForm之類的，
很可能是delphi編的，如果導入了msvbm60.dll，
則是vb6,如果有兩個.data節，一個還是可執行的，另一個放一堆如找不到fnr之類的錯誤文字，那就是犀利的易語言
⑧ C# DLL如何保護防止被破解
.net的實時編譯（JIT）特性決定了用它開發的程序可以被輕松反編譯，同時由於採用反射等技術，使得DLL能被未授權調用。
所以要想不被破解，一是不能被反編譯看到源碼，二是不能被隨意調用。
什麼混淆加殼加密等，都是可逆的。鑒於.net代碼可以包含非託管代碼，我們可以用C++解析C#代碼生成DLL，這個DLL在被調用時驗證調用者信息，就可以解決針對C#的破解，以及非授權調用了。
參考鏈接：http://blog.csdn.net/qwsf01115/article/details/52169574
⑨ 怎麼查看dll文件啊 我菜鳥！不是菜鳥知道的趕緊進來~！
DLL文件(Dynamic Linkable Library 即動態鏈接庫文件)，是一種不能單獨運行的文件，它允許程序共享執行特殊任務所必需的代碼和其他資源
比較大的應用程序都由很多模塊組成，這些模塊分別完成相對獨立的功能，它們彼此協作來完成整個軟體系統的工作。可能存在一些模塊的功能較為通用，在構造其它軟體系統時仍會被使用。在構造軟體系統時，如果將所有模塊的源代碼都靜態編譯到整個應用程序 EXE 文件中，會產生一些問題：一個缺點是增加了應用程序的大小，它會佔用更多的磁碟空間，程序運行時也會消耗較大的內存空間，造成系統資源的浪費；另一個缺點是，在編寫大的 EXE 程序時，在每次修改重建時都必須調整編譯所有源代碼，增加了編譯過程的復雜性，也不利於階段性的單元測試。
Windows 系統平台上提供了一種完全不同的較有效的編程和運行環境，你可以將獨立的程序模塊創建為較小的 DLL 文件，並可對它們單獨編譯和測試。在運行時，只有當 EXE 程序確實要調用這些 DLL 模塊的情況下，系統才會將它們裝載到內存空間中。這種方式不僅減少了 EXE 文件的大小和對內存空間的需求，而且使這些 DLL 模塊可以同時被多個應用程序使用。Windows 自己就將一些主要的系統功能以 DLL 模塊的形式實現。
一般來說，DLL 是一種磁碟文件，以.dll、.DRV、.FON、.SYS 和許多以 .EXE 為擴展名的系統文件都可以是 DLL。它由全局數據、服務函數和資源組成，在運行時被系統載入到調用進程的虛擬空間中，成為調用進程的一部分。如果與其它 DLL 之間沒有沖突，該文件通常映射到進程虛擬空間的同一地址上。DLL 模塊中包含各種導出函數，用於向外界提供服務。DLL 可以有自己的數據段，但沒有自己的堆棧，使用與調用它的應用程序相同的堆棧模式；一個 DLL 在內存中只有一個實例；DLL 實現了代碼封裝性；DLL 的編制與具體的編程語言及編譯器無關。
在 Win32 環境中，每個進程都復制了自己的讀/寫全局變數。如果想要與其它進程共享內存，必須使用內存映射文件或者聲明一個共享數據段。DLL 模塊需要的堆棧內存都是從運行進程的堆棧中分配出來的。Windows 在載入 DLL 模塊時將進程函數調用與 DLL 文件的導出函數相匹配。Windows 操作系統對 DLL 的操作僅僅是把 DLL 映射到需要它的進程的虛擬地址空間里去。DLL 函數中的代碼所創建的任何對象（包括變數）都歸調用它的線程或進程所有。
調用方式：
1、靜態調用方式：由編譯系統完成對 DLL 的載入和應用程序結束時 DLL 卸載的編碼（如還有其它程序使用該 DLL，則 Windows 對 DLL 的應用記錄減1，直到所有相關程序都結束對該 DLL 的使用時才釋放它，簡單實用，但不夠靈活，只能滿足一般要求。
隱式的調用：需要把產生動態連接庫時產生的 .LIB 文件加入到應用程序的工程中，想使用 DLL 中的函數時，只須說明一下。隱式調用不需要調用 LoadLibrary() 和 FreeLibrary()。程序員在建立一個 DLL 文件時，鏈接程序會自動生成一個與之對應的 LIB 導入文件。該文件包含了每一個 DLL 導出函數的符號名和可選的標識號，但是並不含有實際的代碼。LIB 文件作為 DLL 的替代文件被編譯到應用程序項目中。
當程序員通過靜態鏈接方式編譯生成應用程序時，應用程序中的調用函數與 LIB 文件中導出符號相匹配，這些符號或標識號進入到生成的 EXE 文件中。LIB 文件中也包含了對應的 DL L文件名（但不是完全的路徑名），鏈接程序將其存儲在 EXE 文件內部。
當應用程序運行過程中需要載入 DLL 文件時，Windows 根據這些信息發現並載入 DLL，然後通過符號名或標識號實現對 DLL 函數的動態鏈接。所有被應用程序調用的 DLL 文件都會在應用程序 EXE文件載入時被載入在到內存中。可執行程序鏈接到一個包含 DLL 輸出函數信息的輸入庫文件(.LIB文件)。操作系統在載入使用可執行程序時載入 DLL。可執行程序直接通過函數名調用 DLL 的輸出函數，調用方法和程序內部其 它的函數是一樣的。
2、動態調用方式：是由編程者用 API 函數載入和卸載 DLL 來達到調用 DLL 的目的，使用上較復雜，但能更加有效地使用內存，是編制大型應用程序時的重要方式。
顯式的調用：
是指在應用程序中用 LoadLibrary 或 MFC 提供的 AfxLoadLibrary 顯式的將自己所做的動態連接庫調進來，動態連接庫的文件名即是上面兩個函數的參數，再用 GetProcAddress() 獲取想要引入的函
⑩ 怎麼操作將編譯好的程序與DLL一起發布。
C32asm 可反編譯成匯編文件
http://www.25it.net/SoftView.Asp?SoftID=227
C32asm 是一款非常不錯的國產靜態反編譯工具!
C32Asm現具有如下功能：
快速靜態反編譯PE格式文件(Exe、Dll等)
提供Hex文件編輯功能，功能強大
提供內存Dump、內存編輯、PE文件Dump、PE內存ImageSize修正等多種實用功能
提供內存反匯編功能，提供匯編語句直接修改功能，免去OPCode的直接操作的繁瑣
提供反編譯語句彩色語法功能，方便閱讀分析，能方便自定義語法色彩
提供輸入表、輸出表、參考字元、跳轉、調用、PE文件分析結果等顯示
提供方便的跳轉、調用目標地址的代碼顯示
提供匯編語句逐位元組分析功能，有助於分析花指令等干擾代