LBE 隐私卫士原理分析
LBE 是業界比較出名的 Android 軟件。對作者的能力深感佩服，同時抱著學習的態度，需要研究一下這個軟件工作原理。請看分析過程！
?
看運行現象：
因為他是攔截權限的，所以第一時間看系統服務，發現在系統服務中出現了三個服務
1.? sec_controller_phone
2. com.lbe.security.service.IFirewallService
3. sec_controller_main
?
看程序的“異常”情況
servicemanager、system_server、phone 三個進程被加載了 libservice.so 動態庫
?
我們打開 APK 包，不難發現，和普通的程序有很多類似的東西，就不看了，主要在 libs 下有三個 so 庫
?
1.? libloader.so
??? 根據以往經驗這個是用來裝載的，應該是注入進程的，進程應該是上面的 servicemanager、system_server、phone
2. libservice.so
??? 是被目標程序所加載
3. 其它暫時不關注
?
注入過程不研究，如果讓我實現這樣的權限攔截的話，我會怎樣設計呢？
?
程序A????????????? 系統服務??????? 我的服務?????????中轉服務?????????? LBE
---------------------------------------------------------------------------------
?
>>>? LBE 建立中轉服務，注冊一個回調，方便有事件得到通知。好彈出對話框。
>>>? 替換某些“系統服務”中的某服務為“我的服務”
>>> 程序A 請求 “系統服務” 服務的時候相當于請求了“我的服務”， “我的服務”再調中轉服務提前處理，然后再調原來的“系統服務”
>>> 完成檢查
?
系統服務進程在 system_server 進程中。
服務管理在 servicemanager 進程中。
?
?
最近找工作非常心煩，很有“不存在感”，都不知道怎么辦了...
??
貌似有些輕度失眠，最近晚上不到4點完全睡不著，于是乎趁著睡不著，起來學習一直都夢寐以求的LBE，感覺還是那么遙不可及的技術啊，不過看看總是有收獲的。感覺這兩個晚上還是沒白看，雖然還是那么遙不可及。
??
首先LBE就不介紹了，Android下面一個安全軟件，不過做得的確很出色，主要就是那一套主動防御的技術。LBE號稱叫做業界最早實現HOOK技術的人，又是Linux，又是ARM...我去，人生是不能洗點的，就這兩點其實就廢掉了，找不到工作也是該的。
??
安裝完了LBE什么發短信，讀手機卡之類的操作會被攔截下來，這點做得確實霸道。不過結合一下Windows HOOK，還是能夠理解原因的。HOOK嘛，首先要注入，然后就是注入后的事。由于現在出的版本都是很新很新的了，在SO中好多調試鏈接信息都被無情地strip鳥，要逆向真的非常頭大。我估摸著老版本沒有問題，于是在網上找了個可以說是第一版的軟件，但是功能還是足夠的，最為重要的是調試信息，拖到IDA里面就感嘆其意義。
??
安裝完畢之后里面有兩個BIN，可能版本不同情況也不同，反正作為最老版是這樣：一個叫libloader.so，一個叫libservice.so。相信SO大家都編過，但是這兩個SO，其實不是傳統書上教的那種，因為連個什么對JAVA接口都沒有。不過我還是相信用法嘛，可能是什么System.loadLibrary之類，但是不是...
??
由AndroidManifest.xml可以知道哪里是入口點，反正就那么找，然后逆向JAVA代碼之后發現了下面這種情況：
??
??
package com.lbe.security.service.loader;
...
String str2 = Integer.toString(Process.myUid());
arrayOfString[1] = str2;
Cursor localCursor = localContentResolver.query(localUri, null, null, arrayOfString, null);
...
??
??
package com.lbe.security.service.loader;
??
public Cursor query(...)
{
??try
??{
???? Runtime localRuntime1 = Runtime.getRuntime();
???? String str3 = "/system/bin/chmod 755 " + str1 + "/libloader.so";
???? java.lang.Process localProcess1 = localRuntime1.exec(str3);
???? try
???? {
?????? Runtime localRuntime2 = Runtime.getRuntime();
?????? String str4 = String.valueOf(str1);
?????? String str5 = str4 + "/libloader.so " + str2;
?????? java.lang.Process localProcess2 = localRuntime2.exec(str5);
?????? l = 4000L;
???? ......
}
??
那就是說，其實這個libloader.so就不是真正的SO而是一個BIN，于是乎一測試就發現了：
# ./libloader.so
./libloader.so
Usage: ./libloader.so euid#
??
??
至于Usage嘛，那應該是后面接個UID就是了（注意：Process.myUid()）。
??
好吧，那么這個loader真是名副其實的loader，而且也不是屬于那種constructor來混淆你的SO而是真正的BIN。記得Windows注入就是一個EXE一個DLL，那么說另外一個SO就是所謂的“HOOK DLL（SO）”。
??
還是繼續從loader下手，它HOOK了那些程序？其實從IDA里面的Strings可以看到一堆，不過還有個函數即使在main附近的一個叫find_pid_of，那個里面有個結構體（猜的），里面講到了三個注入過程：
1、inject_svcmgr（HOOK實際對象是/system/bin/servicemanage），感覺和短信有關
2、inject_server（HOOK為system_server中的/system/lib/libandroid_runtime.so中的導入表sendmsg），據LBE自己說攔截網絡和那個iptables無關，不過sendmsg似乎是UDP的啊，其它情況呢？
3、inject_phonemgr（HOOK為com.android.phone），打電話
??
??
不過怎么HOOK都是后話，我覺得第一步還是怎么注入是關鍵。arm匯編著實讓人頭大，不過大致的流程還是能夠看到，在loader中有一個叫inject_remote_process的函數，其就是主要負責注入滴，而另外三個注入過程的函數（inject_svcmgr、inject_server、inject_phonemgr）都路過調用了它，其中傳入的參數有要注入的進程pid以及一個字符串解析值，不過那個解析值直到看libservice.so才明白（有的注釋自己加的）：
??
libloader.so inject_phonemgr CODE:
??
.text:00008FA4 inject_phonemgr
.text:00008FA4???????????????? STMFD?? SP!, {R4-R10,LR}
.text:00008FA8???????????????? LDR???? R4, =(_GLOBAL_OFFSET_TABLE_ - 0x8FBC)
.text:00008FAC???????????????? LDR???? R6, =0x104
.text:00008FB0???????????????? SUB???? SP, SP, #0x210
.text:00008FB4???????????????? ADD???? R4, PC, R4
.text:00008FB8???????????????? LDR???? R2, [R4,R6]
.text:00008FBC???????????????? ADD???? R5, SP, #0x10C
.text:00008FC0???????????????? MOV???? R10, R0
.text:00008FC4???????????????? LDR???? R3, [R2]
.text:00008FC8???????????????? MOV???? R7, R1
.text:00008FCC???????????????? MOV???? R0, R5
.text:00008FD0???????????????? MOV???? R1, #0x100
.text:00008FD4???????????????? STR???? R3, [SP,#0x20C]
.text:00008FD8???????????????? BL??????getcwd
.text:00008FDC???????????????? MOV???? R0, R5
.text:00008FE0???????????????? BL??????strlen
.text:00008FE4???????????????? LDR???? R1, =0xFFFFF7E8 ; "/libservice.so"
.text:00008FE8???????????????? MOV???? R2, #0xF
.text:00008FEC???????????????? ADD???? R0, R5, R0
.text:00008FF0???????????????? ADD???? R1, R4, R1
.text:00008FF4???????????????? BL??????memcpy
.text:00008FF8???????????????? MOV???? R0, R5
.text:00008FFC???????????????? MOV???? R1, #0
.text:00009000???????????????? BL??????access
.text:00009004???????????????? CMP???? R0, #0
.text:00009008???????????????? BNE???? loc_9094
.text:0000900C???????????????? MOV???? R0, R7
.text:00009010???????????????? BL??????get_thread_list
.text:00009014???????????????? MOV???? R9, R0
.text:00009018???????????????? BL??????getpid
.text:0000901C???????????????? LDR???? R1, =0xFFFFF830 ; "func=%d,sec_uid=%d,sec_pid=%d"
.text:00009020???????????????? ADD???? R8, SP, #0xC
.text:00009024???????????????? STR???? R0, [SP]
.text:00009028???????????????? ADD???? R1, R4, R1
.text:0000902C???????????????? MOV???? R3, R10
.text:00009030???????????????? MOV???? R2, #3
.text:00009034???????????????? MOV???? R0, R8
.text:00009038???????????????? BL??????sprintf
.text:0000903C???????????????? LDR???? R12, =0xFFFFF850 ; "hook_entry"
.text:00009040???????????????? MOV???? R0, R7
.text:00009044???????????????? MOV???? R1, R5
.text:00009048???????????????? ADD???? R2, R4, R12
.text:0000904C???????????????? MOV???? R3, R8
.text:00009050???????????????? BL??????inject_remote_process
.text:00009054???????????????? CMP???? R0, #0
.text:00009058???????????????? BNE???? loc_9084
??
??
??
??
libservice.so hook_entry CODE:
??
.text:00010560???????????????? EXPORT hook_entry
.text:00010560 hook_entry
.text:00010560
.text:00010560 var_20??????????= -0x20
.text:00010560 var_14??????????= -0x14
.text:00010560 var_10??????????= -0x10
.text:00010560 var_C?????????? = -0xC
.text:00010560 var_4?????????? = -4
.text:00010560
.text:00010560???????????????? STR???? LR, [SP,#var_4]!
.text:00010564???????????????? LDR???? R12, =($_GLOBAL_OFFSET_TABLE_ - 0x10578)
.text:00010568???????????????? LDR???? R1, =(aFuncDSec_uidDS - 0x1DF20)
.text:0001056C???????????????? SUB???? SP, SP, #0x1C
.text:00010570???????????????? ADD???? R12, PC, R12
.text:00010574???????????????? ADD???? R3, SP, #0x20+var_10
.text:00010578???????????????? ADD???? LR, SP, #0x20+var_14
.text:0001057C???????????????? ADD???? R1, R12, R1???? ; "func=%d,sec_uid=%d,sec_pid=%d"
.text:00010580???????????????? ADD???? R2, SP, #0x20+var_C
.text:00010584???????????????? STR???? LR, [SP,#0x20+var_20]
.text:00010588???????????????? BL??????sscanf
.text:0001058C???????????????? LDR???? R3, [SP,#0x20+var_C]
.text:00010590???????????????? CMP???? R3, #2????;2號????hook_server
.text:00010594???????????????? BEQ???? loc_105D4
.text:00010598???????????????? CMP???? R3, #3????;3號????hook_phonemgr
.text:0001059C???????????????? BEQ???? loc_105C4
.text:000105A0???????????????? CMP???? R3, #1????;1號????hook_svcmgr
??
??
就是注入進去之后然后調用的hook_entry代碼了，至于這個傳入的"func=%d,sec_uid=%d,sec_pid=%d"被sscanf解析了，func ID不說了，sec_uid應該是來自JAVA代碼的myUid，而pid就是進程吧。
??
??
inject_remote_process是亮點啊，我是完全對Linux不懂，而且ARM也不懂，真麻煩。其大致的過程是：
1、首先ATTACH（附加進程）
??
2、然后GETREGS（讀那個進程寄存器，這里是ARM匯編，不是X86）：
#ifndef __ASSEMBLY__
??
struct pt_regs {
??long uregs[18];
};
??
#define ARM_cpsr uregs[16]
#define ARM_pc uregs[15]
#define ARM_lr uregs[14]
#define ARM_sp uregs[13]
#define ARM_ip uregs[12]
#define ARM_fp uregs[11]
#define ARM_r10 uregs[10]
#define ARM_r9 uregs[9]
#define ARM_r8 uregs[8]
#define ARM_r7 uregs[7]
#define ARM_r6 uregs[6]
#define ARM_r5 uregs[5]
#define ARM_r4 uregs[4]
#define ARM_r3 uregs[3]
#define ARM_r2 uregs[2]
#define ARM_r1 uregs[1]
#define ARM_r0 uregs[0]
#define ARM_ORIG_r0 uregs[17]
??
3、注入代碼POKETEXT（dlopen dlsym dlclose）
??
4、設置寄存器SETREGS（這里有結構體，由于不熟悉ARM，但是粗略猜測這里可能是ARM_lr，因為BX LR嘛）
??
5、運行CONT
??
嗯，也就說就目前這種寫法上看，我需要在自己寫的測試so里面有個hook_entry供調用才行，并且函數格式還得對。不過如果不考慮這些，就用它自己提供的兩個SO，在不啟動LBE主進程的情況下，進行測試，對象為/system/bin/servermanager...
??
這是servermanager沒有運行loader之前的情況（查看maps文件）：
00008000-0000a000 r-xp 00000000 1f:00 564????????/system/bin/servicemanager
0000a000-0000b000 rwxp 00002000 1f:00 564????????/system/bin/servicemanager
0000b000-0000c000 rwxp 0000b000 00:00 0??????????[heap]
40000000-40008000 r-xs 00000000 00:07 188????????/dev/ashmem/system_properties (deleted)
40008000-40028000 r-xp 00000000 00:0a 53???????? /dev/binder
40028000-40029000 r-xp 40028000 00:00 0
afa00000-afa03000 r-xp 00000000 1f:00 364????????/system/lib/liblog.so
afa03000-afa04000 rwxp 00003000 1f:00 364????????/system/lib/liblog.so
afb00000-afb20000 r-xp 00000000 1f:00 419????????/system/lib/libm.so
afb20000-afb21000 rwxp 00020000 1f:00 419????????/system/lib/libm.so
afc00000-afc01000 r-xp 00000000 1f:00 356????????/system/lib/libstdc++.so
afc01000-afc02000 rwxp 00001000 1f:00 356????????/system/lib/libstdc++.so
afd00000-afd3f000 r-xp 00000000 1f:00 368????????/system/lib/libc.so
afd3f000-afd42000 rwxp 0003f000 1f:00 368????????/system/lib/libc.so
afd42000-afd4d000 rwxp afd42000 00:00 0
b0001000-b000c000 r-xp 00001000 1f:00 615????????/system/bin/linker
b000c000-b000d000 rwxp 0000c000 1f:00 615????????/system/bin/linker
b000d000-b0016000 rwxp b000d000 00:00 0
beb4c000-beb61000 rwxp befeb000 00:00 0??????????[stack]
??
??
這是運行之后的情況：
00008000-0000a000 r-xp 00000000 1f:00 564????????/system/bin/servicemanager
0000a000-0000b000 rwxp 00002000 1f:00 564????????/system/bin/servicemanager
0000b000-00011000 rwxp 0000b000 00:00 0??????????[heap]
40000000-40008000 r-xs 00000000 00:07 188????????/dev/ashmem/system_properties (deleted)
40008000-40028000 r-xp 00000000 00:0a 53???????? /dev/binder
40028000-40029000 r-xp 40028000 00:00 0
40029000-4002d000 rwxp 40029000 00:00 0
80000000-8001b000 r-xp 00000000 1f:01 484????????/data/data/com.lbe.security/lib/libservice.so
8001b000-8001f000 rwxp 0001b000 1f:01 484????????/data/data/com.lbe.security/lib/libservice.so
a8100000-a8124000 r-xp 00000000 1f:00 373????????/system/lib/libutils.so
a8124000-a8125000 rwxp 00024000 1f:00 373????????/system/lib/libutils.so
a8200000-a821f000 r-xp 00000000 1f:00 442????????/system/lib/libbinder.so
a821f000-a8225000 rwxp 0001f000 1f:00 442????????/system/lib/libbinder.so
af700000-af713000 r-xp 00000000 1f:00 395????????/system/lib/libz.so
af713000-af714000 rwxp 00013000 1f:00 395????????/system/lib/libz.so
af900000-af90e000 r-xp 00000000 1f:00 372????????/system/lib/libcutils.so
af90e000-af90f000 rwxp 0000e000 1f:00 372????????/system/lib/libcutils.so
af90f000-af91e000 rwxp af90f000 00:00 0
afa00000-afa03000 r-xp 00000000 1f:00 364????????/system/lib/liblog.so
afa03000-afa04000 rwxp 00003000 1f:00 364????????/system/lib/liblog.so
afb00000-afb20000 r-xp 00000000 1f:00 419????????/system/lib/libm.so
afb20000-afb21000 rwxp 00020000 1f:00 419????????/system/lib/libm.so
afc00000-afc01000 r-xp 00000000 1f:00 356????????/system/lib/libstdc++.so
afc01000-afc02000 rwxp 00001000 1f:00 356????????/system/lib/libstdc++.so
afd00000-afd3f000 r-xp 00000000 1f:00 368????????/system/lib/libc.so
afd3f000-afd42000 rwxp 0003f000 1f:00 368????????/system/lib/libc.so
afd42000-afd4d000 rwxp afd42000 00:00 0
b0001000-b000c000 r-xp 00001000 1f:00 615????????/system/bin/linker
b000c000-b000d000 rwxp 0000c000 1f:00 615????????/system/bin/linker
b000d000-b0016000 rwxp b000d000 00:00 0
beb4c000-beb61000 rwxp befeb000 00:00 0??????????[stack]
?
轉載于:https://blog.51cto.com/laokaddk/1175482
總結
以上是生活随笔為你收集整理的LBE 隐私卫士原理分析的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 红黑树的实现（二）
- 下一篇： Exchange 2010 运维技巧一