跳到主要內容

代碼注入及其拓展--逆向開發

今天繼續講述逆向開發中另一個比較重要的課程是代碼注入內容,本篇篇幅比較長,但還是有很多乾貨的,希望大家通過此篇文章更加了解逆向開發中的要點和知識點.我們將分解幾個內容,進行講解:



  1. Framework注入

  2. Dylib注入

  3. MethodSwizzle

  4. 微信示例講解

  5. 總結


讓代碼執行自己的代碼,整體方案如下:



如何讓別人的app來執行自己的代碼呢? 這就要通過代碼注入的方式來達到,而代碼注入的方式有兩種: 一種是通過framework, 一種是dylib方式,另種方案,可以通過Runtime機制


代碼注入思路:


DYLD會動態加載動態庫Framework中所有動態庫,在frameworks中加入自己的一個動態庫,然後在動態庫中hook和注入代碼.


一、FrameWork注入


 1.準備工作



  • 微信6.6.5（越獄應用）

  • MachOView軟件


　　MachOView的下載地址：


　　如果想看源碼如下：MachOView源碼：



  • yololib工具（給MachOView注入framework）


　　yololib工具下載地址：



  • 簽名文件appsign文件


2.流程


2.1 加入準備工作，導入微信6.6.5版本以及腳本appSign.sh重簽名文件



2.2 將appSign導入到項目腳本中



 


 


 2.3 有了上面的兩個步驟后，然後編譯一下工程，會出現一個temp工程，裡面包含了payload文件



2.4 显示包內容，查看可執行文件



 2.5 我們通過MachOView軟件查看WeChat



我們看到有很多的DYLIB，代表的是加載動態庫


2.6  我們在項目中新建framework



 


2.7 新建文件用於驗證



2.8 想要達到剛加載就運行，代碼要寫在load方法



 2.9 編譯一下，查看app包位置會多出一個framework



2.10 显示包內容，在framework查看



由上可知，WJHookFrameWork已經加入成功。


2.11 但是運行並沒有成功，沒有執行load里的代碼


原因：用MachOView打開可執行的WeChat，沒有找到WJHookFrameWork


下面我們講述怎麼將WJHookFramework寫入到MachoView文件中？


3. WJHookFramework寫入到MachOView文件中


需要使用yololib工具，建議將yololib放到 /usr/local/bin



3.1 解壓越獄包



3.2 將WeChat.app显示包內容，找到WeChat可執行的文件


需要增加執行權限： chmod +x WeChat


3.3 寫入WeChat可執行文件


yololib WeChat Frameworks/WJHookFrameWork.framework/WJHookFrameWork


通過上面的過程，查看MachOView文件Load commands中是否有WJHookFrameWork



上面圖显示已經加入成功。


3.4 刪除原有的ipa，打包payload


zip -ry WeChat.ipa Payload


將WeChat.ipa放入App目錄中，刪除其他的文件夾。



 


3.5 再次運行，發現成功！！！



上面就是framework方式代碼注入。大家可以私信我，如有不懂！！！


 二、Dylib注入


2.1 新建工程，添加腳本到build phases 




加入腳本文件



2.2添加第三方庫dylib（mac os的，非ios）



2.3 添加依賴




2.4 修改第三方類庫僅限mac使用，修改Base SDK



2.5 修改signing 



2.6 腳本中注入動態庫的代碼


# ${SRCROOT} 它是工程文件所在的目錄
 TEMP_PATH="${SRCROOT}/Temp"
 #資源文件夾，我們提前在工程目錄下新建一個APP文件夾，裏面放ipa包
 ASSETS_PATH="${SRCROOT}/APP"
 #目標ipa包路徑
 TARGET_IPA_PATH="${ASSETS_PATH}/*.ipa"
 #清空Temp文件夾
 rm -rf "${SRCROOT}/Temp"
 mkdir -p "${SRCROOT}/Temp"
 
 #----------------------------------------
 # 1. 解壓IPA到Temp下
 unzip -oqq "$TARGET_IPA_PATH" -d "$TEMP_PATH"
 # 拿到解壓的臨時的APP的路徑
 TEMP_APP_PATH=$(set -- "$TEMP_PATH/Payload/"*.app;echo "$1")
 # echo "路徑是:$TEMP_APP_PATH"
 
 #----------------------------------------
 # 2. 將解壓出來的.app拷貝進入工程下
 # BUILT_PRODUCTS_DIR 工程生成的APP包的路徑
 # TARGET_NAME target名稱
 TARGET_APP_PATH="$BUILT_PRODUCTS_DIR/$TARGET_NAME.app"
 echo "app路徑:$TARGET_APP_PATH"
 
 rm -rf "$TARGET_APP_PATH"
 mkdir -p "$TARGET_APP_PATH"
 cp -rf "$TEMP_APP_PATH/" "$TARGET_APP_PATH"
 
 #----------------------------------------
 # 3. 刪除extension和WatchAPP.個人證書沒法簽名Extention
 rm -rf "$TARGET_APP_PATH/PlugIns"
 rm -rf "$TARGET_APP_PATH/Watch"
 
 #----------------------------------------
 # 4. 更新info.plist文件 CFBundleIdentifier
 #  設置:"Set : KEY Value" "目標文件路徑"
 /usr/libexec/PlistBuddy -c "Set :CFBundleIdentifier $PRODUCT_BUNDLE_IDENTIFIER" "$TARGET_APP_PATH/Info.plist"
 
 #----------------------------------------
 # 5. 給MachO文件上執行權限
 # 拿到MachO文件的路徑
 APP_BINARY=`plutil -convert xml1 -o - $TARGET_APP_PATH/Info.plist|grep -A1 Exec|tail -n1|cut -f2 -d\>|cut -f1 -d\<`
 #上可執行權限
 chmod +x "$TARGET_APP_PATH/$APP_BINARY"
 
 #----------------------------------------
 # 6. 重簽名第三方 FrameWorks
 TARGET_APP_FRAMEWORKS_PATH="$TARGET_APP_PATH/Frameworks"
 if [ -d "$TARGET_APP_FRAMEWORKS_PATH" ];
 then
 for FRAMEWORK in "$TARGET_APP_FRAMEWORKS_PATH/"*
 do
 
 #簽名
 /usr/bin/codesign --force --sign "$EXPANDED_CODE_SIGN_IDENTITY" "$FRAMEWORK"
 done
 fi
 
 #注入
 yololib "$TARGET_APP_PATH/$APP_BINARY" "Frameworks/libHankHook.dylib"

2.7 編譯運行成功（也和上面一樣在類中加入load代碼）



 


上面就是dylib方式代碼注入，希望對大家有所幫助！！！


 通過上面的兩種方式實現代碼注入,讓別人的app運行自己的app,下面總結如下:



 三、MethodSwizzle


3.1 概念


iOS 中實現AOP編程思想的方式其中之一是Method Swizzling,而 Method Swizzling 是利用Runtime特性把一個方法和另個方法的實現做替換,程序運行時修改Dispatch Table里SEL和IMP之間的映射關係.


通過swizzling method改變目標函數selector所指向實現,在新的實現中來實現所要改的內容即可.



3.2 特點



  • 繼承: 修改較多,無法敢保證他人一定繼承基類

  • 類別: 類別中重寫方法會覆蓋到原有的實現,其實,在真實的開發中,重寫方法並不是為了取代它,而是為了添加一些實現; 如果幾個類別實現了同樣的方法, 但只有一個類別的方法會被調用.

  • AOP優勢: 減少了重複代碼


3.3 代碼


@implementation NSURL (HKURL)
 
 +(void)load
 {
     Method URLWithStr = class_getClassMethod(self, @selector(URLWithString:));
     
     Method HKURL = class_getClassMethod(self, @selector(HKURLWithStr:));
     
     //交換
     method_exchangeImplementations(URLWithStr, HKURL);
 }
 
 +(instancetype)HKURLWithStr:(NSString *)str{
     //調用系統原來的方法
     NSURL * url = [NSURL HKURLWithStr:str];
     if (url == nil) {
         str = @"https://www.blog.com";
     }
     url = [NSURL HKURLWithStr:str];
     
     return url;
 }

在上面的代碼中,利用method swizzling的交換方法.其他Runtime的使用方法,以及為什麼寫在load方法中,請參考本人另篇博客


拓展: 為什麼寫在load中?



  • load方法在源文件被裝載到程序中會被自動調用,不需要手動調用,也不需要該類使用不使用無關,在main()前被執行.

  • 當子類重寫了load,假如子類的類別重寫了load,load的調用順序會這樣: 父類、子類、子類類別

  • 但是如果有多個子類category都重寫了load,每個子類category中load都會調用一次

  • 假如子類沒有重寫load,子類的默認load也不會去調用父類的load.此與正常繼承不太一樣.

  • 在正常的開發中, 除了method swizzle ,其他的邏輯代碼盡量不放在load,load方法中的代碼邏輯要盡量簡單


 


四、微信示例Demo


4.1 微信--破壞註冊


4.1.1 將微信程序運行出來,如下圖所示



4.1.2 根據上面紅色找出類名,方法名



4.1.3 通過插件class-dump導出微信的.h文件


class-dump是將OC運行時聲明的信息導出來的工具, 其實可以導出.h文件. 用此工具將未經過加密的app的頭文件導出來.


使用它同樣也要講此工具拷貝到MAC的目錄下/usr/local/bin下.



4.1.4 經過sublime text來找出對應的文件



4.1.5 通過第三部分講解,利用runtime交換方法



4.1.6 結果



 


4.2 竊取微信密碼


4.2.1 找到輸入密碼框的內容



從上面看出，登錄按鈕為一個FixTitleColorButton對象，Target名字存放的地址為0x280afaa40，Action名字存放地址是0x280afac00。


4.2.2 查看賬號密碼的輸入框



發現賬號密碼輸入框對象屬於都一個對象，叫做WCUITextField


4.2.3 利用LLDB查看登錄具體的Target和Action



從上面卡出，登錄按鈕在WCAccountMainLoginViewController頁面中；


登錄點擊方法叫做onNext


4.2.4 利用Sublime查看WeChat文件


發現確實有onNext（）方法，並從中看出賬號輸入框和密碼輸入框都是WCAccountTextFieldItem中，但是並沒有發現textFileld，但是可以看到WCAccountTextFieldItem是繼承於WCBaseTextFieldItem，我們再看看WCBaseTextFieldItem文件內容



看出一個m_textField對象，通過tex字段取出string。


4.2.5 在賬號欄中輸入賬號和密碼


po [(WCAccountMainLoginViewController *)0x1128bbc00 valueForKey:@"_textFieldUserPwdItem"]
 po [(WCAccountTextFieldItem *)0x28328e880 valueForKey:@"m_textField"]
 po [(WCUITextField *)0x112163a00 text]


通過LLDB調試輸入的密碼是123456。


4.2.6 Hook登錄，獲取密碼


+ (void)load {
     NSLog(@"來了，老弟");
     Method onNext = class_getInstanceMethod(objc_getClass("WCAccountMainLoginViewController"), sel_registerName("onNext"));
     //1.保存原始的IMP
     old_onNext = method_getImplementation(onNext);
     //2.SET
     method_setImplementation(onNext, (IMP)my_next);
 }
 
 IMP (*old_onNext)(id self,SEL _cmd);
 
 void my_next(id self,SEL _cmd){
     // 獲取密碼
     NSString *pwd = [[[self valueForKey:@"_textFieldUserPwdItem"] valueForKey:@"m_textField"] performSelector:@selector(text)];
     NSString *accountTF = [[[self valueForKey:@"_textFieldUserNameItem"] valueForKey:@"m_textField"] performSelector:@selector(text)];
     NSLog(@"密碼是！%@",pwd);
     // 將密碼追加在賬號欄的後面
     [[[self valueForKey:@"_textFieldUserNameItem"] valueForKey:@"m_textField"] performSelector:@selector(setText:) withObject:[NSString stringWithFormat:@"%@+%@",accountTF,pwd]];
     //調用原來的方法
     old_onNext(self,_cmd);
 }

上面用的是setIMP和getIMP的方式，對原方法進行Hook，也可以用class_replaceMethod（），method_exchangeImplementations（）。


 


五、總結


首先從代碼注入的方式：framework和dylib兩種方式，然後講到Method swizzling方式嘗試Hook，最後又以demo的方式來闡述代碼注入和Hook，希望對大家理解逆向開發的代碼注入有所幫助！！！，歡迎大家繼續關注！！！


 


 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計



※不管是台北網頁設計公司、台中網頁設計公司，全省皆有專員為您服務



※Google地圖已可更新顯示潭子電動車充電站設置地點!!



※帶您來看台北網站建置，台北網頁設計，各種案例分享


Orignal From: 代碼注入及其拓展--逆向開發

留言

張貼留言

這個網誌中的熱門文章

有了四步解題法模板，再也不害怕動態規劃！（看不懂算我輸）

導言 動態規劃問題一直是算法面試當中的重點和難點，並且動態規劃這種通過空間換取時間的算法思想在實際的工作中也會被頻繁用到，這篇文章的目的主要是解釋清楚 什麼是動態規劃 ，還有就是面對一道動態規劃問題，一般的 思考步驟 以及其中的注意事項等等，最後通過幾道題目將理論和實踐結合。 什麼是動態規劃 如果你還沒有聽說過動態規劃，或者僅僅只有耳聞，或許你可以看看 Quora 上面的這個 回答 。 How to explain dynamic 用一句話解釋動態規劃就是 " 記住你之前做過的事 "，如果更準確些，其實是 " 記住你之前得到的答案 "。 我舉個大家工作中經常遇到的例子。 在軟件開發中，大家經常會遇到一些系統配置的問題，配置不對，系統就會報錯，這個時候一般都會去 Google 或者是查閱相關的文檔，花了一定的時間將配置修改好。 過了一段時間，去到另一個系統，遇到類似的問題，這個時候已經記不清之前修改過的配置文件長什麼樣，這個時候有兩種方案，一種方案還是去 Google 或者查閱文檔，另一種方案是借鑒之前修改過的配置，第一種做法其實是萬金油，因為你遇到的任何問題其實都可以去 Google，去查閱相關文件找答案，但是這會花費一定的時間，相比之下，第二種方案肯定會更加地節約時間，但是這個方案是有條件的，條件如下： 之前的問題和當前的問題有着關聯性，換句話說，之前問題得到的答案可以幫助解決當前問題 需要記錄之前問題的答案 當然在這個例子中，可以看到的是，上面這兩個條件均滿足，大可去到之前配置過的文件中，將配置拷貝過來，然後做些細微的調整即可解決當前問題，節約了大量的時間。 不知道你是否從這些描述中發現，對於一個動態規劃問題，我們只需要從兩個方面考慮，那就是 找出問題之間的聯繫 ，以及 記錄答案 ，這裏的難點其實是找出問題之間的聯繫，記錄答案只是順帶的事情，利用一些簡單的數據結構就可以做到。 概念 上面的解釋如果大家可以理解的話，接    動態規劃 算法是通過拆分問題，定義問題狀態和狀態之間的關係，使得問題能夠以遞推（或者說分治）的方式去解決。它的幾個重要概念如下所述。    階段： 對於一個完整的問題過程，適當的切分為若干個相互聯繫的子問題，每次在求解一個子問題...
張貼留言
閱讀完整內容

計算機本地文件快要滅絕了

　　 編者按： 文件是数字世界的基石，是我們基本的工作單位。但是，隨着互聯網的雲化、平台化、服務化，文件日益變得可有可無。這樣一種改變究竟好不好呢？喜歡懷舊的 Simon Pitt 開始回顧各種文件的好處，哪怕這讓他顯得不合時宜。原文發表在 medium 上，標題是：Computer Files Are Going Extinct 　　我喜歡文件。我喜歡對文件重命名、移動、排序，改變它們在文件夾中的显示方式，去備份文件，將之上傳到互聯網，恢復它們，對其進行複製，甚至還可以對文件進行碎片整理。作為信息存儲方式的一種隱喻，在我看來文件是很出色的。我喜歡把文件當作一個工作單位。如果我要寫篇文章，文章會放在文件裏面。如果我要生成圖像，圖像會保存進文件裏面。 　　 謳歌 files.doc 　　文件是擬物化的。這是個很花哨的詞，只是用來表示文件是反映現實物品的一個数字概念。比方說，Word 文檔就像一張紙，躺在你的辦公桌上（desktop）。JPEG 就像一幅畫，等等。它們每個都有一個小圖標，圖標的樣子看起來像它們所代表的現實物品。一堆紙，一個畫框，一個馬尼拉文件夾。真的挺很迷人的。 　　我喜歡文件的一點是，不管裏面有什麼，跟文件的交互方式總是一致的。我上面提到的那些東西——複製、排序、碎片整理——我可以對任何文件進行那些處理。文件可能是圖像、遊戲的一部分、也可能是我最喜歡的餐具清單。碎片整理程序不在乎它是什麼。它不會去判斷內容。 　　自從我開始在 Windows 95 裏面創建文件以來，我就一直都很喜歡文件。但是我注意到我們已經開始慢慢地遠離把文件當作基本工作單位的做法。 Windows95。我的計算機 　　 services.mp3 的興起 　　十幾歲的時候，我開始痴迷於收集和管理数字音樂：我收藏 MP3 文件。一大堆的 128 kbps MP3 文件。如果你足夠幸運，有自己的 CD 刻錄機的話，就可以將它們刻錄到 CD 上，然後在朋友之間傳遞。一張 CD 可以容納 700 MB。這相當於將近 500 張軟盤！ 　　我會仔細端詳我的收藏，然後煞費苦心地給它們添加上 IDv1 和 IDv2 音樂標籤。隨着時間的流逝，大家開始開發可以在雲端自動獲取曲目列表的工具，這樣你就可以檢查和驗證 MP3 的質量。有時候我甚至會去聽那些該死的東西，儘管...
張貼留言
閱讀完整內容

純電動 Mini Cooper SE 將成為中國國產車，年產 16 萬輛

BMW 集團與中國長城汽車合資，將於江蘇建立新廠，專門投入生產 MINI Cooper SE 和部分長城品牌電動車，預計於 2022 年完工並投入生產，每年將可生產 16 萬輛電動車。 靈動可愛的 Mini Cooper，在許多車迷心中都有著特殊的地位，今年 7 月發表了首款純電動版本的 Mini Cooper SE 之後，獲得熱烈迴響，預訂數量已接近 8 萬台，顯示大家對於純電 Mini 的熱愛，因為油電版的 Mini Cooper Countryman 的全球總銷售量也才 3 萬出頭。 Mini Cooper SE 之前公布了官方定價，最低從 27,900 歐元起算，美國售價約 29,900 美元。相比現有的三門款，只貴了一成左右。然而，三年後，中國消費者將有機會買到最便宜的電動 Mini。 電動 Mini Cooper SE 最低價是 27,900 歐元，扣掉全額補助最低可以到 24,400 歐元。 BMW 集團與中國長城汽車集團於 2018 年宣布，將組建合資公司光束汽車，投入在中國的電動車生產計畫，而現在他們正式宣布啟動計畫，於江蘇張家港打造一個新工廠，全部投入電動車的製造，包括了 Mini Cooper SE 和其他長城汽車旗下的電動車。 目前的電動 Mini 只在英國牛津工廠製造，不難想像當產能轉移到中國後，Mini Cooper SE 的價格將有機會進一步調降，來競爭全球最大的電動車市場。這座屬於合資公司光束汽車的新工廠，採用一個新的產銷模式，由 BMW 和長城共同合作開發、設計、製造新產品，但是銷售通路完全沿用原本的品牌渠道。 換句話說，2020 年到 2022 年銷售的電動 Mini，將會是英國製造，而 2022 年後就會有中國製造版本開賣，考量到 Mini 在中國每年約有 30 萬輛的銷售額，同時油電版的 Coutryman 銷量更佔了全球將近五分之一，無怪乎 BMW 會想在最接近主要市場的地方蓋工廠囉。 外型完美復刻油車版 最後，簡單介紹一下 Mini Cooper SE 這台車。Mini 在電動化的路上，盡力保持著跟經典造型一致的設計，畢竟大家愛的就是它的設計。電動版的 Mini 車頭、車身跟車屁股都多了一個黃色的插頭標誌，車頭的氣壩則變成封閉式設計，除此之外，幾乎看不出來差別，連馬達...
張貼留言
閱讀完整內容