Frida 4.0.0發佈∞
是時候進行一次瘋狂的釋放和大量的改進了。
讓我們從面向用戶的更改開始。名為frida repl的CLI工具已重命名為僅frida，現在執行tab completion！這個和其他一些很棒的REPL goodies是由@fitblip貢獻的。
還集成了直接從shell啟動腳本的支持：
$ frida Calculator -l calc.js
_____
(_____)
| | Frida 4.0.0 - A world-class dynamic
| | instrumentation framework
|`-'|
| | Commands:
| | help -> Displays the help system
| | object? -> Display information about 'object'
| | exit/quit -> Exit
| |
| | More info at http://www.frida.re/docs/home/
`._.'
# The code in calc.js has now been loaded and executed
[Local::ProcName::Calculator]->
# Reload it from file at any time
[Local::ProcName::Calculator]-> %reload
[Local::ProcName::Calculator]->
或者，您可能厭倦了console.log（）並希望在腳本中設定一些中斷點，以幫助您瞭解發生了什麼事？現在您可以了，因為efrida剛剛獲得了一個集成的Node.js相容調試器。
（這裡提示“喲，天啊”meme。）
是的，但它實際上非常有用，所有的CLI工具都提供了--調試開關來啟用它：
--debug
# Connect Frida to a locally-running Calculator.app
# and load calc.js with the debugger enabled
$ frida Calculator -l calc.js --debug
_____
(_____)
| | Frida 4.0.0 - A world-class dynamic
| | instrumentation framework
|`-'|
| | Commands:
| | help -> Displays the help system
| | object? -> Display information about 'object'
| | exit/quit -> Exit
| |
| | More info at http://www.frida.re/docs/home/
`._.'
Debugger listening on port 5858
# We can now run node-inspector and start debugging calc.js
[Local::ProcName::Calculator]->
下麵是它的樣子：
你有沒有發現自己想直接從貝殼裏選取目標C原料藥？感謝@Tyilo，您現在可以：
# Trace ObjC method calls in Safari
$ frida-trace -m '-[NSView drawRect:]' Safari
還有其他一些優點，比如對生成回溯的全新支持，以及使用調試符號來表示地址：
var f = Module.findExportByName("libcommonCrypto.dylib",
"CCCryptorCreate");
Interceptor.attach(f, {
onEnter: function (args) {
console.log("CCCryptorCreate called from:\n" +
Thread.backtrace(this.context, Backtracer.ACCURATE)
.map(DebugSymbol.fromAddress).join("\n") + "\n");
}
});
或者你在Windows上試圖找出誰在訪問某些記憶體區域？是啊？好吧，看看newMemoryAccessMonitor。從科技上講，這些程式碼並不新鮮，但直到現在它還沒有暴露在JavaScript api中。
另一個不錯的特性是，從這個版本開始，在另一個設備（如Android）上運行frida服務器時，無需轉發多個TCP埠。
frida-server
現在還有更好的錯誤迴響從遠程行程一直傳播到不同的异常，例如Python。上一個版本附加到Mac上不存在的pid會給您：
SystemError: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2↩
dio_2derror_2dquark.Code0: task_for_pid() for remote pid failed w↩
hile trying to make pipe endpoints: (os/kern) failure (5)
喔，瘋狂。現在簡單地說：
frida.ProcessNotFoundError: unable to find process with pid 1234
那更好。我們來談談表演吧。也許你用了frida trace，想知道它為什麼花這麼多時間“解析函數…”？在一個典型的iOSapp上，只解析一個函數通常需要8秒左右，而現在只需要~ 1秒。雖然有些優化是可能的，但我很快意識到，無論我們以多快的速度枚舉functionexports，我們仍然需要傳輸數據，而且傳輸時間也不合理。解決方案？只需將邏輯移到目標行程並傳輸邏輯而不是數據。簡單。而且，Dalvik和ObjC介面已經優化，囙此秒數减少到毫秒。這裡的短篇故事是當溫特瑞在語言運行時的進一步懶惰。我們在ObjC介面上做了很多工作，現在我們使用ES6代理來提供一個更加習慣和高效的API。
這就引出了下一個話題。ObjC介面有點變化。本質上：
var NSString = ObjC.use("NSString");
現在是：
var NSString = ObjC.classes.NSString;
您仍然使用ObjC.classes來枚舉當前加載的類，但現在的行為類似於將類名映射到JavaScript ObjCbinding的對象。
ObjC.classes
此外，沒有更多的演員，所以：
var NSSound = ObjC.use('NSSound');
var sound = ObjC.cast(ptr("0x1234"), NSSound);
你只要去：
var sound = new ObjC.Object(ptr("0x1234"));
是的，不再有類層次結構試圖模仿ObjC。只是一個完整的動態包裝器，其中方法包裝器是在第一次訪問時構建的，除非嘗試枚舉對象的内容，否則不會獲取方法清單。
不管怎麼說，這已經很長時間了，讓我們總結一下其他的關鍵變化：
- Dalvik介面現在處理varargs方法。感謝@dmchell的報導和幫助追跡。
- 由於@Tyilo，NativePointer還提供了.and（）、.or（）和.xor（）。
.and()
.or()
.xor()
- 攔截器的onEnter/onLeave回檔用於expo