ARM의 코드 실행 모드는 x86과는 다르게 2 or 4바이트씩 처리하는 thumb모드, 4바이트씩 처리하는 arm모드, 두 종류로 나뉩니다.

안드로이드에서 동작하는 대부분의 프로그램(executable)들은 arm과 thumb이 결합된 모드로 컴파일 되어 있습니다.

한 프로그램 내에서 함수에 따라 모드가 달라질 수 있습니다.

아래의 예시 그림은 동일한 파일임에도 각각 다른 모드로 컴파일 되었음을 보여줍니다

THUMB MODE

ARM MODE


x86 후킹과 달리 ARM 후킹은 코드 재배치를 고려해야 하는 경우가 많습니다.

그 이유는 x86은 점프에 필요한 바이트가 단지 5바이트이고,  함수의 프롤로그가 아래와 유사한 경우가 많습니다.

8B FF MOV EDI, EDI

55     PUSH EBP

88 EC MOV EBP, ESP

위의 5바이트는 매우 단순하며, 점프 주소에 복사되어 실행되어도 아무런 문제가 없습니다.


반면, THUMB모드 후킹의 경우는 8바이트가 필요하며(명령어 4바이트, 점프 주소 4바이트), 함수의 프롤로그가 아래와 유사한 경우가 많습니다. (arm 모드 후킹은 추후 다루겠습니다.)

F0 B5 PUSH { R4-R7, LR }

위의 2바이트는 점프 주소에 복사되어 실행되어도 문제없어 보이지만, 이어지는 6바이트가 실행될 때 crash가 야기될 수 있습니다.

아래와 같은 함수가 있다고 가정합니다.

F0 B5 PUSH { R4-R7, LR}

1F 1C MOVS R7, R3

A8 23 MOVS R3, #168

78 4C LDR R4, [PC, #480]

... 후략


7, 8바이트에서 PC + 480 의 값을 참조합니다. 만약 해당 코드가 점프 주소에 그대로 복사되어 실행된다면 엉뚱한 값을 참조하게 되어 결국 의도하지 않은 지점에서 crash가 발생하게 될 것입니다. 

이해를 돕기 위한 그림을 첨부합니다.



이러한 문제들이 발생할 수 있는 가능성이 있기 때문에, 코드 재배치를 해주어야 합니다.

재배치가 고려되어야 할 코드들은 아래와 같습니다.

 THUMB16

 THUMB32

ARM 

 B <label>

 심심할때 작성..

심심할때 작성.. 

 BX PC

   

 ADD <Rdn>, PC

   

 MOV Rd, PC

   

 ADR Rd, <label>

   

 LDR Rt, <label>

   

 CB{N}Z <Rn>, <label>

 


오리지널 코드 4번째 줄에 LDR이 보이므로, 코드 재배치를 해야 합니다.

우선 특정 주소에서 값을 가져와서 r4에 저장할 코드의 일반적인 형태는 다음과 같습니다.

00 4C  ldr r4, [PC] <-- 0xdeadbeef를 취함

01 E0  B PC, #2 <-- 값을 취했으므로 다음 코드를 실행 (B PC, #2)

ef be ad de  <-- 원래의 함수에서 의도된 값

0xdeadbeef는 아래와 같은 수식으로 취할 수 있습니다.

value = (unsigned int*) (Align(pc) + (앞 1바이트 * 2));


구체적으로 풀어보면,

0x78 0x4c에서 0x78만 취한다음, *2를 합니다. (=480) 그 다음 pc를 4바이트 단위로 align합니다.


align 예시)

 PC 

 PC align

 0x87F0 

 0x87F0 

 0x87F2

 0x87F0 

 0x87F4

 0x87F4 

 0x87F6 

 0x87F4 

 0x87F8

 0x87F8


0x87F2:  ldr     r4, [pc, #480]  일 경우, pc는 0x87F4가 됩니다.


0x87F4(align 하였음) + 480(0x1e0) = 0x89d4 를 살펴보면..

0x89D4: C4 FA FF FF     가 보이네요.  

0xFFFFFAC4를 취하면 됩니다. (위의 그림 참조)


아래와 같이 재배치를 할 수 있습니다. 재배치가 필요 없는 코드는 그대로 복사하면 됩니다. (malloc 후에 재배치)


0x789e0001:  f0 b5   push    {r4, r5, r6, r7, lr}

0x789e0003:  1f 1c   adds    r7, r3, #0

0x789e0005:  a8 23   movs    r3, #168     

0x789e0007:  00 4c   ldr     r4, [pc, #0]    ; (0x789e0008) 

0x789e0009:  01 e0   b.n     0x789e000e 

0x789e000b:  c4 fa ff ff   


그런데 뭔가 이상하군요. 0x789e0007 를 보시면 pc + 0x0라인 지점이 영 좋지 않은 곳을 가리켜서 crash가 발생합니다. 의도한대로라면 0x789e000b을 가리켜야 하는데 말이죠. 

이는 2바이트씩 align이 되어 발생한 문제입니다. 이를 해결하려면 thumb16 코드(4바이트 코드는 thumb32라 합니다.) 중간중간에 nop를 삽입시켜주면 됩니다.

0x78dfc001:  f0 b5   push    {r4, r5, r6, r7, lr}

0x78dfc003:  00 bf   nop

0x78dfc005:  1f 1c   adds    r7, r3, #0

0x78dfc007:  00 bf   nop

0x78dfc009:  a8 23   movs    r3, #168        ; 0xa8

0x78dfc00b:  00 bf   nop

0x78dfc00d:  00 4c   ldr     r4, [pc, #0]    ; (0x78dfc010) // (thumb모드이므로 해석된 주소에서 +1씩 더해서 계산해야 합니다.)

0x78dfc00f:  01 e0   b.n     0x78dfc014

0x78dfc011:  c4 fa ff ff         


이제 잘 동작합니다. GOOD! 



[TIP]

gdb 사용시 align을 맞추기 위해 아래 명령어를 실행해 주세요. 한 바이트씩 밀리는 것을 방지하여 줍니다.

(gdb) set arm fallback-mode thumb 

특정 주소를 보는 방법은 dias /r 0xStart 0xEnd

Posted by Codetronik

classes.dex memory dump

Linux 2018.07.19 20:51
메모리 및 파일에 프로세스에 매핑 된 classes.dex를 저장하는 방법입니다.
저장 중에 ptrace가 실패할 경우 0xdeadbeef 가 저장됩니다.


Posted by Codetronik

본 포스팅에서는 dalvik 바이트코드를 메모리에서 변조하는 방법을 다룹니다.


필자의 테스트 환경

- galaxy S5 

- Android 4.4.2

- Snapdragon 805 (32bit) 


"안드로이드 후킹, 메모리 변조 : frida framework를 활용한 dex 함수 후킹"에서 사용한 apk를 그대로 사용합니다.

우선, ida로 classes.dex를 연 다음 check_file 함수를 찾습니다. su 파일 경로를 인자로 전달받아, 파일이 존재하면 true를 리턴하는 함수입니다.

이 함수를 무조건 false를 리턴하게 하면 되겠지요.

현재 바이트 파싱이 big endian으로 되어있기 때문에 바이트를 뒤집어서 보셔야 합니다.

각 바이트들이 무엇을 의미하는지는 http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html 에 자세하게 설명되어 있습니다.

함수의 마지막 줄을 보면 v0을 리턴하게 됩니다. 참고로 0이 true이고 1이 false입니다.

v0이 0또는 1로 설정되어 리턴하는 것을 보실 수 있습니다.

첫 줄을 보면, hex 0x12는 4비트를 변수에 설정하는 opcode입니다.

보통 0x12 0xXY 형태로 사용합니다. 

X는 설정할 값이고, Y는 변수입니다.

Y=0이면 v0, Y=1이면 v1, Y=2이면 v2 이런 식입니다.

우리는 v0 값을 false로 설정할 것이므로, 0x12 0x10 으로 메모리를 변조하면 됩니다.

0x12 0x10 수행 후, 0x00 0x0F 를 통해 리턴을 하게 하면 무조건 false를 리턴하게 되겠지요.


제, classes.dex 메모리를 ptrace를 통해 변조하면 됩니다.

classes.dex 파일에서는 check_file 함수의 offset이 0x132C60이었는데, 메모리에 매핑될 때는 앞에 부가적인 데이터들이 삽입됩니다. (0x28 바이트 고정)

이 데이터들을 건너뛰면, 해당 함수의 offset은 "dex" signature offset으로부터 0x132C60에 위치하게 됩니다. 

아래 그림은 0x76958000 를 덤프한 그림입니다. (메모리 덤프 방법은 http://codetronik.tistory.com/118 참조하세요.

아래 코드와 같이 dex 메모리를 변조할 수 있습니다.

ptrace에서 메모리를 read/write할 때, 사이즈 단위가 long이므로 (테스트한 단말기 환경에서는 4바이트), 아래의 PtraceWrite와 같은 패치 코드를 나눠서 write할 수 있는 함수를 작성해야 합니다.


정상적으로 패치가 되면 아래 화면처럼 null이 나타납니다.



Posted by Codetronik