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方法可能被加壳隐藏了，后续还要好好找找在哪藏着的！

posted @ 2021-05-30 21:24 第七子007 阅读(8979) 评论(3) 编辑收藏举报

刷新页面返回顶部

第七子007

android逆向奇技淫巧六：x音关键加密字段算法逆向分析（一）

公告