在前面已經介紹完了 自動給apk中注入日誌代碼工具icodetools原理了,在那裏咱們曾經說過其實離真正的可以使用價值有點距離,本篇就對這個工具進行一些優化,讓其真正意義上開始能工做量產。當時在前面一篇文章中說到遺留的三個主要問題:java
第一個問題:對每一個類中都添加一個靜態打印方法堆棧信息的方法,這樣會致使有些應用的dex過大,方法數超了問題android
第二個問題:在從輸入一個apk到給每一個類中的每一個方法添加日誌代碼而後在簽名輸出最終的apk,這個過程其實不少步,可是咱們以前都是手動的去進行操做,很是麻煩,因此這裏還得解決一鍵化問題git
第三個問題:在實際演練中會發現一些大型的app調用的方法特別多,致使咋們打印的日誌信息過多霸屏,很難定位到咱們真正想要的那個方法,並且打印日誌調用次數過多會致使應用出現無響應狀態。因此這裏得作一個開關和過濾規則github
只有解決了這三個問題咋們纔算是真正意義上的自動化工具,能夠經歷各類app的考驗。api
咱們可使用在前一篇講解原理的文章中的步驟來進行,用一個比較龐大的企業應用作案例,結果在使用dx將添加日誌代碼以後的jar文件轉化成dex文件的時候出現報錯了:數組
看到這個咱們就猜到了,咱們添加日誌代碼以後的jar中方法數超過了,緣由其實很簡單,由於咱們以前的添加日誌操做是在每一個類中添加一個靜態打印日誌的方法,那麼若是對於一個dex文件中有不少類,那麼就添加了不少相同的打印方法,方法數超了是有可能的。那麼如何解決這個問題呢?其實方案有兩個:微信
第一個方案:由於方法數超了,每一個類都被添加了一個打印堆棧日誌的方法,咋們能夠不用這個方法,把這個方法的代碼直接拷貝到原來類中的每一個方法前。可是這樣會帶來一個問題,若是一個類中的方法不少,那麼就會增長很是多的一樣代碼。最後使用dx轉化的時候會發現也是報錯的。因此該方案不可行。app
第二個方案:由於方法數超了,因此那個打印堆棧的方法確定不能要了,可是又不能把代碼都塞到每一個方法的前面,那麼正常的編碼習慣是能夠把這個打印方法抽取出來放到一個工具類中。從這裏能夠看到這個方案是靠譜的。一個應用中只有這麼一個工具類,並且這個工具類包含了打印堆棧信息的方法,那麼整體來看方法數是沒多大變化的,只是多了一個工具類。框架
有了方案,咋們就得實現了,可是這個實現仍是有點曲折的,由於從方案2來看,咱們須要給dex中添加一個工具類了,可是咱們在前一篇文章中瞭解到,能夠經過ClassVisitor類操做dex中的每一個類信息,經過MethodVisitor類操做dex中每一個類的每一個方法,可是沒有途徑能夠添加一個類的。因此咋們得另想辦法了。工具
咱們如今可以往dex中塞入一個類有兩個方案:
第一個方案:很是清楚dex文件格式以後,能夠去手動的添加類信息到dex中。可是這個方案我只是敢想想,實踐的話我就算了,很簡單由於我怕麻煩!
第二個方案:能夠利用jar工具,在咱們把利用dex2jar把dex添加代碼變成jar文件以後,咱們能夠把jar文件解壓,而後再把咱們須要插入的類放到這個解壓目錄下,最後再用jar命令生成jar文件。最終在使用dx命令生成dex文件。這個方案有點複雜,可是靠譜好操做呀。如今看着有點複雜,可是下面會詳細介紹一個一鍵化工具,到時候都不用你來操做,何談複雜了。可是惋惜的是,這個方案有一個缺點,就是解壓過程當中,Windows平臺是不區分文件名的大小寫的,可是若是原來jar中的包名中有兩個類名是大小寫的,那麼解壓到本地的時候會出錯的。好比一個包裏面有A.class和a.class文件,解壓到本地前者會被後者覆蓋,並且這個方案有點繁瑣了。
第三個方案:能夠直接把編譯以後的classes文件塞到jar文件中。有了這個方案,實現比較簡單了。
注意:
一、這裏咱們本身定義的類文件必定要注意,首先這個類的包名必定要具備本身的惟一性,千萬不可與原來jar中的類重名了,要想作到徹底惟一是不可能了。可是咱們能夠弄一個奇葩的包名和類名就能夠了。這裏我用的名稱是:
cn.wjdiankong.jw.utils.JWUtils這個名稱了。現階段應該不會有重複。
代碼比較簡單,咋們直接來看看便可:
這裏直接藉助ZipEntry類進行添加一個文件到jar文件中便可,可是在添加的時候必定要注意ZipEntry的名稱必須是類的全路徑名稱,咱們是從工具命令外部傳入獲取到的類名:
下面咋們咱們在每一個類的每一個方法以前調用這麼一行代碼便可:JWUtils.printStackTrace(「jw」);,而這段代碼對應的asm代碼爲:
上面操做完成以後,就能夠運行一下程序了,前提是你得先準備一個須要插入的類JWUtils
首先默認狀況下咱們必須得準備一個cn.wjdiankong.jw.utils.JWUtils類,並且類中有一個打印堆棧的方法:
public static void printStackTrace(String tag){….},而後編譯獲取到JWUtils.class文件放到指定工具根目錄下便可。當成功的把JWUtils.class文件塞入到jar文件中以後就能夠直接使用dx命令進行轉化成dex了,這裏有可能會遇到這個錯誤:
這個錯誤緣由是由於我用JDK1.8編譯了JWUtils.java文件,而dx工具不兼容這個JDK版本,因此可使用1.8如下的版本編譯JWUtils.java文件便可。
成功以後,在把dex文件放到apk中,在從新簽名以後的apk,可使用jadx打開查看:
看到了,在apk中咱們已經成功的把咱們的JWUtils類插入進去了,而後咱們在隨便打開一個其餘類看看:
在類的每一個方法以前也成功調用了JWUtils.printStatckTrace方法進行打印日誌信息了。
那麼到這裏其實咱們就解決了第一個問題了,並且從這裏能夠看到之後若是咱們想本身在打印什麼消息能夠本身實現JWUtils類,而後實現printStatckTrace方法便可,可是須要注意的是類名和包名以及方法的簽名都必須一致,否則會報錯的。
解決了第一個問題以後,咋們就能夠來解決第二個問題了,第二個問題實際上是爲了工具更好的可以被使用。由於咱們在前面操做能夠看到從輸入一個源apk到最終輸出一個添加日誌代碼的apk有不少步驟,可是這些操做很是繁瑣。因此這裏咱們就須要把每一步作到代碼化,讓使用該工具的人無感知。因此一鍵化主要從下面幾步進行完善:
第1、解壓apk文件獲取其全部的dex文件
這個代碼簡單不解釋了,可是這裏須要注意的是,不要解壓apk中全部的文件,那樣不必也很浪費時間,這裏只須要解壓dex文件和簽名目錄,由於簽名目錄在下一步須要用到:
第2、刪除原始簽名文件
這一步是爲了後面簽名工做準備,若是這裏不刪除簽名文件的話,後面再進行二次簽名會發現有的apk有衝突
看到了吧,這裏若是不刪除原始簽名,重簽名以後的apk會有兩個簽名文件,原本Android中是容許有多個簽名文件的,可是這些簽名文件信息必須保持一致也就是須要用一樣的私鑰進行簽名,可是如今明顯不是,因此在安裝apk會報錯的。從這裏就能夠看到咋們爲了後面重簽名方便,就在這裏把原始簽名文件刪除便可。
這裏爲了方便就直接藉助aapt命令進行刪除apk中的簽名文件了,命令很簡單:
aapt remove src.apk META-INF/XXX.RSA META-INF/XXX.SF MANIFEST.MF
由於aapt不支持直接刪除目錄操做,因此這裏須要藉助第一步中的解壓META-INF目錄,獲得應用的全部簽名文件,而後在這裏組裝簽名文件名便可。
第3、添加日誌到dex文件中
這個依然用咱們以前介紹的改造以後的dex2jar的接口,把dex轉化成jar文件,而且在每一個類每一個方法中添加日誌代碼,這裏須要注意的是有的apk中可能有多個dex文件,因此須要處理第一步中獲取到解壓以後的全部dex文件。
這裏咱們爲了更好的後續拓展,因此只須要外部工具提供JWUtils.java文件,內部咱們自動使用javac將其編譯成JWUtils.class文件了,
注意:
一、這裏使用javac命令編譯的時候,指定了類文件格式是UTF-8的,因此若是想本身定義JWUtils類的話,須要注意這個文件的格式爲UTF-8,否則在編譯的時候可能會報錯。
二、由於JWUtils.java中用到了Android的系統api,因此編譯的時候須要攜帶系統的android.jar文件一塊兒進行編譯工做。
這一步主要是咱們把上面編譯好的JWUtils.class文件直接塞入到jar文件中便可。
這裏須要注意由於有的應用可能包含多個dex文件,因此咋們在給dex添加JWUtils類的時候,只須要在主dex中添加便可,不可重複添加。而後就藉助dx.jar這個工具進行轉化了。這個jar包在AndroidSDK目錄下有。構造好dx命令以後直接調用main方法便可。
這裏須要把咱們添加代碼以後的dex文件插入到源apk中,依然藉助aapt命令便可,由於aapt命令不支持文件覆蓋功能,因此咋們得先刪除原始的dex文件,而後在添加新的dex文件。
這一步就簡單了,直接使用jarsigner工具命令進行apk簽名便可。簽名以後的文件爲signed.apk。這裏的簽名文件信息寫死了,不支持外部傳入的功能。
到這裏咋們就把全部的步驟用代碼進行整合了,而後咋們須要把這個工具導出一個可執行的jar文件,可是咱們還得想一想爲了讓這個工具更好的拓展,咱們可讓外部傳入一些參數作成動態化功能,這裏接受了外部傳入的5個參數信息:
這裏接受的5個參數以下:
1》工具運行的當前目錄
2》須要處理的源apk文件路徑
3》aapt命令的路徑
4》打印信息的tag,默認是:jw
5》打印信息的類名,默認是:cn.wjdiankong.jw.utils.JWUtils
6》打印信息的方法名:默認是:printStackTrace
而後咋們還須要判斷aapt命令路徑是否有效,以及是否配置了JAVA_HOME環境變量,由於後面幾步都會依賴aapt工具和java的一些工具。因此這兩個內容是必要的。
有了這些接受參數,咱們在外部就好擴展了,好比咱們能夠本身實現打印消息的類,類名和包名隨意定義,也能夠隨意定義打印日誌的方法名,可是方法的簽名不可變也就是必須是這種格式:public static void XXX(String tag)。其實這個簽名也是能夠修改的,可是我以爲沒那個必要了。有這些拓展應該足夠用了。後續看用戶反饋能夠在進行詳細修改。有了這個可執行jar包,咋們就能夠簡單的寫一個批處理icodetools.bat:
cd %~dp0
set aapt_path=D:\Android_tools\AndroidSdk\build-tools\23.0.1\aapt.exe
java -jar libs\icode_tools.jar %~dp0 src.apk %aapt_path% jw cn.wjdiankong.jw.utils.JWUtils printStackTrace
adb install -r signed.apk
pause..
首先進入當前目錄,而後設置aapt_path環境變量,接着就要調用咋們導出來的icode_tools.jar包了,看到這裏輸入了上面對應的6個參數信息。這裏能夠修改的,好比原始apk路徑,aapt路徑,打印消息的tag等。最後爲了方便直接在一鍵化安裝apk。固然這一步可能會失敗,不過失敗了能夠本身想辦法安裝便可,簽名以後的apk是signed.apk,未簽名的apk是unsigned.apk,能夠本身簽名的。
而後就是須要額外的jar包,由於在編譯類文件的時候須要引用到系統api,因此這裏要用到android.jar文件,放在當前目錄的libs下面,同時icode_tools.jar也是在這個目錄下,最後就是還須要一個打印消息的工具類JWUtils.java了,因此最終咋們工具的目錄是這樣的結構:
這裏的簽名文件信息在工具中寫死了,因此這裏不支持修改,若是想本身重簽名可使用工具運行完以後在當前目錄下有一個unsigned.apk文件進行操做便可。
有了這個工具,咋們確定想火燒眉毛的嘗試一下,如今咱們只須要雙擊icodetools_1.0.bat批處理便可坐等結果了:
看到了,全部步驟一鼓作氣,多麼智能一鍵化,不再用那麼費勁了。運行完命令以後的目錄有了簽名和未簽名的apk文件以下:
後續還能夠本身操做這兩個文件。想怎麼玩就怎麼玩。
工具如今已經有了,可是咱們上面都是用了簡單的案例apk進行操做的,這個明顯不符合現實,咱們爲了檢驗此工具的牛逼性,必須用一些大型app來作實驗。由於真的勇士勇於面對淋漓的鮮血!下面就用一個如今很火的直播軟件來進行操做,有人說爲什麼不用微信,彆着急微信後面再用。
看到了,這裏由於應用包含了多個dex,並且每一個dex文件較大,因此在處理的過程當中會比較耗時的,須要慢慢的等待
等操做結束以後,咋們直接運行應用,輸出log信息:
日誌刷刷的,太辣眼睛了徹底把握晃暈了,因此這個就是咱們此次須要解決的第三個問題了。如何讓這些日誌信息不霸屏,在指定地方打印咱們想要的結果。
從上面能夠看到咱們完成了全部的一鍵化操做,可是惋惜的是被那些日誌霸屏了,徹底懵逼的狀態。因此這裏我還得解決一個問題,就是給這個日誌加一些過濾規則,可以很好的控制日誌,讓他受我控制。這個問題其實和上面的工具沒多大關係了,由於在前面咱們知道,那個打印方法已經被弄出來放到了JWUtils這個類中,而這個類是工具須要編譯而後插入到dex中的,因此咋們就能夠直接修改JWUtils中的打印日誌的方法便可。
下面就是我寫的JWUtils類,內部已經有了一些打印信息的過濾規則,主要包括:控制日誌的總開關,須要打印日誌的方法名,返回類型,參數類型,類名等規則。這個規則是一個字符串內容:
-s 1 -m JW -r int -p [int,java.lang.String] -c JWUtils
-s:表示日誌總開關
-m:表示須要打印日誌的方法名稱
-r:表示方法返回的類型
-p:表示方法的參數類型,多個類型直接用分號隔開
-c:表示須要添加日誌的類名
而後我把這行字符串內容保存到/data/local/tmp/log.txt文件中,爲何要保存到這裏呢?有的同窗想保存到SD卡中,可是假若有的應用沒有聲明SD讀寫權限,那怎麼辦?咱們最終的JWUtils類是被插入到應用中的。因此就想到了系統有一個不須要權限有沒有沙盒權限限制的目錄:/data/local/tmp/。
下面簡要的說一下這個過濾規則吧:
首先咱們能夠在一個方法中獲取當前方法的堆棧信息,因此就能夠獲取到當前方法名和類名了:
StackTraceElement[] stackElements = new Throwable().getStackTrace();
由於咱們想要獲取到被插入打印代碼的方法信息,因此這裏只要獲取數組的第二個元素便可,第一個元素實際上是JWUtils.printStackTrace方法信息了。有了這個元素以後直接調用它的兩個方法就能夠獲取到當前方法名稱和類名稱了,這個也就能夠作到方法名和類型的過濾規則了。
而對於上面只能簡單的獲取到指定的方法名和類型,卻獲取不到對應方法的簽名信息,好比參數類型,返回值類型等。因此這裏得費點事,就是須要經過上面獲取到的類名而後用Class.forName方法獲取到對應類的Class對象,而後在獲取該類全部的方法信息:
而後用一個全局數組進行保存,在結合上面的方法名去遍歷這個數組,就能夠獲取到指定方法名對應的方法信息了:
這樣就能夠作到方法的返回值類型,參數類型的過濾規則了,可是有同窗會發現這裏有一個問題,假如一個類中有重構方法,也就是方法名相同的可是方法簽名不同,這裏由於只是經過檢測方法名來獲取到method的信息的。因此對於同一個類中重構方法是沒有過濾效果的。
最後就是一個日誌總開關了,因此最終的過濾規則以下:
有了這個規則以後,咋們再次操做一下,把這個JWUtils類放到icode_tools目錄中,而後再次跑一下icode_tools批處理,安裝便可,這時候咱們先設置一個過濾規則,直接使用命令就進行操做了:
我開始的時候把日誌關閉,而後在打開,在關閉看一下效果,咱們使用echo命令寫入一條規則關閉日誌:
看到了吧,這裏咱們經過總開關能夠控制日誌輸出了,下面再來一條實際的過濾規則,就是經過包名,方法名,返回類型等規則操做一下:-s 1 -m a -c com.meelive.ingkee.v1.core.a.a
這裏咱們經過方法名和類型進行過濾限制,打印以後的結果都是指定類名的方法日誌了。
上面操做的是某直播軟件,爲了有說服力,我得用微信在嘗試一下哈:
看到了,此刻咱們加上規則以後,打開微信頓時以爲爽多了,日誌很少,慢慢操做查看具體方法,從微信的日誌看,這個版本已經開始使用熱修復框架Tinker了。後面得趕快出一篇分析Tinker框架的文章了。
最後在來看一下QQ的日誌:
注意:此過濾規則能夠本身定義的,由於全部的打印消息邏輯都在JWUtils類中,上面說到這個類是開放出來的,也就是能夠本身隨便定義這個類的信息!
好了,到這裏咱們已經解決了在前一篇文章中遇到的三個問題,也是填完了工具的坑,下面來總結一下這三個問題:
第一個問題:方法數超了問題,由於咱們給每一個類都添加了一個打印堆棧信息的方法,因此若是一個dex中包含不少類的話,那麼就會額外增長不少方法,在使用dx工具進行轉化的時候出現了方法數超的問題。
解決方案:能夠把打印堆棧信息的方法抽取到一個工具類中,而後把這個類插入到dex中,這裏採用的方案是經過dex2jar工具轉化dex成jar文件,而後在編譯須要插入的類文件,把編譯以後的類文件直接塞入到jar文件中,最後在原先的dex基礎上每一個類中的每一個方法只須要調用JWUtils.printStackTrace方法便可。
第二個問題:一鍵化完善工做,這個是由於咱們在前面文章中操做的時候發現從抽離apk中的dex文件到最終重簽名apk文件有不少步驟,可是都是人工操做的,很是繁瑣,因此能夠把這些步驟進行整合一步到位。
解決方案:先從apk中解壓出dex文件和簽名文件==》利用aapt命令刪除apk中的簽名文件==》添加代碼到dex中==》編譯工具類獲得class文件,塞入到jar文件中==》使用dx命令轉化成dex文件==》使用aapt命令覆蓋apk中舊的dex文件==》使用jarsigner對apk從新簽名。
而後把工程導出一個可執行的jar包,這裏爲了後續擴展,就提供了執行的入口參數:
1》工具運行的當前目錄
2》須要處理的源apk文件路徑
3》aapt命令的路徑
4》打印信息的tag,默認是:jw
5》打印信息的類名,默認是:cn.wjdiankong.jw.utils.JWUtils
6》打印信息的方法名:默認是:printStackTrace
而後咱們還須要提供一個批處理icodetools.bat文件,主要執行的命令是:
java -jar libs\icode_tools.jar %~dp0 src.apk %aapt_path% jw cn.wjdiankong.jw.utils.JWUtils printStackTrace
第三個問題:優化打印日誌信息規則,這個是由於當咱們使用一鍵化工具生成apk安裝運行以後發現打印日誌太多致使霸屏,並且應用自己還會出現了ANR問題。因此得想個辦法控制打印日誌輸出。
解決方案:加一些日誌輸出過濾規則,首先咋們得有一個日誌總開關,而後是能夠指定須要打印方法所屬的類名,方法名,以及方法的返回類型,參數類型等過濾規則。
須要注意的是,這個過濾規則都是工具使用者能夠本身實現的,就在JWUtils類中,代碼能夠自行修改,若是不想修改,默認的我已經加了這些規則:
-s 1 -m JW -r int -p [int,java.lang.String] -c JWUtils
-s:表示日誌總開關
-m:表示須要打印日誌的方法名稱
-r:表示方法返回的類型
-p:表示方法的參數類型,多個類型直接用分號隔開
-c:表示須要添加日誌的類名
咱們能夠經過echo命令給/data/local/tmp/log.txt文件輸入規則來控制日誌輸出。
本文中咱們能夠學習到一些知識點和經驗值:
一、瞭解到一種往dex文件中插入一個類文件的方法
先把dex轉成jar文件,而後解壓jar文件,複製對應的類文件到解壓目錄下,而後在使用jar命令進行class文件從新打包成jar文件便可。最後在使用dx命令轉成dex文件。
二、瞭解到如何在一個方法中獲得該方法的簽名信息。
經過堆棧信息獲取到該方法的名稱和所在的類名,而後在使用Class.forName方法經過類名獲得類對象,而後在使用反射獲取到該類對應的全部方法簽名信息,而後經過以前的方法名進行檢索獲取到對應方法的簽名信息。
三、javac,jarsiginer,aapt命令的常見用法。
一、當前目錄的須要操做的apk文件名稱默認是src.apk文件,若是想修改apk名稱,能夠手動的修改icodetools.bat中的apk文件名
二、在icodetools.bat中能夠指定當前日誌的tag,默認值是jw
三、當前目錄下還有一個JWUtils.java這個java文件,這個類中有一些打印方法,能夠根據本身的需求定義一些方法,可是定義的方法必須有要求:
1》必須是static類型
2》方法只容許有一個參數是String類型的,而這個參數就是打印的日誌tag
3》方法名稱能夠隨意指定,可是必須在icodetools.bat中保持一致
因此最終的方法模板爲: public static XXX YYY(String tag)
這個類的名稱能夠變更,但必須和icodetools.bat中保持一致
四、當前目錄下的libs目錄中是工具依賴的jar包,不能夠隨便修改
五、當前目錄下的JWUtils.java文件名和包名都不可變更
六、cyy_game.keystore簽名文件名不可進行修改
七、若是想本身再次簽名,可使用unsigned.apk文件操做,signed.apk是使用了cyy_game.keystore文件簽名
八、在icodetools.bat中須要手動設置aapt命令的路徑
九、工具運行前必須配置JAVA_HOME環境變量
十、現階段只支持JDK1.7以及如下版本編譯器,不支持1.8以及以上的
注意:工具目錄下有兩個腳本,一個是icodetools_1.0.bat,一個是icodetools_2.0.bat,這兩個工具主要是由於爲了兼容更多的apk,默認最好先採用icodetools_1.0.bat工具進行嘗試,失敗了能夠在使用icodetools_2.0.bat工具,若是都失敗了那就要反饋問題給我了!
第一個問題:Uncaught translation error: com.android.dx.cf.code.SimException
這樣的錯誤是由於工具版本不兼容問題,能夠嘗試使用另一個版本操做。若是icodetools_1.0.bat操做有問題具使用icodetools_2.0.bat工具操做,若是icodetools_2.0.bat工具操做有問題就是用icodetools_1.0.bat工具進行操做。若是兩個工具都有問題那就是真的有問題了,記得給我反饋!
第二個問題:拷貝文件失敗:java.io.FileNotFoundException: JWUtils.class
這個錯誤主要是由於工具內部會採用javac編譯JWUtils類文件,這裏應該是編譯失敗了,大部分緣由是由於JWUtils這個類文件的編碼格式和語法格式致使的,因此解決版本,能夠本身使用javac命令進行編譯看看具體是哪裏編譯出了問題。
第三個問題:bad class file magic (cafebabe) or version (0034.0000)
這個問題是由於javac這個命令是1.7以上版本的,也就是JDK版本。可是此工具如今只支持JDK1.8版本如下的。因此這裏須要設置JDK版本。
第四個問題:成功注入代碼安裝以後發現無日誌信息
這個問題可能有兩個緣由:第一個是須要檢查日誌的tag是否正確,主要經過查看icodetools.bat文件中的執行命令,第二個緣由是由於默認狀況下開始日誌開關是關閉的,因此咱們還得手動打開,首先得去/data/local/tmp目錄下,而後使用echo 「-s 1」 >log.txt,打開日誌便可。
固然還有其餘問題,因此我但願你們在使用的過程當中遇到問題以及一些優化建議均可以提給我,我會盡快修復!
工具下載地址:https://github.com/fourbrother/icodetools
聲明:有人認爲有了這個工具火燒眉毛的手癢想立馬下載嘗試,可是我想說這尚未結束,由於後面一篇文章纔是重點,任何一個工具都須要發揮其做用纔是個好工具,因此下一篇文章就會帶你們用這個工具來破解一些app!
後期優化:現階段此工具支持Windows系統,後續會增長Mac和Linux系統,現階段只支持apk根目錄下的dex文件,不支持其餘目錄下的dex文件處理,因此對於有些apk此工具處理過程當中會出現錯誤!
解決了這三個問題以後,咋們的工具纔算是比較完整的可以用於生產的工具了,可是由於是本人業餘時間編寫的,因此我相信這個工具確定還有一些漏洞,以及須要優化改善的地方,因此我先將此工具的初版本給出,很是歡迎你們一塊兒使用,若是在使用的過程當中發現有一些問題,必定要記得給我留言,我會當即修復和改善,我相信一個好的工具是靠你們一塊兒貢獻的。問題反饋能夠在我微信私聊我或者是在微信公衆號留言都是能夠的,我會第一時間回覆,先拜謝各位使用者了。寫了這篇文章以後並無結束,由於後面還有一篇文章會詳細介紹這個工具的實際使用,如何用它來解決咱們的實際問題,好比尋找hook點。