android逆向奇技淫巧六:x音關鍵加密字段算法逆向分析(一)


  上文通過fiddler抓到了點贊的包,並通過對比不同包的差異確定了需要逆向4個關鍵字段的算法:X-Ladon、X-Gorgon、X-Tyhon、X-Argus; 本文嘗試逆向分析這些字段的實現算法!

  既然要逆向分析字段的生算法,第一件事就是要找到算法的生成代碼。這里再重復一句真理: 逆向都是從數據開始的!於是滿懷期待把這4個字符串放到android killer(jdax-gui逆向這種上百兆app時,用全局搜索非常耗內存,我16G的內存都不夠用),結果無一例外都找不到!這不是應征了中國人的那句古話:此地無銀三百兩么!既然這些字段直接搜不到,那么就有這么及種可能:

  •  字段本身被分成了好些段,比如X-Ladon被分成了X-   La  don等段,用完整的字符串搜不到;
  •     字段本身被加密了,使用的時候才動態解密,導致靜態搜索查不到
  •    dex文件被加密或加殼導致靜態搜索查不到
  •    X-Ladon是在so層生成的,所以java層靜態找不到!在kali下用strings命令查找的結果不樂觀,如下:啥都沒有

  

  換成X-試試:這次找到了一大堆,但是挨個人肉搜查后發現還是沒有我們想要的這4個字段,那么只剩一種可能了:這4個字段都被加密了!

    

   關鍵字段直接找不到,只能“圍魏救趙”,從非關鍵字段入口;GET頭有很多字段,GET的url里面不也有很多字段么?其實這些字段都是為了從客戶端給服務端傳遞信息,沒有本質區別的!頭的字段不好找,就從url下手唄!用url的“/aweme/v1/commit/item/digg/”下手,終於找到了(而且還只有2處,非常利於查找):

   

        smali代碼看着不方便,這里繼續換成jadx試試。代碼如下:很明顯用了retrofit框架!

package com.ss.android.ugc.aweme.feed.api;

import androidx.core.util.Pair;
import com.bytedance.covode.number.Covode;
import com.google.b.h.a.q;
import com.meituan.robust.ChangeQuickRedirect;
import com.meituan.robust.PatchProxy;
import com.meituan.robust.PatchProxyResult;
import com.ss.android.b.a;
import com.ss.android.ugc.aweme.feed.model.DeleteItemResp;
import com.ss.android.ugc.aweme.feed.model.DiggItemResponse;
import com.ss.android.ugc.aweme.services.RetrofitService;
import retrofit2.http.GET;
import retrofit2.http.Query;

public final class FeedActionApi {

    /* renamed from: a  reason: collision with root package name */
    public static ChangeQuickRedirect f167036a;

    /* renamed from: b  reason: collision with root package name */
    public static final RetrofitApi f167037b = ((RetrofitApi) RetrofitService.createIRetrofitServicebyMonsterPlugin(false).createNewRetrofit(a.f123092f).create(RetrofitApi.class));

    public interface RetrofitApi {
        static {
            Covode.recordClassIndex(86951);
        }

        @GET("/aweme/v1/aweme/delete/")
        q<DeleteItemResp> deleteItem(@Query("aweme_id") String str);

        @GET("/aweme/v1/commit/item/digg/")
        q<DiggItemResponse> diggItem(@Query("aweme_id") String str, @Query("type") int i, @Query("channel_id") int i2, @Query("filter_warn") int i3);

        @GET("/aweme/v1/commit/item/digg/")
        q<DiggItemResponse> diggItem(@Query("aweme_id") String str, @Query("type") int i, @Query("channel_id") int i2, @Query("city") String str2, @Query("activity") int i3);

        @GET("/aweme/v1/commit/item/digg/")
        q<DiggItemResponse> diggItem(@Query("aweme_id") String str, @Query("origin_aweme_id") String str2, @Query("type") int i, @Query("channel_id") int i2, @Query("city") String str3, @Query("activity") int i3);
    }

    static {
        Covode.recordClassIndex(86950);
    }

    public static Pair<String, Integer> a(String str, int i, int i2, String str2) throws Exception {
        PatchProxyResult proxy = PatchProxy.proxy(new Object[]{str, Integer.valueOf(i), Integer.valueOf(i2), str2}, null, f167036a, true, 244471);
        if (proxy.isSupported) {
            return (Pair) proxy.result;
        }
        f167037b.diggItem(str, i, i2, str2, 0).get();
        return Pair.create(str, Integer.valueOf(i));
    }
}

   從這里也看不出個啥!那就用obejction hook試試唄:結果沒任何反應,說明根本沒調用!

 

   截至目前,靜態分析能用的手段都用了,由於java層混淆地厲害,不太好分析這些類、方法和變量的功能;lib下面的so文件有113個,我也沒時間精力挨個拖到IDA去分析,只剩一條路了:內存搜索和dump!

  先用objection,查找某個字段,有結果:

  

  用frida查看:意外發現了另一個關鍵的字符串;

   

   現在問題又來了:此時如果在windows下用OD或CE調試PE文件,可以在這個內存地址下斷點,一旦有代碼讀寫這個內存地址立即斷下來,用來定位關鍵的代碼;andrdoi端該怎么操作了?先試試GameGardiance!嘗試后發現這里只能查找字符串地址,然后根據maps映射查看,發現這些地址都是通過malloc函數在棧上分配的,根本不再代碼段(這又是一句正確的廢話),無法定位到具體的so!

         

  X-Ladon也是:都是通過malloc在棧上分配的地址,無法定位到so文件!

   

   換成最熟悉的CE:X-Ladon關鍵字段存放的位置很多,但是值得關注的不超過5個,如下:

     

  本以為勝利就在眼前,想直接通過“find out what access this address”定位到關鍵代碼,結果直接報錯!what the fxxk.............

        

   剛開始不知道為啥,后來查了很多資料,發現是hw手機即使root后,默認也沒開啟硬件斷點,所以用gdb調試也沒法下硬件斷點:

         

  好吧,ce沒法下內存斷點,繼續試試ida:內存里面還算順利,4個關鍵的字段都能找到,竊喜(先根據ce的地址找X-Ladon字段,結果在這個字段的附近居然同時出現了其他3個字段,真是得來全不費功夫啊)!

  

  耐心點:每個字段都下個讀寫斷點:

   

   

   

   

  居然一個都沒有斷下來,怎么回事了? 有可能是這些通過malloc分配的地址只用1次(嘗試過用pixel,畢竟是Google的親兒子,root后默認是開啟了硬件斷點的。用CE的“find out what access this address”還是沒斷下來;不管我更換多少視頻、點贊等操作,通過CE查看內存數據一直都沒變,說明這塊內存只被用了一次就沒再用了; 后續從sub_6221c函數分析得知: 這3個字段每次生成前都用malloc分配內存,所以這些內存只用一次,用內存斷點的方式自然是找不到讀寫的代碼),用完就回收,所以導致斷不下來!這種方式每次用的時候都要申請內存,效率較低,但也更加安全,可以有效防止內存斷點的追蹤!還有一種可能:這些加密字段是針對當時發送的數據做加密的,因為每次發送的數據包不同,所以每個數據包加密的密文只用1次,所以用這種方式是無效的!好吧,思路到這里又斷了!

   換個思路:從/proc/pid/maps這里看到,這些地址內存都是通過libc的malloc函數分配的內存,要是在這里下斷點,然后在棧上回溯,是不是就能追蹤到調用者了

   frida有個trace的功能(ida也有,但是調試時經常彈窗爆各種異常,需要手動選擇和點擊,trace的效率台低,已經放棄),首次運行命令后會生成一個js腳本,然后自己在js腳本添加需要打印的信息,我改后的js腳本如下:

{
  /**
   * Called synchronously when about to call malloc.
   *
   * @this {object} - Object allowing you to store state for use in onLeave.
   * @param {function} log - Call this function with a string to be presented to the user.
   * @param {array} args - Function arguments represented as an array of NativePointer objects.
   * For example use args[0].readUtf8String() if the first argument is a pointer to a C string encoded as UTF-8.
   * It is also possible to modify arguments by assigning a NativePointer object to an element of this array.
   * @param {object} state - Object allowing you to keep state across function calls.
   * Only one JavaScript function will execute at a time, so do not worry about race-conditions.
   * However, do not use this to store function arguments across onEnter/onLeave, but instead
   * use "this" which is an object for keeping state local to an invocation.
   */
  onEnter(log, args, state) {
    log('malloc()');
    log('RegisterNatives called from:\n' +Thread.backtrace(this.context, Backtracer.ACCURATE).map(DebugSymbol.fromAddress).join('\n') + '\n');
  },

  /**
   * Called synchronously when about to return from malloc.
   *
   * See onEnter for details.
   *
   * @this {object} - Object allowing you to access state stored in onEnter.
   * @param {function} log - Call this function with a string to be presented to the user.
   * @param {NativePointer} retval - Return value represented as a NativePointer object.
   * @param {object} state - Object allowing you to keep state across function calls.
   */
  onLeave(log, retval, state) {
  }
}

  這里打印調用堆棧;由於被調用很多次,我就不把所有的日子都貼出來了,這里選幾個比較關鍵的:

 
           /* TID 0x30d7 (想不到x音也用sqlite)*/
  9939 ms  RegisterNatives called from:
0xf6f9347d libsqlite.so!0x1e47d
0xf6f8761d libsqlite.so!0x1261d
0xf6f835a5 libsqlite.so!0xe5a5
0xf6f8c939 libsqlite.so!0x17939
0xf6fa2e7d libsqlite.so!0x2de7d
0xf6faf1c1 libsqlite.so!0x3a1c1
0xf6fb24ef libsqlite.so!sqlite3_step+0x19e
0xf757d289 libandroid_runtime.so!0x6b289
0x7343c281 system@framework@boot.oat!oatexec+0x9e5281

 10513 ms  malloc()
           /* TID 0x3c57 */
 10490 ms  RegisterNatives called from:
0xf76473c1 libutils.so!_ZN7android12SharedBuffer5allocEj+0x20
0xf7649a45 libutils.so!_ZN7android10VectorImpl5_growEjj+0x78
0xf7649b41 libutils.so!_ZN7android10VectorImpl8insertAtEPKvjj+0x18
0xf735d803 libui.so!_ZN7android6RegionC2Ev+0x2a
0xf733af79 libgui.so!_ZN7android7Surface11queueBufferEP19ANativeWindowBufferi+0x174
0xf63af4f5 libstagefright.so!_ZN7android6ACodec9BaseState21onOutputBufferDrainedERKNS_2spINS_8AMessageEEE+0x1fc
0xf63ae091 libstagefright.so!_ZN7android6ACodec9BaseState17onMessageReceivedERKNS_2spINS_8AMessageEEE+0x27c
0xf63b166b libstagefright.so!_ZN7android6ACodec14ExecutingState17onMessageReceivedERKNS_2spINS_8AMessageEEE+0x1ea
0xf632a503 libstagefright_foundation.so!_ZN7android25AHierarchicalStateMachine13handleMessageERKNS_2spINS_8AMessageEEE+0x42
0xf632a367 libstagefright_foundation.so!_ZN7android8AHandler14deliverMessageERKNS_2spINS_8AMessageEEE+0x12
0xf632c43b libstagefright_foundation.so!_ZN7android8AMessage7deliverEv+0x3a
0xf632ad8d libstagefright_foundation.so!_ZN7android7ALooper4loopEv+0xe4
0xf7648b67 libutils.so!_ZN7android6Thread11_threadLoopEPv+0x72
0xf742c7bd libc.so!_ZL15__pthread_startPv+0x20
0xf74042d7 libc.so!__start_thread+0x8
           /* TID 0x2eba */
 10206 ms  RegisterNatives called from:
0xf76473c1 libutils.so!_ZN7android12SharedBuffer5allocEj+0x20
0xf7649c45 libutils.so!_ZN7android10VectorImpl7_shrinkEjj+0x58
0xf7649ce5 libutils.so!_ZN7android10VectorImpl13removeItemsAtEjj+0x10
0xf72ee91f libinput.so!_ZN7android13InputConsumer7consumeEPNS_26InputEventFactoryInterfaceEbxPjPPNS_10InputEventE+0x156
0xf75801e1 libandroid_runtime.so!_ZN7android24NativeInputEventReceiver13consumeEventsEP7_JNIEnvbxPb+0x64
0xf75803dd libandroid_runtime.so!_ZN7android24NativeInputEventReceiver11handleEventEiiPv+0x34
0xf764b9d1 libutils.so!_ZN7android6Looper9pollInnerEi+0x214
0xf764baa3 libutils.so!_ZN7android6Looper8pollOnceEiPiS1_PPv+0x86
0xf7589e0d libandroid_runtime.so!_ZN7android18NativeMessageQueue8pollOnceEP7_JNIEnvP8_jobjecti+0x1a
0x72a5755f system@framework@boot.oat!oatexec+0x55f

 10583 ms  malloc()
           /* TID 0x3c56 */
 10510 ms  RegisterNatives called from:
0xf749c5ad libc++.so!_Znwj+0x14
0xb9647870

           /* TID 0x2eba */
 10583 ms  RegisterNatives called from:
0xf76473c1 libutils.so!_ZN7android12SharedBuffer5allocEj+0x20
0xf7649c45 libutils.so!_ZN7android10VectorImpl7_shrinkEjj+0x58
0xf72e8fc5 libinput.so!_ZN7android11MotionEvent10initializeEiiiiiiiiffffxxjPKNS_17PointerPropertiesEPKNS_13PointerCoordsE+0x8a
0xf72ee573 libinput.so!_ZN7android13InputConsumer21initializeMotionEventEPNS_11MotionEventEPKNS_12InputMessageE+0xa0
0xf72ee927 libinput.so!_ZN7android13InputConsumer7consumeEPNS_26InputEventFactoryInterfaceEbxPjPPNS_10InputEventE+0x15e
0xf75801e1 libandroid_runtime.so!_ZN7android24NativeInputEventReceiver13consumeEventsEP7_JNIEnvbxPb+0x64
0xf75803dd libandroid_runtime.so!_ZN7android24NativeInputEventReceiver11handleEventEiiPv+0x34
0xf764b9d1 libutils.so!_ZN7android6Looper9pollInnerEi+0x214
0xf764baa3 libutils.so!_ZN7android6Looper8pollOnceEiPiS1_PPv+0x86
0xf7589e0d libandroid_runtime.so!_ZN7android18NativeMessageQueue8pollOnceEP7_JNIEnvP8_jobjecti+0x1a
0x72a5755f system@framework@boot.oat!oatexec+0x55f

          /* TID 0x3c57 */
 10539 ms  RegisterNatives called from:
0xf76473c1 libutils.so!_ZN7android12SharedBuffer5allocEj+0x20
0xf7649a45 libutils.so!_ZN7android10VectorImpl5_growEjj+0x78
0xf7649b41 libutils.so!_ZN7android10VectorImpl8insertAtEPKvjj+0x18
0xf735d803 libui.so!_ZN7android6RegionC2Ev+0x2a
0xf7324275 libgui.so!_ZN7android10BufferItemC1Ev+0x40
0xf7329adb libgui.so!_ZN7android19BufferQueueProducer11queueBufferEiRKNS_22IGraphicBufferProducer16QueueBufferInputEPNS1_17QueueBufferOutputE+0x172
0xf733aff3 libgui.so!_ZN7android7Surface11queueBufferEP19ANativeWindowBufferi+0x1ee
0xf63af4f5 libstagefright.so!_ZN7android6ACodec9BaseState21onOutputBufferDrainedERKNS_2spINS_8AMessageEEE+0x1fc
0xf63ae091 libstagefright.so!_ZN7android6ACodec9BaseState17onMessageReceivedERKNS_2spINS_8AMessageEEE+0x27c
0xf63b166b libstagefright.so!_ZN7android6ACodec14ExecutingState17onMessageReceivedERKNS_2spINS_8AMessageEEE+0x1ea
0xf632a503 libstagefright_foundation.so!_ZN7android25AHierarchicalStateMachine13handleMessageERKNS_2spINS_8AMessageEEE+0x42
0xf632a367 libstagefright_foundation.so!_ZN7android8AHandler14deliverMessageERKNS_2spINS_8AMessageEEE+0x12
0xf632c43b libstagefright_foundation.so!_ZN7android8AMessage7deliverEv+0x3a
0xf632ad8d libstagefright_foundation.so!_ZN7android7ALooper4loopEv+0xe4
0xf7648b67 libutils.so!_ZN7android6Thread11_threadLoopEPv+0x72
0xf742c7bd libc.so!_ZL15__pthread_startPv+0x20

  10722 ms  malloc()
           /* TID 0x2eba */
 10598 ms  RegisterNatives called from:
0xf76473c1 libutils.so!_ZN7android12SharedBuffer5allocEj+0x20
0xf764749b libutils.so!_ZNK7android12SharedBuffer10editResizeEj+0x2e
0xf7649c33 libutils.so!_ZN7android10VectorImpl7_shrinkEjj+0x46
0xf72e8fd7 libinput.so!_ZN7android11MotionEvent10initializeEiiiiiiiiffffxxjPKNS_17PointerPropertiesEPKNS_13PointerCoordsE+0x9c
0xf72ee573 libinput.so!_ZN7android13InputConsumer21initializeMotionEventEPNS_11MotionEventEPKNS_12InputMessageE+0xa0
0xf72ee927 libinput.so!_ZN7android13InputConsumer7consumeEPNS_26InputEventFactoryInterfaceEbxPjPPNS_10InputEventE+0x15e
0xf75801e1 libandroid_runtime.so!_ZN7android24NativeInputEventReceiver13consumeEventsEP7_JNIEnvbxPb+0x64
0xf75803dd libandroid_runtime.so!_ZN7android24NativeInputEventReceiver11handleEventEiiPv+0x34
0xf764b9d1 libutils.so!_ZN7android6Looper9pollInnerEi+0x214
0xf764baa3 libutils.so!_ZN7android6Looper8pollOnceEiPiS1_PPv+0x86
0xf7589e0d libandroid_runtime.so!_ZN7android18NativeMessageQueue8pollOnceEP7_JNIEnvP8_jobjecti+0x1a
0x72a5755f system@framework@boot.oat!oatexec+0x55f

 10748 ms  malloc()
 10748 ms  RegisterNatives called from:
0xf76473c1 libutils.so!_ZN7android12SharedBuffer5allocEj+0x20
0xf7649c45 libutils.so!_ZN7android10VectorImpl7_shrinkEjj+0x58
0xf72e8fdf libinput.so!_ZN7android11MotionEvent10initializeEiiiiiiiiffffxxjPKNS_17PointerPropertiesEPKNS_13PointerCoordsE+0xa4
0xf72ee573 libinput.so!_ZN7android13InputConsumer21initializeMotionEventEPNS_11MotionEventEPKNS_12InputMessageE+0xa0
0xf72ee927 libinput.so!_ZN7android13InputConsumer7consumeEPNS_26InputEventFactoryInterfaceEbxPjPPNS_10InputEventE+0x15e
0xf75801e1 libandroid_runtime.so!_ZN7android24NativeInputEventReceiver13consumeEventsEP7_JNIEnvbxPb+0x64
0xf75803dd libandroid_runtime.so!_ZN7android24NativeInputEventReceiver11handleEventEiiPv+0x34
0xf764b9d1 libutils.so!_ZN7android6Looper9pollInnerEi+0x214
0xf764baa3 libutils.so!_ZN7android6Looper8pollOnceEiPiS1_PPv+0x86
0xf7589e0d libandroid_runtime.so!_ZN7android18NativeMessageQueue8pollOnceEP7_JNIEnvP8_jobjecti+0x1a
0x72a5755f system@framework@boot.oat!oatexec+0x55f

 10852 ms  malloc()
           /* TID 0x2f52 */
 10513 ms  RegisterNatives called from:
0xf76473c1 libutils.so!_ZN7android12SharedBuffer5allocEj+0x20
0xf7648017 libutils.so!_ZN7android8String16C1EPKDsj+0x10
0xf761e20d libbinder.so!_ZNK7android6Parcel12readString16Ev+0x18
0xf761e269 libbinder.so!_ZNK7android6Parcel16enforceInterfaceERKNS_8String16EPNS_14IPCThreadStateE+0x38
0xf6acb9f9 libmedia.so!_ZN7android13BnOMXObserver10onTransactEjRKNS_6ParcelEPS1_j+0x20
0xf76148f3 libbinder.so!_ZN7android7BBinder8transactEjRKNS_6ParcelEPS1_j+0x3e
0xf7619c8d libbinder.so!_ZN7android14IPCThreadState14executeCommandEi+0x228
0xf7619df9 libbinder.so!_ZN7android14IPCThreadState20getAndExecuteCommandEv+0x44
0xf7619e5d libbinder.so!_ZN7android14IPCThreadState14joinThreadPoolEb+0x34
0xf761e8c1 libbinder.so!0x1f8c1
0xf7648b67 libutils.so!_ZN7android6Thread11_threadLoopEPv+0x72
0xf7566525 libandroid_runtime.so!_ZN7android14AndroidRuntime15javaThreadShellEPv+0x48
0xf742c7bd libc.so!_ZL15__pthread_startPv+0x20
0xf74042d7 libc.so!__start_thread+0x8


11018 ms  malloc()
 11018 ms  RegisterNatives called from:
0xf749c5ad libc++.so!_Znwj+0x14
0xa895f290
          /* TID 0x2eba */
 10951 ms  RegisterNatives called from:
0xf76473c1 libutils.so!_ZN7android12SharedBuffer5allocEj+0x20
0xf7649c45 libutils.so!_ZN7android10VectorImpl7_shrinkEjj+0x58
0xf72e8fc5 libinput.so!_ZN7android11MotionEvent10initializeEiiiiiiiiffffxxjPKNS_17PointerPropertiesEPKNS_13PointerCoordsE+0x8a
0xf72ee573 libinput.so!_ZN7android13InputConsumer21initializeMotionEventEPNS_11MotionEventEPKNS_12InputMessageE+0xa0
0xf72ee927 libinput.so!_ZN7android13InputConsumer7consumeEPNS_26InputEventFactoryInterfaceEbxPjPPNS_10InputEventE+0x15e
0xf75801e1 libandroid_runtime.so!_ZN7android24NativeInputEventReceiver13consumeEventsEP7_JNIEnvbxPb+0x64
0xf75803dd libandroid_runtime.so!_ZN7android24NativeInputEventReceiver11handleEventEiiPv+0x34
0xf764b9d1 libutils.so!_ZN7android6Looper9pollInnerEi+0x214
0xf764baa3 libutils.so!_ZN7android6Looper8pollOnceEiPiS1_PPv+0x86
0xf7589e0d libandroid_runtime.so!_ZN7android18NativeMessageQueue8pollOnceEP7_JNIEnvP8_jobjecti+0x1a
0x72a5755f system@framework@boot.oat!oatexec+0x55f

 11020 ms  malloc()
 11020 ms  RegisterNatives called from:
0xf76473c1 libutils.so!_ZN7android12SharedBuffer5allocEj+0x20
0xf764749b libutils.so!_ZNK7android12SharedBuffer10editResizeEj+0x2e
0xf7649c33 libutils.so!_ZN7android10VectorImpl7_shrinkEjj+0x46
0xf72e8fd7 libinput.so!_ZN7android11MotionEvent10initializeEiiiiiiiiffffxxjPKNS_17PointerPropertiesEPKNS_13PointerCoordsE+0x9c
0xf72ee573 libinput.so!_ZN7android13InputConsumer21initializeMotionEventEPNS_11MotionEventEPKNS_12InputMessageE+0xa0
0xf72ee927 libinput.so!_ZN7android13InputConsumer7consumeEPNS_26InputEventFactoryInterfaceEbxPjPPNS_10InputEventE+0x15e
0xf75801e1 libandroid_runtime.so!_ZN7android24NativeInputEventReceiver13consumeEventsEP7_JNIEnvbxPb+0x64
0xf75803dd libandroid_runtime.so!_ZN7android24NativeInputEventReceiver11handleEventEiiPv+0x34
0xf764b9d1 libutils.so!_ZN7android6Looper9pollInnerEi+0x214
0xf764baa3 libutils.so!_ZN7android6Looper8pollOnceEiPiS1_PPv+0x86
0xf7589e0d libandroid_runtime.so!_ZN7android18NativeMessageQueue8pollOnceEP7_JNIEnvP8_jobjecti+0x1a
0x72a5755f system@framework@boot.oat!oatexec+0x55f

  從日志來看,調用libc.so文件中malloc函數的so文件不多,有libutils.so、libinput.so、libc++.so、libbinder.so、libstagefright.so、libui.so、libgui.so、libsqlite.so,這些so的數量和原始110多個so比,范圍已經小了很多;並且也能定位到so的哪一行代碼層層調用了malloc函數,后續先從內存dump這些so,從這里開始繼續分析!

   ============================分割線==============================

   用jadx分析源碼的時候,發現一個“有趣的”現象: 包名中含有aweme的代碼都是x音的定制代碼,而包名含有bytedance的代碼都是基礎的框架代碼(個人猜測是給公司內部所有產品使用的通用代碼);這些基礎框架代碼包含了retrofit代碼,通過http、network等關鍵自研,hook了 “com.bytedance.frameworks.baselib.network.http.util.UrlUtils.encode” 這個函數;又根據調用棧找到了com.ss.android.ugc.aweme.bp.d$3$1.run,這個是棧底的函數了,說明就是從這里開始運行的;並且從命名看,這明顯是x音的函數,所以需要重點跟蹤!從java層的源碼看,這個是Thread線程,當試圖搜索這個函數的start方法時,但是根本找不到(如下):猜測start方法可能被加殼隱藏了,后續還要好好找找在哪藏着的!

   

 

 

   

 

   

  


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM