歡迎來到 黑吧安全網 聚焦網絡安全前沿資訊,精華內容,交流技術心得!

FRIDA腳本系列(四)更新篇:幾個主要機制的大更新

來源:本站整理 作者:佚名 時間:2019-05-05 TAG: 我要投稿

最近沉迷學習,無法自拔,還是有一些問題百思不得騎姐,把官網文檔又翻了一遍,發現其實最近的幾個主要版本,更新還是挺大的,遂花了點時間和功夫,消化吸收下,在這里跟大家分享。
 
進程創建機制大更新
存在的問題:無法為新進程準備參數和環境
當我們使用Frida Python的binding的時候,一般會這么寫:
pid = device.spawn(["/bin/cat", "/etc/passwd"])
或者在iOS平臺上,會這樣寫:
pid = device.spawn(["com.apple.mobilesafari"])
目前來看貌似用這個API只能這么寫,這么寫其實是存在很多問題的,比如說沒有考慮完整參數列表的問題,或者說新進程的環境是繼承自綁定的host機環境還是設備client環境?再比如想要實現定制功能,比如以關閉ASLR模式打開safari,這些都沒有考慮進去。
問題產生的原因(一):當初源碼中就沒有實現
我們先來看看這個API在frida-core里是如何實現的:
namespace Frida {
    …
    public class Device : GLib.Object {
        …
        public async uint spawn (string path,
            string[] argv, string[] envp)
            throws Frida.Error;
        public uint spawn_sync (string path,
            string[] argv, string[] envp)
            throws Frida.Error;
    }
    …
}
這段代碼是用vala語言寫的,frida-core都是用vala寫的,vala看起來跟C#很像,并且最終會被編譯成C代碼。從代碼可以看出,第一個方法——spawan是異步的,調用者調用一遍就可以去干其他事情了,不用等待調用完成,而第二個方法——spawn_sync則需要等到調用完全結束并返回。
這兩個方法會被編譯成如下的C代碼:
void frida_device_spawn (FridaDevice * self,
    const gchar * path,
    gchar ** argv, int argv_length,
    gchar ** envp, int envp_length,
    GAsyncReadyCallback callback, gpointer user_data);
guint frida_device_spawn_finish (FridaDevice * self,
    GAsyncResult * result, GError ** error);
guint frida_device_spawn_sync (FridaDevice * self,
    const gchar * path,
    gchar ** argv, int argv_length,
    gchar ** envp, int envp_length,
    GError ** error);
前兩個函數組成了spawn()的過程,首先調用第一個獲得一個回調,當獲得回調之后就會調用第二個函數——spawn_finish(),將回調的返回值將會作為GAsyncResult的參數。最終的返回值就是PID,當然如果有error的話就會返回error no。
第三個函數——spawn_sync()上面也解釋了,是完全同步的,Frida Python用的其實就是這個。Frida nodejs用的其實是前兩個,因為nodejs里的綁定默認就是異步的。當然以后其實應該也考慮將Frida Python的綁定遷移到異步的模式中來,利用Python 3.5版本引入的async/await機制。
回到上一小節那兩個例子,可以發現其實調用的格式跟我們寫的API并不完全一致,仔細看源碼就會發現,像envp字符串列表并沒有暴露給上層API,如果查看Frida Python的綁定過程的話,就可以發現其實后來在綁定里是這樣寫的:
envp = g_get_environ ();
envp_length = g_strv_length (envp);
也就是說最終我們傳遞給spawn()函數的是調用者的Python環境,這明顯是不對的,host的Python環境跟client的Python肯定是不一樣的,比如像client是iOS或Android的情況。
當然我們在frida-server里做了設定,在spawn()安卓或者iOS的進程的時候,envp會被默認忽略掉,這或多或少減少了問題的產生。
問題產生的原因(二):spawn()的歷史遺留問題
還有一個問題就是spawn()這個古老的API的定義——string[] envp,這個定義意味著不能為空(如果寫成string[]? envp的話其實就可以為空了),也就是說其實無法從根本上區別“用默認的環境配置”和“不使用任何環境配置”。
進程創建機制更新(一):參數、目錄、環境均可設置
既然決定要修這個API,那就干脆順便把跟這個API相關的問題都來看下:
如何給命令提供一些額外的環境參數
設置工作目錄
自定義標準輸入流
傳入平臺特定的參數
修正完以上bug之后,最終代碼會變成下面這樣:
namespace Frida {
    …
    public class Device : GLib.Object {
        …
        public async uint spawn (string program,
            Frida.SpawnOptions? options = null)
            throws Frida.Error;
        public uint spawn_sync (string program,
            Frida.SpawnOptions? options = null)
            throws Frida.Error;
    }
    …
    public class SpawnOptions : GLib.Object {

[1] [2] [3] [4]  下一頁

【聲明】:黑吧安全網(http://www.zjtpzs.live)登載此文出于傳遞更多信息之目的,并不代表本站贊同其觀點和對其真實性負責,僅適于網絡安全技術愛好者學習研究使用,學習中請遵循國家相關法律法規。如有問題請聯系我們,聯系郵箱[email protected],我們會在最短的時間內進行處理。
  • 最新更新
    • 相關閱讀
      • 本類熱門
        • 最近下載
        神秘东方电子游艺