利用DNS重綁定攻擊專用網路
利用DNS重綁定攻擊專用網路
來自專欄看雪論壇
6 人贊了文章
家庭WiFi網路是一個神聖的地方，是屬於你自己的網路空間。 在那裡，我們將手機，筆記本電腦和智能設備相互連接並聯通到互聯網，從而改善我們的生活，或者至少我們是這樣想的 。 到了二十世紀末，我們的本地網路已經被越來越多的設備所佔據。 從智能電視和媒體播放器到家庭助理，安全攝像頭，冰箱，門鎖和恆溫器，我們的家庭網路是可信賴的個人和家庭設備的天堂。摘要：點擊錯誤的鏈接可能會導致遠程攻擊者控制你的WiFi路由器，Google Home，智能電視盒子Roku，Sonos揚聲器，家用恆溫器等。
許多這些設備提供有限或不存在的身份驗證來訪問和控制其服務。 它們默認信任網路上的其他設備，就像你信任被允許進入你家的人一樣。 它們使用通用即插即用（UPnP）和HTTP等協議在彼此之間自由通信，同時通過路由器的防火牆，本質上可以防止來自Internet外部的連接請求 。 它們相當於在一個有圍牆的花園中運行，不受外部威脅。至少這是開發人員所認為的。
幾個月前，我開始研究一項有10年歷史的名為DNS重綁定的網路攻擊研究。 簡而言之，DNS重綁定允許遠程攻擊者繞過受害者的網路防火牆，並使用其Web瀏覽器作為代理，直接與其私有家庭網路上的設備進行通信。 通過打開錯誤的鏈接或點開惡意橫幅廣告，你可能會無意中讓攻擊者能夠訪問控制家中溫度的恆溫器。
注意：本研究同時也經由Lily Hay Newman在Wired網站上發表。
什麼是DNS重綁定？
為了更好地理解DNS重綁定的工作方式，首先要了解它所避開的安全機制是有幫助的; Web瀏覽器的同源策略。 許多月前，瀏覽器供應商認為，如果沒有來自第二個域的明確許可，從一個域提供的網頁能夠向另一個域發出任意請求可能不是一個好主意。
如果你在網路上打開惡意鏈接，你到達的網頁將無法向你的銀行網站發出HTTP請求，並利用你在此處登錄的會話來清空你的帳戶。 瀏覽器通過限制來自一個域的HTTP請求僅能訪問位於同一域的其他資源（或明確使用跨源資源共享的另一個域）來禁止這種行為。
可以濫用DNS來誘騙Web瀏覽器與他們不想要的伺服器進行通信。
因為malicious.website和http://bank.com屬於不同的域，http://malicious.website上的代碼無法向http://bank.com/transfer-fund發送標準的XMLHttpRequest請求，因此瀏覽器將它們視為單獨的來源。 瀏覽器通過要求請求的URL的協議，域名和埠號與請求它的頁面的URL相同來強制執行此操作。 聽起來不錯吧？
但是不然。 每個域名後面都有一個IP地址。 malicious.website可能位於34.192.228.43，http://bank.com可能位於171.159.228.150。 域名系統（DNS）提供了一種有用的機制，可以將易於記憶的域名轉換為我們的計算機實際用來相互通信的IP地址。
問題在於現代瀏覽器使用URL來評估同源策略限制，而不是IP地址。 如果malicious.website的IP地址從34.192.228.43快速更改為IP地址171.159.228.150，會發生什麼？ 從瀏覽器上看，沒有任何改變。
但現在，你的瀏覽器實際上正在與http://bank.com交談，而不是與最初託管惡意網站文件的伺服器進行通信。 問題出現了，我們可以通過濫用DNS來誘騙Web瀏覽器與他們不想要的伺服器進行通信。
在過去的一年中，DNS重綁定因為一些流行軟體的漏洞，已經收到了一些短暫的關注。 最值得注意的是，暴雪的視頻遊戲，傳輸Torrent客戶端和幾個以太坊加密貨幣錢包直到最近才不再容易受到DNS重綁定攻擊。 糟糕的情況下，以太坊Geth漏洞可能讓遠程攻擊者完全控制受害者的以太坊賬戶，並使用它完全控制所有硬幣。
DNS重新綁定允許遠程攻擊者繞過受害者的網路防火牆，並使用其Web瀏覽器作為代理，直接與其私有家庭網路上的設備進行通信。
DNS重綁定是如何工作的？
攻擊者控制惡意DNS伺服器來回復域的查詢，比如rebind.network。
攻擊者欺騙用戶在瀏覽器中載入http://rebind.network。 他們可以通過多種方式，從網路釣魚到持久性XSS，或購買HTML橫幅廣告，來實現這一目標。
一旦用戶打開鏈接，他們的Web瀏覽器就會發出DNS請求，查找rebind.network的IP地址。 當它收到受害者的DNS請求時，攻擊者控制的DNS伺服器會使用rebind.network的真實IP地址34.192.228.43進行響應。 它還將響應的TTL值設置為1秒，以便受害者的機器不會長時間緩存它。受害者從http://rebind.network載入網頁，其中包含惡意JavaScript代碼，該代碼開始在受害者的Web瀏覽器上執行。 該頁面開始反覆向http://rebind.network/thermostat發送一些奇怪的POST請求，其中包含JSON有效負載，如{「tmode」: 1,」a_heat」: 95}。首先，這些請求被發送到34.192.228.43上運行的攻擊者的Web伺服器，但過了一段時間（因為瀏覽器DNS緩存的奇怪運作），瀏覽器的解析器觀察到rebind.network的DNS條目是陳舊的，因此它進行另一次DNS查找。攻擊者的惡意DNS伺服器接收受害者的第二個DNS請求，但這次它以IP地址192.168.1.77響應，該地址恰好是受害者本地網路上智能恆溫器的IP地址。受害者的計算機收到此惡意DNS響應，並開始將指向http://rebind.network的HTTP請求指向192.168.1.77。 就瀏覽器而言，沒有任何改變，因此它將另一個POST發送到http://rebind.network/thermostat。這一次，POST請求被發送到在受害者WiFi連接的恆溫器上運行的小型不受保護的Web伺服器。 恆溫器處理請求，受害者家中的溫度設置為95度。
這個場景是我發現並使用的無線電溫控器CT50智能恆溫器的實際漏洞利用（CVE-2018-11315）。 這樣的攻擊可能對專用網路上運行的設備或服務產生深遠的破壞性影響。 通過將受害者的Web瀏覽器用作一種HTTP代理，DNS重綁定攻擊可以繞過網路防火牆，並使受保護的內網上的每個設備都可供外網上的遠程攻擊者使用。
什麼設備會被攻擊？
在我第一次嘗試發現並利用此漏洞後，我擔心可能還有很多其他物聯網設備也可以作為目標。 我開始收集和借用當今市場上一些比較流行的智能家居設備。 在接下來的幾周內，我手上的每一台設備都以某種方式成為DNS重新綁定的受害者，導致信息被泄露，或者在某些情況下，導致設備完全控制。
Google Home，Chromecast，Roku，Sonos WiFi揚聲器和某些智能恆溫器都可以通過未經授權的遠程攻擊者以某種方式與其進行連接。 好像是個大問題吧？
當地網路是一個避風港的想法是一種謬論。 如果我們繼續相信這個謬論，人們會受到傷害。
我一直與這些產品的供應商保持聯繫，所有這些產品都正在開發或已經發布了安全補丁（本論文中包含此披露的更多信息）。 這些只是我業餘時間親自測試過的設備的公司。 如果具有如此高級配置的公司未能防止DNS重綁定攻擊，那麼必須有無數其他供應商同樣不能防止這一攻擊。
演示於此：http://rebind.network
Google Home
快進五年，谷歌似乎已將同樣神秘的API集成到其所有Google Home產品中，而且你可以想像，此時無數業餘愛好者已經很好地記錄了這種未記錄的API。 事實上，今年早些時候，Rithvik Vibhu向公眾發布了詳細的API文檔。
此API提供廣泛的設備控制，無需任何形式的身份驗證。 一些最有趣的功能包括啟動娛樂應用和播放內容，掃描和加入附近的WiFi網路，重啟，甚至恢復出廠設置的能力。
想像一下，你正在瀏覽網頁，突然你的Google Home開始恢復出廠設置。 或者比如你的室友在他們的筆記本電腦上打開網路瀏覽器，並且在你嘗試觀看電影時通過一個HTML廣告將你的Chromecast發送到重啟循環。 我最喜歡的針對此API的攻擊方案之一是濫用WiFi掃描功能。
攻擊者可以將此信息與可公開訪問的駕乘式攻擊數據配對，並僅使用附近的WiFi網路列表獲得準確的地理位置。 即使你已禁用Web瀏覽器的地理位置API並使用VPN來隧道通過其他國家/地區的流量，此攻擊也會成功。
這是我從自己的Chromecast中刪除的部分數據示例。 你能弄明白我在什麼地方寫這篇文章嗎？
更新(06/19/2018): Craig Young昨天在此帖之前公布了對此漏洞的同步和獨立研究。他實際上為我上面描述的地理定位攻擊場景創建了一個PoC，但還沒有對此加以實現。 他的作品和Brian Kreb對它的評論都非常出色。
我在3月份發現此漏洞時通知了Google，並在無響應後於4月再次通知了Google。根據Kreb的帖子，Young在5月向谷歌報告了這個漏洞並且他的請求以「狀態：不會修復（預期行為）」為由被關閉了。 直到Krebs自己聯繫谷歌，他們才同意修補漏洞。 預計谷歌將於2018年7月中旬發布補丁。
Sonos Wifi 揚聲器
與Google Home一樣，Sonos WiFi揚聲器也可以由遠程攻擊者（CVE-2018-11316）控制。 通過打開錯誤的鏈接，你會發現令人愉快的夜晚爵士樂播放列表，會突然被非常不同的內容所打斷。 對於簡單的惡作劇來說這很有趣，但最終還是無害的，對嗎？
經過一番挖掘後，我在Sonos UPnP網路伺服器上發現了一些其他有趣的鏈接，這些鏈接可能並不那麼無辜。 看來設備上可以訪問幾個隱藏的網頁以進行調試。
http://192.168.1.76:1400/support/review提供的XML文件似乎包含在Sonos設備上運行的幾個Unix命令的輸出（它本身似乎運行在一個Linux發行版系統上）。
http://192.168.1.76:1400/tools提供了一個簡單的HTML表單，讓你自己在Sonos設備上運行一些這些Unix命令！ Sonos HTTP API允許遠程攻擊者使用traceroute命令映射內部和外部網路，並使用簡單的POST請求通過ping使用ICMP請求探測主機。 攻擊者可以使用Sonos設備作為樞軸點來收集有用的網路拓撲和連接信息，以用於後續攻擊。
更新（06/19/2018）：Sonos已發布聲明並公開表示; 「在了解DNS重綁定攻擊後，我們立即開始研究並將在7月軟體更新中推出修復程序。」
Roku
有趣的是，它還允許直接控制按鈕和按鍵，如虛擬遙控器，以及多個感測器的輸入，包括加速度計，方向感測器，陀螺儀甚至磁力計（為什麼？）正如你可能已經猜到的，這個本地API 不需要身份驗證，可以通過DNS重新綁定（CVE-2018-11314）進行攻擊。
我向Roku安全團隊報告了這些調查結果，他們最初回復說：「使用此API對我們客戶的帳戶或Roku平台沒有安全風險...我們知道可以載入到瀏覽器中並用於與Roku交互的http://remoku.tv等網路應用程序位於同一個本地網路。「
在描述了一個詳細的攻擊場景之後，公司的一名安全副總裁澄清說他們的團隊確實「認為這是一個有效的威脅，而且至少不是平凡的。」為了團隊的信譽，他們立即停止了Roku OS 8.1的發布。 並開始開發一個補丁，如果他們找不到及時發布的解決方案，他們預計可能仍需要3-4個月。
經過一番考慮後，我告訴團隊我正在和WIRED的記者一起工作，我們很可能會快速發布研究報告。 第二天早上，我收到了團隊的一封電子郵件，說明已經開發了一個補丁，並且已經通過固件更新推送到超過2000萬台設備！
更新（06/19/2018）：Roku已發布聲明以及此公示; 「在最近意識到DNS重新綁定問題之後，我們創建了一個軟體補丁，現在正在向客戶推出。 請注意，對此漏洞的任何潛在利用都不會對我們客戶的帳戶，渠道合作夥伴的內容安全或Roku平台造成安全風險。」
Radio恆溫器
Trustwave SpiderLabs的Daniel Crowley試圖多次聯繫該供應商，然後在聽不到該公司的回應後最終發布該漏洞。 不幸的是，這種缺乏響應是多年來漏洞披露的反覆出現的主題，特別是對於較小的製造商而言。 我預計這個漏洞未修補五年的可能性實際上很高，所以我購買了一台全新的CT50。
這個假設被證明是正確的，並且恆溫器的控制API為DNS重新綁定惡作劇留下了大門。 如果你的建築物的恆溫器可以由遠程攻擊者控制，那麼可能會發生的損害非常明顯。
http://rebind.network上的PoC在將目標溫度設置為95°F之前從恆溫器中泄漏了一些基本信息。
在夏季，對於老年人或殘疾人來說，這個溫度可能是危險的，甚至是致命的。 更不用說如果你的設備在你度假時成為攻擊目標，你可以回到家裡去付一大筆公用事業賬單。
這個漏洞的嚴重性，以及美國Radio恆溫器公司多年來一直無視此漏洞，是我們為什麼需要對物聯網設備進行安全監管的完美例子。
無線路由器
如果你還一直在閱讀這篇文章，你可能已經開始考慮家庭網路上可能會被攻擊的其他設備。 你是否會驚訝地發現，從歷史上看，網路路由器本身是DNS重綁定攻擊的最常見目標之一？ 可能不會。
那是因為網路路由器擁有王國的鑰匙。 擁有路由器，你就擁有網路。 我通過DNS重綁定看到了兩種常見的攻擊媒介：
將默認登陸賬戶通過POST發送到登錄頁面，如http://192.168.1.1/login作為自己的路由器管理員頁面。 一旦攻擊者通過身份驗證，他們就可以完全控制設備，並可以隨意配置網路。
通過UPnP使用路由器的Internet網關設備（IGD）介面來配置永久埠轉發連接，並將網路上的任意UDP和TCP埠暴露給公共Internet。
第一種攻擊方式是非常基礎的。 許多路由器都附帶默認登錄賬戶，消費者從不更改它們。 當然，也許他們會啟用WPA2並設置WiFi密碼，但我敢打賭他們中的許多人都沒有意識到他們的路由器的配置面板仍然可以使用「admin：admin」被網路上任何人訪問。
第二種攻擊更糟糕，是徹頭徹尾的諷刺。 不知何故，在這個時代，大多數品牌主打的新家用路由器仍配備默認啟用的UPnP伺服器。 這些UPnP伺服器通過HTTP為網路上任何未經身份驗證的計算機提供類似管理員的路由器配置控制。
網路上的任何機器或通過DNS重綁定的公共Internet都可以使用IGD / UPnP配置路由器的DNS伺服器，添加和刪除NAT和WAN埠映射，查看網路上發送/接收的位元組數，以及訪問 路由器的公共IP地址（有關更多信息，請訪問http://upnp-hacks.org）。
針對路由器的UPnP伺服器的DNS重新綁定攻擊可以在受害者的防火牆中打一個洞，留下永久入口點，對網路上的設備執行原始TCP和UDP攻擊，而不受DNS重新綁定攻擊的正常HTTP限制的約束。
他們甚至可以配置埠轉發規則，將流量轉發到Internet上的外部IP地址，允許攻擊者將受害者的路由器添加為受感染路由器的大型網路中的節點，可用於避開當局的審計（請參閱Akamai最近的 UPnProxy研究）。
IGD還提供了一個通過簡單的未經身份驗證的HTTP請求來發現路由器的公共IP地址的介面。 此功能與DNS重綁定相結合，可用於對試圖通過VPN或使用TOR屏蔽其公共IP地址的用戶進行去匿名化。
根據我的經驗，路由器對DNS重綁定的漏洞是一個混合包。 我已經看到有路由器可以實現完全阻止DNS重綁定攻擊，隨機化其UPnP伺服器埠以使發現和攻擊更加困難，但同時也有對攻擊完全開放的路由器。 我應該提一下，到目前為止，我基本上沒有將DNS重綁定研究應用到路由器......主要是因為我幾乎不敢看。
內網是避風港的想法是一個謊言
今天如此多的設備如何容易受到十年前的攻擊？ 這可能有比我能解釋的更多的理由，但我願意在其中兩個上賭錢。
你必須在雲中啟動惡意DNS伺服器，編寫針對特定服務的一些自定義JavaScript有效載荷，將其提供給目標網路上的受害者，然後找出如何使用其Web瀏覽器轉移到運行的目標計算機 那個服務，你可能不知道的IP地址。 有開銷，而且容易出錯。 （我已經寫了一些工具來緩解一些痛苦。以後會提出更多信息......）
我們需要開發人員在開發軟體時，將本地專用網路視為惡意公共網路。
即使DNS重綁定在網路安全社區中變得越來越流行，這並不能保證我們會看到易受攻擊的設備數量大幅下降。那是因為安全人員不是那些實現這些API的人，而是Web開發人員。當然，Web開發人員應該知道面向外部的API端點需要某種授權，但人們普遍認為私有網路本身可用於保護面向內部網的API。
本地API始終將信任和安全性託付到專用網路本身。如果你的路由器擁有它，為什麼你的本地REST API需要授權？像UPnP這樣的整個協議都圍繞著同一網路上的設備可以相互信任的想法而構建。這是問題的根源。
我們需要開發人員在開發軟體時，將本地專用網路視為惡意公共網路。本地網路是一個避風港的想法是一種謬論。如果我們繼續相信它，人們會受到傷害。
防止DNS重綁定攻擊消費者
作為產品或服務的用戶，你經常受制於構建它的人的擺布。幸運的是，在DNS重新綁定的情況下，只要你可以更改路由器的配置，就可以控制保護網路。 OpenDNS Home是一種免費的DNS服務，可配置為過濾DNS響應中的私有IP範圍等可疑IP地址。你應該能夠將路由器使用的DNS伺服器從默認ISP的DNS伺服器更改為路由器設置中的OpenDNS Home DNS伺服器之一。
如果你希望在路由器本身上控制此過濾而不是信任像OpenDNS這樣的公共DNS伺服器來執行此操作，則可以使用Dnsmasq或選擇在路由器本身上安裝libre路由器固件（如DD-RT）。如果你可以控制路由器，這些解決方案中的任何一個都是足夠的，但請注意，因為無論何時你處於未明確配置以防止它們的網路上，你仍可能成為DNS重新綁定攻擊的目標。
開發者
如果你是開發人員，或者參與創建具有HTTP API的產品，則可以採取一些措施來保護其免受DNS重綁定攻擊。有三種簡單的解決方案可供選擇。
第一個，也是最簡單的實現，對於你現有的系統也沒有副作用，是向你的HTTP伺服器添加「主機」標頭驗證。此標頭包含在從現代瀏覽器發送的所有HTTP請求中，它包含期望與之通信的伺服器的主機（主機名：埠）。此值可以是域名或IP地址，但無論哪種方式，接收請求的伺服器都應驗證其自己的主機是否與所請求的主機匹配。
由於DNS重新綁定依賴於與域名關聯的基礎IP地址的更改，重綁定到目標服務的惡意HTTP請求中的Host頭會保持原始的域名。對路由器登錄頁面的惡意POST請求將具有與你在路由器上的主機名或IP地址不匹配的主機標頭值。它看起來像Host：malicious.website。
Web伺服器應驗證所請求的Host標頭是否與其預期值完全匹配，如果不滿足，則使用403 Forbidden HTTP狀態代碼進行響應。我已經為Express.js Web伺服器編寫了一個NPM模塊，但在任何Web伺服器或語言中都應該很容易實現。
破壞DNS重綁定攻擊的另一種有效方法是使用HTTPS而不是HTTP，即使對於本地網路連接也是如此。發生重新綁定時，目標服務將具有對malicious.website無效的SSL證書，因此安全警告將阻止請求到達你的API端點。
此解決方案還為你的用戶提供額外的隱私和安全性，以及TLS / SSL帶來的常見好處。供應商曆來迴避使用自己的TLS / SSL證書來加固物聯網設備的安全性，但Plex媒體伺服器軟體通過實際使用DNS重綁定來頒發證書並保護其客戶，以有趣的方式解決了這個問題！
可能最好的解決方案是在你的API中添加某種形式的用戶身份驗證，儘管這種解決方案可能會對你現有的服務造成最大的破壞。如果你的API控制真實世界的功能或提供對敏感信息的訪問，則只有選擇方才能訪問它。
它不應該是整個專用網路，因此也不應該通過DNS重新綁定訪問公共Internet。絕對沒有理由認為WiFi網路上的任何設備應該能夠任意控制建築物中的溫度。人們忘記破解WPA2 WiFi是多麼容易。
工具和細節
為了幫助傳播DNS重綁定攻擊的意識，我構建了其他人可以用來創建自己的DNS重綁定攻擊的工具和庫。 除了針對特定設備或服務編寫的JavaScript有效負載之外，交付該有效負載，與惡意DNS伺服器交互以及枚舉受害者專用網路上的主機的過程在不同的攻擊目標之間幾乎相同。 為了降低進入門檻以了解和執行DNS重綁定攻擊，我已經開源了：
一個名為whonow的「惡意」DNS伺服器
一個名為DNS rebind toolkit的前端JavaScript庫
Whonow DNS伺服器
Whonow是一個自定義DNS伺服器，允許你使用域請求本身動態指定DNS響應和重新綁定規則。 這是一個如何工作的例子：
如果你願意，可以立即嘗試，只需使用dig查詢公共whonow實例。 它響應對* rebind.network域名的請求。
DNS Rebind Toolkit是一個實用程序庫，可自動執行DNS重綁定攻擊的過程。 一旦你編寫了一個JavaScript有效載荷來定位特定服務，DNS Rebind Toolkit就可以幫助你在受害者的網路上部署該攻擊。
使用WebRTC IP地址泄漏來發現受害者的本地IP地址。
可以自動執行網路子網枚舉，這樣即使你不知道專用網路上的IP地址，也可以定位設備。
自動化攻擊的DNS重新綁定部分。 你得到一個Promise，一旦重新綁定完成就會解決。
在幕後使用whonow，因此你不必擔心DNS重新綁定攻擊的DNS伺服器組件。
帶有幾個用於攻擊常見物聯網設備的有效負載和記錄良好的示例，以便你學會編寫自己的漏洞。
在192.168.1.1/24子網上啟動對Google Home設備的攻擊就像在index.html頁面中嵌入代碼段一樣簡單。
每個iframe都使用以下JavaScript代碼段嵌入有效內容/ google-home.html：
鏈接和感謝
感謝Lily Hay Newman與我進行了三個月的對話，及她在WIRED中對這項研究進行了報道。 非常感謝William Robertson對這項工作的幫助，特別是讓我攻擊他的家庭網路 和Sonos設備。 我還要感謝Roku和Sonos的安全團隊在開發和部署固件更新方面的迅速反應，以保護他們的用戶免受DNS重綁定攻擊。
以下是我在研究中發現有用的DNS重綁定資源的集合。 你可能也會從中得到幫助！
斯坦福大學的原始DNS重綁定研究（2007年）
https://crypto.stanford.edu/dns/
與Robert RSnake Hansen進行DNS重綁定（精彩視頻）https://www.youtube.com/watch?v=FIQGKIE3Fv0
·
CORS, the Frontendian
https://frontendian.co/cors
Luke Young的DEFCON 25「實現可靠的DNS重新綁定」講座
https://www.youtube.com/watch?v=Q0JG_eKLcws
·
Ricky Lawshae的DEFCON 19 SOAP和UPnP講座
https://www.youtube.com/watch?v=dT0b5DWq9b8
UPnP Hacks網站
http://www.upnp-hacks.org/upnp.html
親愛的開發人員，謹防DNS重綁定
https://www.twistlock.com/2018/02/28/dear-developers-beware-dns-rebinding/
DNS重綁定的實際攻擊
https://www.tripwire.com/state-of-security/vert/practical-attacks-dns-rebinding/
由Tavis Ormandy撰寫的原始暴雪遊戲的DNS重綁定錯誤報告
https://bugs.chromium.org/p/project-zero/issues/detail?id=1471&desc=2
翻譯鏈接：https://medium.com/@brannondorsey/attacking-private-networks-from-the-internet-with-dns-rebinding-ea7098a2d325
編譯：看雪翻譯小組 一壺蔥茜
校對：看雪翻譯小組
原文作者：一壺蔥茜
原文鏈接：https://bbs.pediy.com/thread-230047.htm
編譯：看雪翻譯小組 一壺蔥茜
校對：看雪翻譯小組 SpearMint
更多閱讀：
1、[原創]關於android 微信 frida 使用技巧
2、[原創]Hook原理
3、[翻譯]一次紅隊之旅
4、[原創]逆向及修復最新iOS版少數派客戶端的閃退 bug
5、[原創]逆向分析及修復稀土掘金iOS版客戶端閃退 bug
推薦閱讀：
