앱이 실행이 안된다는 보고가 있어서 이 문제를 살펴보았더니 인텔 CPU용 안드로이드 x86/x86_64에서 실행되지 않는 문제였다. 리포팅된 로그에 남아있는 오류는 대략 다음과 같았다.

java.lang.UnsatisfiedLinkError: dlopen failed: \
"/data/app-lib/org.dumpcookie.ringdroidclone-1/libffmpeg_jni.so" has unexpected e_machine: 40

예를 들어 아수스에서 나온 트랜스포머 TF103C는 인텔 Atom CPU를 사용하는데 현재 native library가 arm만 지원하고 있기때문에 실행이 안되고 있던 것이었다.

클론 리플레이어를 x86 기기에 사용하려면 mpg123 / sonic / soundtouch / mpg123 / lame 등등의 각종 라이브러리를 x86 용으로 다시 빌드해야 했기때문에 이를 빌드하고 테스트하기 위하여 다음과 같은 삽질성 작업을 하였다.
- 우선 x86/x86_64를 빌드하기 위해서 삽질 시작. -> ndk-build를 사용하려니 여러 라이브러리 의존성때문에 빌드하기 어려운 난점 -> 라이브러리간 의존성 문제는 ndk-build 빌드 스크립트를 수정하는 방식으로 회피하고, 실제로 빌드하면서 발견되는 컴파일 오류를 바탕으로 Android.mk 픽스하여 arm/x86 ABI로 컴파일
- 이와 더불어 AOSP x86 (Android 6.0 브랜치)프로젝트에서 소스를 가져다가 AOSP 전체 빌드하고,
- AOSP x86 환경하여 여러 라이브러리를 빌드하면서 ndk-build를 통해 수정했던 Android.mk 재수정

안드로이드의 빌드시스템을 제대로 이해하고 시작한 작업이 아니였기때문에 꽤 삽질을 했는데, AOSP의 build/core/* 스크립트 및 ndk-build의 ndk/build/core/* 스크립트 분석 및 다음 문서를 통해서 안드로이드 빌드 시스템을 좀 더 이해할 수 있었다.

http://web.guohuiwang.com/technical-notes/androidndk1 - Mastering Android NDK Build System - Part 1
- http://www.netmite.com/android/mydroid/2.0/build/core/build-system.html - Android Build System

특히 위 링크의 마지막 문서를 보면 1997년에 만들어진 Miller의 Recursive Make Considered Harmful 이라는 make에 대한 흥미로운 문서를 만날 수 있다. (2002년 2008년 개정판(?)을 pdf로 볼 수 있다)

FFmpeg

ffmpeg + android로 검색해보면 나오는 다음의 문서를 통해서 automake/autoconf + cross compile 방식을 써서 Android.mk를 만드는 방법을 어느정도 살펴볼 수 있다.

안드로이드 펍의 ffmpeg NDK 컴파일 방법 강좌 시리즈

http://www.androidpub.com/1645684
http://www.androidpub.com/1646144
http://www.androidpub.com/1646529
http://www.androidpub.com/1646540

그러나 이 강좌를 보면 알겠지만, 처음 보는 개발자라면 조금 당황할 수도 있는데, ffmpeg 프로젝트 자체가 고유의 빌드시스템을 가지고 있을 뿐만 아니라 유연성을 제공하기 위한 다양한 configure 옵션이 있으며, 여러가지 외부 라이브러리와 의존성이 있기때문에 컴파일하는 작업조차 상당히 까다로운 작업이다.

하지만 불행중 다행으로(?) 안드로이드용 FFmpeg을 보다 손쉽게 할 수 있는 방법이 있다. 공식 AOSP는 FFmpeg을 포함하지 않고 있으나 CyanogenMod 소스는 FFmpeg을 포함하고 있다. (반면 Android-x86 프로젝트 소스도 FFmpeg을 포함하고 있으나, 이 소스는 CyanogenMod에서 거의 그대로 가져온 소스였고, make파일도 불완전했다.) 그런데 CM13/CM14 소스는 이미 x86을 지원하고 있었지만 YASM에 관련된 수정을 해야 Android-x86 소스트리에서 정상적으로 컴파일이 된다. 즉, AOSP/CM 최신 빌드 스크립트는 이미 YASM을 지원하고 있기 때문에 CM소스에 들어있는 ffmpeg의 x86+YASM관련 fix가 필요 없다. YASM에 관련된 fix를 제거하고 x86_64에 대한 지원을 추가 수정 해주면 x86뿐만 아니라 x86_64 역시 컴파일이 잘 된다.

mpg123

Android용 mpg123는 검색해보면 몇가지를 찾을 수 있지만 대개 최신 mpg123이 아니고 x86도 지원하지 않는다. 기존에 있던 Android.mk + configure + Makefile을 바탕으로 Android.mk를 만들고 AOSP 소스트리에서 컴파일을 할 수 있었다.

일반적인 automake/autoconf 방식은 configure를 통해서 config.h를 생성시켜야 하는데 호스트는 x86_64이고 타겟을 arm용으로 빌드하는 cross compile 방식을 써야 한다. configure를 통한 cross compile은 대개 잘 지원하기는 하지만 이 방식의 각각의 라이브러리마다 약간씩 차이가 있으므로 configure.* 파일과 Makefile.*의 내용을 잘 살펴보면서 Android.mk를 작성해야 한다. 이 부분은 따로 설명하고 https://github.com/wkpark/mpg123에 올려두었다.

ndk-build

위에서 기술한 방식으로 x86_64로 빌드해서 성공하기는 하였지만, 이번에는 최신 스마트폰을 대응하기 위해서 arm64에 대해서 또 다시 빌드하려고 하니 또 AOSP트리를 별도로 컴파일 해도 하나 하는 고민에 빠졌다. 물론 이런 식으로 별도의 CPU마다 AOSP 소스 트리를 따로 마련해도 되겠지만 이렇게 하는 것은 뭔가 낭비인 것 같아서 이번에는 ndk-build를 조금 고치고 AOSP식의 소스를 관리하면 편리할 것 같아 ndk-build 스크립트를 조금 고쳐보았다. (ndk-build의 장점은 무었보다도 APP_ABI := armeabi armeabi-v7a arm64-v8a x86 x86_64 라는 식으로 지정하여 각기 다른 CPU별 바이너리를 보다 쉽게(?) 빌드할 수 있다는 점일 것이다.)

ndk-build 빌드 방식이 AOSP 빌드시스템과 다르게 불편한 점은 바로 외부 라이브러리의 의존성 문제이다. 예를 들어서 FFmpeg을 빌드하기 위해서 외부 라이브러리 lame을 사용하는 경우에 lame 라이브러리에 대해서 import-module 방식을 쓰거나 ($(call import-module, external/lame)과 같은 줄을 Android.mk에 추가해 줌) 혹은 PREBUILT_SHARED_LIBRARY 방식을 써야 한다. 그러나 이는 AOSP식의 빌드시스템에 비교해서 여간 불편한게 아니다. 또한 import-module 방식을 쓰는 경우에는 이미 빌드한 외부 라이브러리가 다시 빌드되는 현상이 있었다(이는 ndk-build의 버그로 보인다. 그밖에, Android.mk를 고칠때마다 다시 빌드되는 현상도 버그로 보였다. NDK_OUT을 동일하게 지정해도 여전히 다시 빌드되는 현상은 마찬가지였다. 소스를 추적해보니 아니나다를까 해당 오브젝트 파일의 디펜던시에 Android.mk 및 Application.mk가 지정되어있었다. 이를 제거하면 Application.mk / Android.mk를 수정해도 재컴파일 되거나 하지 않았다. 만약 재컴파일 해야 하는 경우라면 -B 옵션을 넣어 ndk-build -B 라는 식으로 실행해야 한다.)

import-module을 사용하는 방식이 PREBUILT_SHARED_LIBRARY를 사용하는 것 보다 Android.mk를 덜 수정하는 방식이어서 더 나아보였지만 AOSP 빌드시스템과 비교해보면 너무도 불편한 것 이었다. 즉, AOSP 빌드 시스템의 경우 external 하위에 무수한 외부 라이브러리들의 의존성이 자동으로 판별되며, 이미 빌드된 외부 라이브러리를 그대로 재사용 하게 된다는 점이 ndk-build와 비교해서 가장 큰 차이점이었다.

그리하여 삽질끝에 ndk-build 스크립트의 다음과 같은 내용을 수정하였다.

  1. LOCAL_STATIC_LIBRARIES := liblame 을 넣으면 lame 외부 라이브러리가 이미 빌드된 것이 있는 경우 해당 모듈에 대한 스크립트 로컬 변수를 자동으로 할당하게끔 수정 : ndk-build의 경우 모든 LOCAL_MODULE 및 import 된 모듈에 대해서 __ndk_modules.*라는 내부 변수가 세팅되게 된다. import-module call은 단순히 해당 모듈의 Android.mk를 include하는 방식이였는데, import-module방식을 쓰지 않더라도 __ndk_modules.* 내부 변수가 자동으로 추가되게끔 수정하게끔 하니 import-module 라인을 추가하지 않아도 되었다. 이렇게 수정을 하니 이미 빌드된 외부 라이브러리를 아무런 문제 없이 재사용 할 수 있게 되었다.
  2. 롤리팝 이후에 AOSP 빌드 시스템의 경우 LOCAL_CFLAGS_x86_64, LOCAL_SRC_FILES_x86_64 같은 CPU arch 별 LOCAL 변수를 사용할 수 있다. ndk-build 스크립트도 조금 수정해서 arch별 LOCAL_* 변수를 사용할 수 있도록 하였고 잘 동작 하였다.
  3. AOSP 빌드 시스템의 경우 external/lame 외부 모듈에서 mm 명령을 실행하면 최상위 빌드 디렉토리로 옮겨간 후에 make -C $TOPDIR build/core/main.mk lame 식으로 외부 모듈을 컴파일 하고, 모든 INCLUDE 경로를 TOPDIR 상대 경로로 인식을 하게 된다. 그러나 ndk-build의 경우 make -C $TOPDIR이 아닌 make -C external/module_name 식으로 실행이 되어 모든 LOCAL_C_INCLUDES 경로가 현재 프로젝트 경로에 대한 상대 경로로 인식된다. ndk-build도 AOSP처럼 TOPDIR에 대한 상대경로를 인식하게끔 -C $TOPDIR 방식을 적용하게 스크립트를 고쳐봤는데 큰 문제 없이 잘 빌드 되었다. (단 이 경우 ndk-build 실행 스크립트를 조금 수정해야 했으며, Android.mk 및 Application.mk, NDK_PROJECT_PATH 경로를 직접 지정해 주어야 했다.)

이정도 수정을 하니 ndk-build 시스템을 AOSP 빌드시스템과 마찬가지로 외부 라이브러리 의존성에 대해서 덜 걱정하도록 해 주었고 쓸만해졌다.

이렇게 수정을 한 ndk-build를 통해서 arm64용으로 FFmpeg + lame + 기타 jni 소스등을 빌드해서 테스트하여 잘 실행이 됨을 확인하였다.

(※주의: arm64와 같이 64비트의 경우는 AOSP 롤리팝 이후부터 지원됨)

text relocations 문제

안드로이드 6.0 이후부터는 text relocations 문제가 있는 shared 라이브러리를 사용하는 경우 앱이 실행이 되지 않는다. arm64/x86_64에서는 이 문제가 없거나 해결하기 쉬운 편이나, 유독 x86 아키텍쳐에서는 text relocations 문제를 쉽게 해결하기 어려우며 이러한 문제가 발생하게 된다.

앱이 타겟 API가 22 이하로 빌드된 경우에는 경고만 뿌리고 실행이 정상적으로 되지만, 클론 리플레이어의 경우는 타겟 API가 23이며 text relocations 오류를 내며 앱이 실행조차 되지 않는다. 그래서 원래는 x86 아키텍쳐용으로 FFmpeg/mpg123 등등을 컴파일하고 지원하려고 했지만 text relocations 문제로 인해 x86을 당장 지원하기는 어렵게 되었고 x86_64 및 arm64 지원용 라이브러리를 우선적으로 테스트하게 되었던 것이다.

Text relocation 문제가 있는 라이브러리는 다음과 같았다.

  1. FFmpeg의 libavcodec / libswresample / libswscale(클론 리플레이어는 사용 안함) (libavutil, libavformat은 정상) https://trac.ffmpeg.org/ticket/4928 참고
  2. mpg123
  3. 기타 클론 리플레이어와는 무관하지만 구글링을 해보면 x264 등등의 라이브러리도 text relocation 문제가 있었으며 shared 라이브러리로 빌드시에 text relocation 경고를 보여주었다. (x264의 경우 구 버전은 text relocation 문제가 없었다가 AMD64 + i386 어셈블리어를 통합시키는 과정에서 text relocation 문제가 발생하는 것을 우연히 발견하였다. x264 개발자는 text relocation문제를 수정할 계획이 없다고 밝혔지만 정작 원래는 문제 없던 것이 새롭게 문제가 생겼던 것...) TEXTREL 문제는 readelf -d 명령을 통해 확인할 수 있다. (readelf -d 라이브러파일경로 | grep TEXTREL)
  4. 문제가 생기는 부분은 어셈블러로 최적화된 부분이다. FFmpeg의 경우 컴파일 옵션으로 YASM 어셈블러를 사용하지 않게 처리하면 TEXTRELs 문제가 발생하지 않는다. 다만 이 경우 성능저하가 있게 된다.


by dumpcookie 2017. 3. 1. 19:01

오랫동안 프로그래밍을 해본 사용자라 할지라도 어셈블리어가 필요하거나 리버스엔지니어링(역공학)이 필요한 경우는 별로 많지 않다. 본인도 90년대에 처음 GW 베이직을 시작으로 터보파스칼/터보C를 사용하며 프로그래밍의 기초를 배웠던 것이 그 시작이었지만 어셈블리어를 사용할 기회는 그다지 많지 않았다. 터보 파스칼의 그래픽 라이브러리를 사용하다가 마이크로소프트웨어 잡지책에 나와있던 원그리기/직선 그리기 알고리즘을 MASM 어셈블리어로 구현하고 이를 개선하려고 하면서 VGA 메모리 접근을 위해 주소를 어셈블리어로 직접 다루던 부분을 디버깅하던 기억이 아직도 남아있다. 당시 어셈블리어는 이해하기 어려웠고 고치기도 힘들었으나 최적화되고 나서 기대했던 속도가 나왔을 당시의 느꼈던 감격은 어셈블러의 단점을 보상하고도 남음이 있었다.

아무튼 지금 이 글을 쓰고있는 시점에서 조차도 본인은 어셈블리어에 대한 경험이 별로 없지만, 어셈블리어 혹은 리버스엔지니어링에 대한 기초적인 입문서도 많지 않다는 것에 조금 의아스럽게 생각하며, 어셈블리어에 완전히 생초짜라도 누구나 쉽게 따라해보면서 어셈블리어의 기초와 리버스엔지니어링을 같이 배워가며 문서를 쓸 예정이다.

C언어 기초 및 리눅스/유닉스에 어느정도 익숙한 분들을 대상으로 하지만 내용은 훨씬 쉽게 쓰려고 한다.

gcc와 objdump를 사용한 간단한 역공학

가장 먼저 초간단 C 프로그램을 만들어보자.

int main() {
return 0;
}

이를 a.c로 저장하고 gcc -c a.c 라고 하면 a.o가 얻어지며 a.o 오브젝트 파일을 objdump를 사용하여 간단히 역어셈블해보면 다음과 같다. (여기서는 -O1 컴파일 옵션을 주었으며, objdump -d 명령으로 디스어셈블을 하되 -Mintel 옵션으로 인텔 방식의 명령을 사용했다. gcc 버전은 5.4.0 / OS는 우분투 16.04.4)

$ gcc -c -O1 a.c
$ objdump -d -Mintel a.o

a.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <main>:
   0:   b8 00 00 00 00          mov    eax,0x0
   5:   c3                      ret

여기 처음으로 두개의 어셈블리어 명령이 보이는데, mov eax,0x0 명령은 eax 레지스터에 0x0을 옮기고(mov), ret 명령은 리턴하라는 것이다. (여기서는 eax레지스터를 처음으로 보게 되는데, 인텔의 16비트 레지스터는 ax,bx,cx,dx였던 것이 32비트로 넘어오면서 eax,ebx,ecx,edx로 확장되었고 ax,bx,cx,dx는 각각 8비트 레지스터 ah/al,bh/bl,ch/cl,dh/dl 등으로 구성된다. x86에서 지원하고 있는 레지스터에 대한 좀 더 자세한 정보는 위키피디아 https://en.wikipedia.org/wiki/X86#x86_registers 문서를 참고)

gcc에 최적화 옵션을 -O2로 주어서 컴파일한 후에 디스어셈블해보면 다음과 같다.

$ objdump -d -Mintel a.o

a.o:     file format elf64-x86-64


Disassembly of section .text.startup:

0000000000000000 <main>:
   0:   31 c0                   xor    eax,eax
   2:   c3                      ret

O2로 최적화를 하는 경우에는 오브젝트의 크기가 6바이트에서 3바이트로 줄어든 것을 볼 수 있는데, xor 명령을 사용하면 mov eax,0x0 명령이 5바이트인 것에 비해서 xor 명령은 2바이트밖에 안되면서 eax 레지스터의 내용을 지워서 0으로 만드는 동일한 작업을 수행하고 있다.

그렇다면 다음을 역어셈블해보면 어떻게 될까?

int main() {
return -1;
}

gcc -O2로 컴파일 한 후에 objdump -d -Mintel로 역어셈블 해보면 다음과 같다.

0000000000000000 <main>:
   0:   b8 ff ff ff ff          mov    eax,0xffffffff
   5:   c3                      ret

mov eax,0xffffffff 명령은 -1을 eax로 옮기는(mov)명령인데, -1는 32비트(4바이트)로 0xffffffff에 해당하며 mov eax, -1 명령과 똑같다.

NASM/YASM 소스 생성하기

이렇게 objdump를 이용해서 어셈블러 명령을 볼 수 있는 방법을 알게 되었지만 이와 같은 원리를 이용해서 컴파일 가능한 어셈블리어 소스를 만드는 것도 가능하다. (물론 몇가지 제한이 있다.) 다음 링크에서 찾아볼 수 있는 objconv를 사용하면 된다.

※ 다음 링크를 보면 gcc+objconv를 사용하여 nasm/yasm 소스를 만드는 방법을 볼 수 있는데, 이 내용을 참고하였다. http://stackoverflow.com/questions/35102193/how-to-generate-assembly-code-with-gcc-that-can-be-compiled-with-nasm

objconv 실행 파일은 다음 사이트를 통해 받을 수 있는데 리눅스에서 사용하려면 직접 컴파일 해야 한다. 소스 제공 및 다운로드: http://www.agner.org/optimize/ (x86/x86_64를 위한 최적화 자료모음이 함께 있다.)

이제 위에서 만든 초간단 소스 a.c을 gcc로 컴파일 하여 오브젝트 파일 a.o을 만든 후에 이것을 objconv를 통해서 NASM/YASM으로 컴파일 할 수 있는 asm 소스파일을 만들어보자.

이 경우 -fno-asynchronous-unwind-tables 옵션을 통해서 몇가지 디버깅 정보를 생성하지 않는 것이 편리하다. (gcc man 페이지를 살펴보면 -fasynchronous-unwind-tables 옵션은 찾을 수 있는데 이 옵션에 대한 해설은없다.  이 옵션은 디버거 혹은 가비지 콜렉터에서 사용할 수 있는 DWARF 2 형식의 해석 테이블(unwind table)을 만들지 않도록 한다.)

$ gcc -fno-asynchronous-unwind-tables -O2 -c a.c

다음 명령을 통해 a.o 오브젝트 파일을 objconv를 통해서 asm 소스 파일로 변환한다. (-fnasm 혹은 -fyasm 옵션을 써서 NASM/YASM 형식으로 출력한다.)

$ objconv -fnasm a.o

(이렇게 하면 a.asm 소스 파일을 얻는다. 출력 파일 이름을 별도로 지정하려면 objconv -fnasm a.o my.asm 라고 하면 my.asm 소스파일을 얻게 된다)

얻은 asm 소스 파일의 내용은 다음과 같다.

; Disassembly of file: a.o
; Wed Mar  1 7:00:34 2017
; Mode: 64 bits
; Syntax: YASM/NASM
; Instruction set: 8086, x64

default rel

global main: function


SECTION .text   align=1 execute                         ; section number 1, code


SECTION .data   align=1 noexecute                       ; section number 2, data


SECTION .bss    align=1 noexecute                       ; section number 3, bss


SECTION .text.unlikely align=1 execute                  ; section number 4, code


SECTION .text.startup align=16 execute                  ; section number 5, code

main:   ; Function begin
        xor     eax, eax                                ; 0000 _ 31. C0
        ret                                             ; 0002 _ C3
; main End of function

이렇게 얻어진 위 소스는 몇가지 오류를 바로잡아야 NASM/YASM 명령을 통해 컴파일 할 수 있는데, sed 명령을 통해 다음과 같이 필터링해야 한다. (위의 stackoverflow에 나와있는 것을 참고로 해서 조금 수정한 sed 명령은 다음과 같다)

$ sed -i "s/align=1 //g;s/[a-z]*execute//g;s/: *function//g;/default *rel/d;" orig.asm

혹은 다음과 같이 불필요한 부분을 지우는 대신에 주석처리해서 남길 수도 있다. (";" 기호 뒤의 내용은 주석으로 인식됨)

$ sed -i "s/\(align=1\) /;\1 /g;s/\([a-z]*execute\)/;\1/g;s/: \(function\)/ ; \1/g;/default *rel/d;" a.asm

(-i 옵션을 사용하지 않으면 콘솔 화면으로 출력된다. 이를 쉘스크립트로 만들거나 해서 좀 더 쉽게 써먹을 수 있을 것이다.)

이렇게 필터링 처리한 소스는 다음과 같이 된다.

; Disassembly of file: a.o
; Wed Mar  1 1 7:00:34 2017
; Mode: 64 bits
; Syntax: YASM/NASM
; Instruction set: 8086, x64


global main


SECTION .text                            ; section number 1, code


SECTION .data                          ; section number 2, data


SECTION .bss                           ; section number 3, bss


SECTION .text.unlikely                   ; section number 4, code


SECTION .text.startup align=16                   ; section number 5, code

main:   ; Function begin
        xor     eax, eax                                ; 0000 _ 31. C0
        ret                                             ; 0002 _ C3
; main End of function

이 소스는 비어있는 섹션을 지워서 다음과 같이 더 간단히 만들 수도 있다.

; Disassembly of file: a.o
; Wed Mar  1 7:00:34 2017
; Mode: 64 bits
; Syntax: YASM/NASM
; Instruction set: 8086, x64

global main ; function
SECTION .text.startup                                   ; section number 5, code
main:   ; Function begin
        xor     eax, eax                                ; 0000 _ 31. C0
        ret                                             ; 0002 _ C3
; main End of function

이것을 YASM/NASM을 통해 컴파일해서 오브젝트 파일을 얻고 실행파일을 얻으려면 다음과 같이 한다.

$ yasm -f elf64 a.asm gcc a.o -o a.out

(이 경우 얻어지는 a.o을 objdump -d 명령으로 보려고 하면 내용이 출력이 안되는데 이 경우에는 objdump -D 옵션으로 출력하면 된다. objdump --help에 의하면 -D, --disassemble-all 이라는 설명을 볼 수 있다.) 이를 실행해보면 다음과 같다. (리턴값이 0임을 확인할 수 있다)

$ ./a.out ; echo $? 0

Hello World!

그러면 이제 조금 더 그럴듯한 C프로그램을 nasm으로 변환시켜보자.

#include <stdio.h>

int main() {
    printf("Hello World!\n");
    return 0;
}

이를 gcc로 컴파일하고 objconv로 nasm 소스로 변환시키고 수동으로 정리하면 다음과 같다.

; Disassembly of file: c.o
; Mode: 64 bits
; Syntax: YASM/NASM
; Instruction set: 8086, x64
;
; manually simplified

default rel
global main
extern puts                                             ; near

SECTION .rodata.str1.1
?_001:                                                  ; byte
        db 48H, 65H, 6CH, 6CH, 6FH, 20H, 57H, 6FH       ; 0000 _ Hello Wo
        db 72H, 6CH, 64H, 21H, 00H                      ; 0008 _ rld!.

SECTION .text.unlikely
SECTION .text.startup align=16
main:   ; Function begin
        sub     rsp, 8                                  ; 0000 _ 48: 83. EC, 08
        mov     edi, ?_001                              ; 0004 _ BF, 00000000(d)
        call    puts                                    ; 0009 _ E8, 00000000(rel)
        xor     eax, eax                                ; 000E _ 31. C0
        add     rsp, 8                                  ; 0010 _ 48: 83. C4, 08
        ret                                             ; 0014 _ C3
; main End of function

이를 컴파일하고 실행시키면 정상적으로 실행됨을 확인할 수 있다.

위 소스에서 문자열이 저장된 부분을 다음과 같이 좀 더 정리할 수도 있다.

; Disassembly of file: c.o
; Mode: 64 bits
; Syntax: YASM/NASM
; Instruction set: 8086, x64
;
; manually simplified

default rel
global main
extern puts                                             ; near

SECTION .rodata.str1.1
msg:
        db "Hello World!", 00h

SECTION .text.unlikely
SECTION .text.startup align=16
main:   ; Function begin
        sub     rsp, 8                                  ; 0000 _ 48: 83. EC, 08
        mov     edi, msg                              ; 0004 _ BF, 00000000(d)
        call    puts                                    ; 0009 _ E8, 00000000(rel)
        xor     eax, eax                                ; 000E _ 31. C0
        add     rsp, 8                                  ; 0010 _ 48: 83. C4, 08
        ret                                             ; 0014 _ C3
; main End of function

clang의 출력과 비교

이번에는 clang을 이용하여 동일한 소스를 컴파일하고 역어셈블 해보자. 순서의 차이 및 그밖의 차이가 약간 있으나 다음과 같이 거의 동일한 결과를 얻을 수 있다. (소스를 약간 정리함)

$ clang -fno-asynchronous-unwind-tables -O2 -c c.c

; Disassembly of file: c.o
; Wed Mar  1 11:13:03 2017
; Mode: 64 bits
; Syntax: YASM/NASM
; Instruction set: 8086, x64

global main
extern puts                                             ; near

SECTION .text   align=16                         ; section number 1, code

main:   ; Function begin
        push    rax                                     ; 0000 _ 50
        mov     edi, ?_001                              ; 0001 _ BF, 00000000(d)
        call    puts                                    ; 0006 _ E8, 00000000(rel)
        xor     eax, eax                                ; 000B _ 31. C0
        pop     rcx                                     ; 000D _ 59
        ret                                             ; 000E _ C3
; main End of function

SECTION .rodata.str1.1                 ; section number 2, const

?_001:                                                  ; byte
        db 48H, 65H, 6CH, 6CH, 6FH, 20H, 57H, 6FH       ; 0000 _ Hello Wo
        db 72H, 6CH, 64H, 21H, 00H                      ; 0008 _ rld!.ob

objdump와 gdb 비교

objdump -d 명령을 사용하여 간단히 디스어셈블 할 수 있지만 gdb도 역시 가능하다. objdump를 사용하면 명령행으로 간단히 디스어셈블을 할 수 있는 반면 gdb를 사용하면 옵션을 조절해가며 볼 수 있는 등의 장점이 있다.

gdb를 사용하기 위해서 위의 가장 간단한 프로그램 a.c를 다음과 같이 컴파일하고 gdb로 로드해보자.

$ gcc -O2 -g -c a.c
$ gdb a.o
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a.o...done.
(gdb) _

gdb 파일명 명령을 내리면 파일이 실행파일/오브젝트 파일 등을 로드하고 (gdb) 프롬프트가 뜨고 명령을 기다린다.

이 상태에서 help 명령을 내리면 gdb에서 사용할 수 있는 몇가지 명령 목록이 나오는데, help all 등을 하면 모든 gdb 명령 목록을 보여주며, gdb 명령이 잘 생각이 나지 않는다면 탭키를 두어번 누르면 명령 목록이 주르륵 나온다.

우선 x86 사용자라면 NASM/YASM 스타일이 익숙할 것이므로 set disassembly-flavor intel로 인텔 스타일로 바꿔준다. 오브젝트 파일을 디스어셈블하려면 disassemble을 입력하고 탭을 몇번 치면 disassemble 명령을 통해 디스어셈블 가능한 함수 목록이 나온다. disassemble main라고 입력하면 objdump -d -Mintel 명령으로 디스어셈블 하듯 콘솔에 내용을 출력한다.

(gdb) disassemble (탭을 몇번 치면 다음과 같이 함수 목록이 나온다)
a.c   int   main (a.c 소스의 int main 함수)
(gdb) disassemble main
Dump of assembler code for function main:
   0x0000000000000000 <+0>:     xor    %eax,%eax
   0x0000000000000002 <+2>:     retq
End of assembler dump.
(gdb) set disassembly-flavor intel (인텔 스타일로 출력)
(gdb) disassemble main
Dump of assembler code for function main:
   0x0000000000000000 <+0>:     xor    eax,eax
   0x0000000000000002 <+2>:     ret
End of assembler dump.
(gdb)

a.c 소스를 -g 옵션을 넣어 디버깅 정보를 넣어주었으므로, gdb의 list 명령으로 소스를 같이 볼 수 있다.

(gdb) list
1       int main() {
2       return 0;
3       }
(gdb)

위에서 사용했던 set disassembly-flavor intel같은 옵션은 ~/.gdbinit 설정 파일에 저장해 두면 편리할 것이다. 즉 다음과 같은 내용을 .gdbinit 파일에 넣어둘 수 있다.

set disassembly-flavor intel
set history save on
set history size 1000
set history filename ~/.gdb_history

여기서는 gdb를 통해 간단히 디스어셈블을 하는 방법만 알아보았지만, 더 궁금한 사용자라면 gdb를 사용하려면 필수적인 몇가지 명령은 https://blogs.oracle.com/ksplice/entry/8_gdb_tricks_you_should 문서를 통해 볼 수 있다.

gdb의 사용법은 조금 복잡해보이지만 기본적인 사용법을 익히고 나면 어렵지만은 않다. 검색해보면 한글로 된 좋은 자료도 많으니 이를 참고할 수 있을 것이다.

※몇몇 참고문서

- Relocatable Global Data on x86 - http://nullprogram.com/blog/2016/12/23/

by dumpcookie 2017. 3. 1. 11:24

ndk-build는 의존성이 여러개인 외부 라이브러리를 손쉽게(?) 빌드하기 어렵다. 이 경우 ndk-build를 사용하는 대신에 AOSP를 소스 트리를 그대로 가져와서 arm_aosp-eng를 빌드한 후에 external/ 하위에 외부 라이브러리를 빌드하면 여러모로 편리하다. 또한 이렇게 하는 경우에 ndk-build와는 다르게 라이브러리 뿐만 아니라 apk 패키지도 같이 빌드할 수 있는 장점도 있다.

기존에는 AOSP 트리 대신에 CyanogenMod 킷캣 소스트리를 사용하고 있었는데 킷캣의 경우 arm64 및 x86_64를 지원하지 않아서 롤리팝 소스트리를 가져다가 빌드 환경을 재구성 하였다.

(AOSP 마쉬멜로우 트리의 경우 전체 빌드는 문제 없이 잘 되었으나, 이를 사용하려 하니 하위 호환성을 무시하고 과감하게 없애버린 몇몇 라이브러리 등등이 문제가 되어 롤리팝 소스트리를 선택하였다)

아무튼 이러한 이유로 AOSP 트리를 받아서 롤리팝을 다음과 같이 컴파일 하였다.

$ repo init -u https://android.googlesource.com/platform/manifest -b android-5.1.1_r38
$ repo sync
$ . build/envsetup.sh
$ lunch aosp_arm-eng
$ make -j4
...

보통은 이렇게 하면 아무런 문제 없이 전체 빌드가 되는데, 우분투 16.04 환경에서 빌드하다고 못보던 오류가 떴다.

해당 오류를 구글로 검색해보니 대략 다음과 같은 내용을 찾을 수 있었다.

http://stackoverflow.com/questions/36048358/building-android-from-sources-unsupported-reloc-43

https://android-review.googlesource.com/#/c/223100/

롤리팝부터는 clang을 host 바이너리 빌드하는 경우에 사용하게 되는데, 이 경우 clang은 자체적으로 내장된 as를 사용하는 대신에 별도의 gcc 툴체인의 as도 같이 사용하고 있다. 그런데 clang에 -B 옵션으로 툴체인의 경로를 지정하지 않는 경우, 툴체인의 as를 사용하는 대신에 host에 이미 설치된 as를 이용해 컴파일 된다. host의 as가 버전이 낮은 경우에는 별 문제가 되지 않는데 최신의 배포판을 사용하는 경우에는 host의 as 버전이 높고,  gcc 툴체인의 ld는 높은 버전으로 컴파일된 오브젝트의 relocation 타입을 인식하지 못하는 문제가 발생하는 것이다.

우분투 16.04를 사용하는 경우 host의 as 버전 (binutils 2.26.1)

$ as -v
GNU assembler version 2.26.1 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.26.1

툴체인의 as 버전 (gcc 4.6 + binutils 2.23.2)

$ prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.11-4.6/bin/x86_64-linux-as -v
GNU assembler version 2.23.2 (x86_64-linux) using BFD version (GNU Binutils) 2.23.2

위와 같이 툴체인의 as 버전이 host의 as 버전보다 낮다.

일단 위 링크에 써있듯이 -B 옵션을 build/core/clang/HOST_clang_common.mk에 추가하고 다시 컴파일 하였다. (stackoverflow 링크에 나와있듯이 롤리팝의 경우에는 다른 옵션을 건드리지 말고 패치를 수동으로 추가)

  -B$($(clang_2nd_arch_prefix)HOST_TOOLCHAIN_FOR_CLANG)/x86_64-linux/bin

주의해야 할 것은 이 경우 이미 컴파일 된 오브젝트 파일을 모두 지워줘야 한다는 점이다. 따라서 out/host/* 파일을 지워주고 make -j4 로 재빌드 한다.

by dumpcookie 2017. 2. 26. 21:25
| 1 2 3 4 5 6 7 ··· 22 |