최근의 일련의 x86 어셈블리어 관련 글은 클론 리플레이어상에서 x86을 지원하기 위해 할 수 있는게 무엇일까 하고 살펴보던 차에 썼던 것이다. 이런 저런 관련 정보를 찾아보고 테스트를 해보니, x86을 위해 빌드한 공유 라이브러리의 TEXTRELs 문제를 고치기 위해서는 MMX/SSE 등등의 지원을 위해 들어가있는 꽤 오래된 어셈블리어 소스를 고쳐야만 하는 문제였다.
https://sourceforge.net/p/mpg123/bugs/168/
소스를 살펴보다가 알게된 사실중 하나는, x264/ffmpeg/mplayer/libvpx 등등의 프로젝트에서 꽤 오래전에 누군가가 만들었던 소스를 서로 의도하지 않게(?) 공유하고 있었다는 사실이었다. 최초 누가 만들었는지 조차도 명확하지 않지만 그에 대한 언급이 소스에 있으며, 또 다른 것으로는, 어셈블리어로 있던 소스를 인라인 어셈블리로 바꾸면서 c 소스로 바뀐 경우, 혹은 그 반대로 c 소스를 어셈블러 소스로 변환시킨 후에 손으로 최적화 한 흔적들도 보였다.
아무튼 TEXTREL 문제를 고치기 위해 PIC 코드로 고쳐야 하는 부분은 많지 않았으나, 암호같던 어셈블리어가 조금씩 눈에 들어오니 고치는 것이 가능하겠다 싶어서 어셈블리어 공부(?)/테스트 및 삽질을 같이하여 TEXTREL 문제를 제거한 패치를 만들게 되었다.
패치는 https://github.com/wkpark/mpg123/tree/textrels 링크를 통해 받고 테스트해볼 수 있다.
일단 간단히 테스트를 해볼 수 있는 것이 mpg123 -t 명령을 통해서 입력 mp3를 받아 디코딩하여 -w foo.wav 옵션으로 WAV 파일로 디코딩된 파일을 들어보는 것이었다. 패치를 거듭 살펴보고 최종적으로 빌드후 실행해서 core 덤프가 나면 어디가 문제인지 gdb로 몇차례 살펴보고, 더이상 core dump 안되고 실행이 된 후 디코딩된 wav파일이 정상적으로 소리가 들렸으며, readelf -d 명령을 통해서 TEXTREL이 더이상 보이지 않는 것을 확인하였다.
$ readelf -d src/libmpg123/.libs/libmpg123.so Dynamic section at offset 0x56e20 contains 27 entries: Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [libm.so.6] 0x00000001 (NEEDED) Shared library: [libdl.so.2] 0x00000001 (NEEDED) Shared library: [libc.so.6] 0x0000000e (SONAME) Library soname: [libmpg123.so.0] 0x0000000c (INIT) 0x2f08 0x0000000d (FINI) 0x441b4 0x00000019 (INIT_ARRAY) 0x57a74 0x0000001b (INIT_ARRAYSZ) 4 (bytes) 0x0000001a (FINI_ARRAY) 0x57a78 0x0000001c (FINI_ARRAYSZ) 4 (bytes) 0x6ffffef5 (GNU_HASH) 0x138 0x00000005 (STRTAB) 0x1160 0x00000006 (SYMTAB) 0x5f0 0x0000000a (STRSZ) 2954 (bytes) 0x0000000b (SYMENT) 16 (bytes) 0x00000003 (PLTGOT) 0x58000 0x00000002 (PLTRELSZ) 848 (bytes) 0x00000014 (PLTREL) REL 0x00000017 (JMPREL) 0x2bb8 0x00000011 (REL) 0x1f48 0x00000012 (RELSZ) 3184 (bytes) 0x00000013 (RELENT) 8 (bytes) 0x6ffffffe (VERNEED) 0x1e58 0x6fffffff (VERNEEDNUM) 3 0x6ffffff0 (VERSYM) 0x1cea 0x6ffffffa (RELCOUNT) 392 0x00000000 (NULL) 0x0 $ readelf -d src/libmpg123/.libs/libmpg123.so |grep TEXT $
이렇게 빌드된 mpg123 라이브러리를 클론 리플레이어에 x86 jni 라이브러리로 넣고 x86/x86_64 AOSP+vmware에서 테스트해보니, 전에는 TEXTRELs 문제로 정지되던 것이 이제는 실행이 잘 되었다.
이 패치는 mpg123 sourceforge 사이트에 보고하였으며, 몇번의 피드백과 테스트를 통해 MMX/3DNow/3dnowext/SSE 디코더를 모두 지원하게 되었으며, 고친 소스는 위에서 언급한 github 사이트를 통해 확인할 수 있다.
| x86 어셈블리어 배우기 - Text relocation 문제 재현 및 수정. (0) | 2017.03.11 |
|---|---|
| x86 공유 라이브러리의 TEXTRELS 오류 찾기 (0) | 2017.03.10 |
X86 32비트 어셈블리어 소스코드 예제를 통해서 TEXTREL 문제를 확인해보고, 이를 TEXTREL 문제 없는 어셈블리어 소스를 만들어보자. 먼저 다음과 같은 간단한 소스코드 예제를 보자.
#include <stdio.h>
int main() {
puts("Hello World\n");
return 0;
}
이 소스를 clang으로 컴파일하고, objconv를 통해 NASM/YASM 소스코드로 변환시켜 조금 정리하면 다음과 같다. (clang -m32 -O2 -c 옵션으로 컴파일)
global main: function
extern puts
SECTION .text
main:
sub esp, 12
mov dword [esp], .str
call puts
xor eax, eax
add esp, 12
ret
; main End of function
SECTION .data
.str:
db "Hello World", 0xa, 0x0
스택 조작하는 부분을 더 간단히 고쳐보면 다음과 같다.
global main: function
extern puts
SECTION .text
main:
mov eax, .str
push eax
call puts
add esp, 4
xor eax, eax
ret
SECTION .data
.str:
db "Hello World", 0xa, 0x0
이를 my.asm로 저장하고 yasm -fnasm my.asm으로 컴파일 후에 gcc -m32 my.o 명령으로 링크를 하면 실행이 잘 됨을 확인할 수 있다
인라인 어셈블리에 익숙해지려면 AT&T 스타일의 어셈블리어도 알아할 것이므로 -S 옵션으로 어셈블리어 소스를 얻고, 이를 정리해보면 다음과 같다.
.text
.globl main
.align 16
main:
movl $.str, %eax
push %eax
calll puts
addl $4, %esp
xorl %eax, %eax
retl
.section .data
.align 16
.str:
.asciz "Hello World"
일대일 대응이므로 이해하는데 어렵지 않을 것이다. 이 소스는 my2.s로 저장한 후에 gcc -m32 my2.s로 컴파일하면 실행이 잘 됨을 확인할 수 있다.
이렇게 얻어진 어셈블리어 소스를 오브젝트 파일로 만든 후에 공유 라이브러리를 만들면 어떻게 될까?
다음과 같은 명령으로 공유라이브러리를 얻을 수 있으며, TEXREL 문제 역시 확인할 수 있다.
$ gcc -Wl,--warn-shared-textrel -m32 -shared -Wl,-soname,my2.so -o /tmp/my2.so my.o /usr/bin/ld: my.o: warning: relocation in readonly section `.text' /usr/bin/ld: warning: creating a DT_TEXTREL in a shared object.
그렇다면 이와 같은 문제의 어셈블리어 소스의 TEXTREL 문제를 어떻게 해결할 수 있을까?
우선 objdump -r 명령을 통해 리로케이션 정보를 살펴보자. (readelf -r 명령과 거의 동일)
$ objdump -r my.o my.o: file format elf32-i386 RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 00000001 R_386_32 .data 00000007 R_386_PC32 puts
puts 함수의 리로케이션 정보를 고치기 위해서는 NASM의 경우 메뉴얼에 나온것처럼 다음과 같이 고치면 함수의 리로케이션 문제가 해결된다. 즉 함수 호출을 call puts로 하는 대신에 call puts wrt ..plt라고 해준다.
global main: function
extern puts
SECTION .text
main:
mov eax, .str
push eax
call puts wrt ..plt
add esp, 4
xor eax, eax
ret
SECTION .data
.str:
db "Hello World", 0xa, 0x0
이렇게 고친 후에 yasm -f elf my.asm으로 컴파일하고, objdump -r 명령으로 확인해보면 뭔가 달라졌음을 확인할 수 있다.
$ objdump -r my.o my.o: file format elf32-i386 RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 00000001 R_386_32 .data 00000007 R_386_PLT32 puts
즉, 리로케이션 테이블에 있는 puts 엔트리의 오프셋은 전혀 변화가 없는데, 리로케이션 타입이 R_386_PLT32로 바뀌었으며, 함수 puts에 대한 리로케이션 문제는 수정된 것이다.
AT&T 스타일의 소스의 경우는 다음과 같은 식으로 고쳐야 한다.
.text
.globl main
.align 16
main:
movl $.str, %eax
push %eax
calll puts@PLT
addl $4, %esp
xorl %eax, %eax
retl
.section .data
.align 16
.str:
.asciz "Hello World"
YASM/NASM에서는 조금 헷갈리게 만드는 wrt ..plt라는 지시자를 썼지만, AT&T 스타일에서는 왠지 한결 쉬운듯한 @PLT를 사용하고 있다. 이 경우 역시 gcc -m32 -c 명령으로 컴파일한 후에 gcc로 공유 라이브러리를 생성시켜보면 여전히 TEXTREL문제가 남아있음을 확인할 수 있는데, 이는 함수에 대한 리로케이션 뿐만 아니라, 데이터에 대한 리로케이션 정보도 바꿔줘야 하기 때문이다.
어셈블리어 소스는 @PLT 지시자를 통해서 고쳤으나, objdump -d를 통해서 바이너리 코드를 살펴보면 바뀌기 전 코드와 완전히 일치한다. @PLT같은 지시자는 리로케이션 테이블의 정보를 바꿔주는 역할을 할 뿐, 실제 실행 코드 (.text 섹션내 실행 코드) 자체는 변화가 없다.
리로케이션 테이블을 readelf -r 명령을 통해서 보면 다음과 같다.
$ readelf -r my.o Relocation section '.rel.text' at offset 0x54 contains 2 entries: Offset Info Type Sym.Value Sym. Name 00000001 00000201 R_386_32 00000000 .data 00000007 00000604 R_386_PLT32 00000000 puts
오브젝트 파일을 xxd로 덤프해서 바이너리 파일을 비교해보면 다음과 같은 차이가 있는 것을 볼 수 있다. (아래쪽 변경점은 소스파일의 파일 이름이 fa.asm 에서 fb.asm으로 변한 정보)
--- a 2017-03-10 18:54:40.016601488 +0900 +++ b 2017-03-10 18:54:43.364574036 +0900 @@ -4,11 +4,11 @@ 00000030: 0700 0100 0000 0000 0000 0000 0000 0000 ................ 00000040: b800 0000 0050 e8fc ffff ff83 c404 31c0 .....P........1. 00000050: c300 0000 0100 0000 0102 0000 0700 0000 ................ -00000060: 0406 0000 4865 6c6c 6f20 576f 726c 6421 ....Hello World! +00000060: 0206 0000 4865 6c6c 6f20 576f 726c 6421 ....Hello World! 00000070: 0a00 0000 002e 7465 7874 002e 6461 7461 ......text..data 00000080: 002e 7265 6c2e 7465 7874 002e 7374 7274 ..rel.text..strt 00000090: 6162 002e 7379 6d74 6162 002e 7368 7374 ab..symtab..shst -000000a0: 7274 6162 0000 0000 0066 612e 6173 6d00 rtab.....fa.asm. +000000a0: 7274 6162 0000 0000 0066 622e 6173 6d00 rtab.....fb.asm. 000000b0: 6d61 696e 0070 7574 7300 0000 0000 0000 main.puts....... 000000c0: 0000 0000 0000 0000 0000 0000 0100 0000 ................ 000000d0: 0000 0000 0000 0000 0400 f1ff 0000 0000 ................
다음은 데이터 리로케이션 정보를 넣어줄 차례이다. 그런데 이 경우는 x86_32비트의 경우 문제가 약간 복잡한데, 이유는 차차 설명하기로 한다.
먼저 64비트의 경우를 살펴보자. hello world 프로그램을 clang -O2 -S 옵션으로 소스를 얻고 정리를 해보면 다음과 같다.
.text
.globl main
main:
movl $.str, %edi
callq puts
xorl %eax, %eax
retq
.section .rodata
.str:
.asciz "Hello World"
여기서 movl $.str, %edi 코드는 .str 문자열의 주소값($.str)을 %edi 레지스터에 넣으라는 것이다. 이 명령은 leal .str, %edi와 하는 일이 같다.
64비트의 경우에는 함수 호출 규약이 더 간단한데, 스택으로 호출 인자를 넘기는 것이 아니라 rdi, rsi 등의 레지스터를 통해 인자를 넘기고 있다. 따라서 push 혹은 pop을 통해 인자를 넘기지 않고 곧바로 edi, esi 레지스터를 수정하게 된다.
이 프로그램의 리로케이션 문제를 해결하려 하면 다음과 같이 바꿔주어야 한다.
.text
.globl main
main:
leal .str(%rip), %edi
callq puts@PLT
xorl %eax, %eax
retq
.section .rodata
.str:
.asciz "Hello World"
32비트에서처럼 함수의 경우에는 @PLT 지시자를 넣었으나, 데이터 섹션의 .str 주소를 넘기는 부분은 leal .str(%rip), %edi를 사용했다.
이것은 단순히 지시자를 사용한 것이 아니며, X86_64(AMD64)에서 새로 도입된 레지스터 %rip를 사용해서 .str 문자열 주소를 넘겨준 것이다.
AT&T의 문법이 헷갈릴 수 있으니 이에 대응하는 YASM/NASM 어셈블리어로 살펴보자.
default rel
global main
extern puts
SECTION .text
main:
lea edi, [rel .str]
call puts wrt ..plt
xor eax, eax
ret
SECTION .rodata
.str:
db "Hello World"
default rel등등이 포함된 것을 제외하고는 32비트/64비트 프로그램 소스가 거의 같고, .str 문자열 주소를 넘겨주는 부분이 다른 것을 볼 수 있다.
문자열의 주소는 .str이며, .str의 주소의 내용은 [.str]인데, lea eax, [.str]이라고 쓰면 .str의 주소값을 넘겨주라는 것이다. (NASM/YASM에서 사용할 수 있는 몇몇 주소 지정 방식은 다음 링크를 통해서 볼 수 있다. https://www.tortall.net/projects/yasm/manual/html/nasm-effaddr.html#nasm-effaddr-riprel)
이렇게 문자열 .str의 주소를 넘겨주는 코드에 rel이라는 지시자를 넣으면 리로케이션 문제가 없는 오브젝트 파일이 생성된다. (NASM/YASM에서는 rip 레지스터를 직접 사용하면 오류가난다.) 이렇게 해서 생성된 코드의 바이트수도 조금 다르다는 것을 다음과 같이 확인할 수 있다.
$ objdump -d nopic.o ffa-nopic.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 <main>: 0: 8d 3c 25 00 00 00 00 lea 0x0,%edi 7: e8 00 00 00 00 callq c <main+0xc> c: 31 c0 xor %eax,%eax e: c3 retq $ objdump -d pic.o # 수정된 PIC 코드의 경우 ffa.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 <main>: 0: 8d 3d 00 00 00 00 lea 0x0(%rip),%edi # 6 <main+0x6> 6: e8 00 00 00 00 callq b <main+0xb> b: 31 c0 xor %eax,%eax d: c3 retq
함수와는 다르게, 데이터의 주소를 상대적 주소로 바꿔주기 위해서 명령 코드 자체가 조금 바뀐 것을 알 수 있는데, 64비트에서 데이터 주소를 상대적 주소로 바꿔주기 위해서 %rip 레지스터를 사용한다. %rip 레지스터는 X86_32에서는 %eip이며, 16비트 32비트의 경우 %eip 어드레스의 값을 손쉽게 불러오지 못하였으나, X86_64(AMD64)부터는 %rip를 불러서 상대적 주소를 쉽게 계산할 수 있게 된 것이다.
그렇다면 X86 32비트에서는 데이터의 상대주소를 어떻게 구할까?
콜팝은 콜라+팝콘의 뜻이 아니고, 32비트에서 %eip 레지스터의 값을 가져오는 트릭이다. call + pop을 통해 %eip 레지스터 값을 읽는 방식을 구현할 수 있다. 32비트에서도 명령 카운트 레지스터가 존재하지만, 이것은 직접 읽기가 불가능한 레지스터이다. 그런데 함수를 콜하게 되면 스택에 리턴할 주소를 저장한다는 사실을 알고 있다. 스택에 저장되는 리턴할 주소가 바로 명령 카운터 레지스터 %eip의 값인 셈이다. 또한, 리턴할 주소는 바로 다음 명령이 실행될 위치이며, 이 경우 local:주소의 값이 된다. 따라서 아래와 같이 하면 %ebx 레지스터에 local:의 실제 주소값이 저장될 것이다.
call local
local:
pop %ebx
pop 대신에 mov (esp), %ebx라고 해도 된다. 그렇다면 이렇게 얻어진 %ebx 값은 local:의 실제 메모리에 올라간 진짜 주소가 된다는 것인데, 그렇다면 데이터가 적재된 곳의 주소 위치는 어떻게 구하게 될까? 64비트에서 lea .str(%rip), %eax라고 하면 되었듯이, %rip 대신에 %eip가 저장된 위치인 %ebx를 사용하여 leal .str(%ebx), %eax 라고 하면 될 것 같은데, 실제로는 이런 메커니즘을 지원하지 않으며, 다음과 같은 조금 아리송한 코드가 실제 사용된다. 즉,
call local
local:
pop %ebx
leal .str(%ebx), %eax
라고 해야 하는 것이 아니라 다음과 같이 한다
call local
local:
pop %ebx
local2:
addl $_GLOBAL_OFFSET_TABLE_ + (local2 - local), %ebx
leal .str@GOTOFF(%ebx), %eax
알쏭달쏭한 이 코드를 gdb로 파헤쳐보면 내막을 알 수 있지만, 실제로 _GLOBAL_OFFSET_TABLE_ 이라는 주소의 값은 프로그램이 적재되기 이전까지 알 수 없는 값이고, 소스코드상의 _GLOBAL_OFFSET_TABLE_은 조금 다르게 해석 되어진다. (이 부분은 아래에서 살펴보겠다.) 소스를 컴파일해서 얻어진 오브젝트 파일은 $_GLOBAL_OFFSET_TABLE_값을 아직 알지 못하고, 최종 실행파일은 링커에 의해 해석되어진 후에 GLOBAL OFFSET TABLE이 만들어지게 되어 비로소 GLOBAL_OFFSET_TABLE을 알게 된다.
본인도 이 부분이 제대로 이해되지 않아서 어려워했으나, gdb를 통해 내막을 살펴보고서야 이해하게 되었다.
우선 다음의 소스코드를 살펴보자. 이것은 hello world 프로그램의 PIC 버전이다. clang -O2 -fPIC -m32 -S 옵션으로 컴파일해서 소스를 얻고 이를 정리한 것이다.
.text
.globl main
main:
call .tmp0
.tmp0:
popl %ebx
.tmp1:
addl $_GLOBAL_OFFSET_TABLE_+(.tmp1-.tmp0), %ebx
leal .str@GOTOFF(%ebx), %eax
movl $_GLOBAL_OFFSET_TABLE_, %ebx ; 디버그용 코드
movl $_GLOBAL_OFFSET_TABLE_, %ebx ; 디버그용 코드
push %eax
call puts@PLT
add $4, %esp
xorl %eax, %eax
retl
.section .rodata
.str:
.asciz "Hello World"
$_GLOBAL_OFFSET_TABLE값을 알기 위해서 중간에 디버그 코드를 넣었다. 이를 컴파일해서 오브젝트 파일 및 실행파일을 얻었다. 이를 objdump -d 명령으로 살펴보면 main 함수가 다음과 같다.
00000000 <main>: 0: e8 00 00 00 00 call 5 <.tmp0> 00000005 <.tmp0>: 5: 5b pop %ebx 00000006 <.tmp1>: 6: 81 c3 03 00 00 00 add $0x3,%ebx c: 8d 83 00 00 00 00 lea 0x0(%ebx),%eax 12: bb 01 00 00 00 mov $0x1,%ebx 17: bb 01 00 00 00 mov $0x1,%ebx 1c: 50 push %eax 1d: e8 fc ff ff ff call 1e <.tmp1+0x18> 22: 83 c4 04 add $0x4,%esp 25: 31 c0 xor %eax,%eax 27: c3 ret
위의 내용을 잘 살펴보면 $_GLOBAL_OFFSET_TABLE_ 값이 들어가야 할 자리가 $0x1 이라는 값이 들어있다. 또한, $_GLOBAL_OFFSET_TABLE_+(.tmp1-.tmp0)가 들어가야 할 자리는 두 주소의 차이 (.tmp1-.tmp0) 값이 1이므로 0x02이어야 할 것 같은데 이상하게 $0x03이 들어있다. 그러면 실행파일을 덤프해보면 어떤가 살펴보자.
...(생략) 0804840b <main>: 804840b: e8 00 00 00 00 call 8048410 <.tmp0> 08048410 <.tmp0>: 8048410: 5b pop %ebx 08048411 <.tmp1>: 8048411: 81 c3 f0 1b 00 00 add $0x1bf0,%ebx 8048417: 8d 83 c0 e4 ff ff lea -0x1b40(%ebx),%eax 804841d: bb e3 1b 00 00 mov $0x1be3,%ebx 8048422: bb de 1b 00 00 mov $0x1bde,%ebx 8048427: 50 push %eax 8048428: e8 b3 fe ff ff call 80482e0 <puts@plt> 804842d: 83 c4 04 add $0x4,%esp 8048430: 31 c0 xor %eax,%eax 8048432: c3 ret ...(생략) Disassembly of section .got.plt: 0804a000 <_GLOBAL_OFFSET_TABLE_>: 804a000: 14 9f adc $0x9f,%al 804a002: 04 08 add $0x8,%al
실행파일에서는 $_GLOBAL_OFFSET_TABLE_이 들어갈 위치의 값이 모두 다른 값으로 채워져 있으며, $_GLOBAL_OFFSET_TABLE_+(.tmp1-.tmp0) 값에는 $0x1bf0(7152)가 들어가고, $_GLOBAL_OFFSET_TABLE_값이 들어갈 줄 알았던 곳은 각각 $0x1be3(7139) , $0x1bde(7134) 값이 채워져 있다. 그리고 정작 _GLOBAL_OFFSET_TABLE_ 주소는 0x0804a000값이다.
실제로 상수인줄 알았던 소스코드상에 들어간 $_GLOBAL_OFFSET_TABLE_ 값은 링커에 의해 고정된 값으로 해석되는 것이 아니라 .data 섹션과의 오프셋값으로 해석되어지고 있는 것이다.
따라서 실제 GLOBAL_OFFSET_TABLE 즉 실행파일이 메모리에 올라갔을 때에 .data 세그먼트의 위치를 가리키는 값은 다음과 같이 계산되어진다.
GLOBAL_OFFSET_TABLE의 실제 위치 = 현재 실행 코드의 %eip + 현재 실행 코드와 GLOBAL_OFFSET_TABLE 주소와 오프셋(여기서는 $_GLOBAL_OFFSET_TABLE_)
아무튼 이 과정은 GNU as + GND ld의 합작 과정인 것인데, YASM/NASM에서는 이마져도 약간 다르게 보이지만 원리는 같다. 다음 코드는 YASM/NASM에서 GLOBAL_OFFSET_TABLE를 구하는 코드이다.
global main: function
extern puts
extern _GLOBAL_OFFSET_TABLE_ ; YASM/NASM에서는 이를 선언해주어야 한다.
SECTION .text
main:
call .get_got
.get_got:
pop ebx
.tmp:
add ebx, _GLOBAL_OFFSET_TABLE_ + .tmp - .get_got ; AT&T 스타일의 어셈블리어와 같은 방식
;add ebx, _GLOBAL_OFFSET_TABLE_ + $$ - .get_got wrt ..gotpc ; NASM/YASM 메뉴얼에 나와있는 방식.
lea eax, [.str + ebx wrt ..gotoff]
push eax
call puts wrt ..plt
add esp, 4
xor eax, eax
ret
SECTION .data
.str:
db "Hello World", 0xa, 0x0
이렇게 하여 이 소스를 컴파일하여 오브젝트 파일의 리로케이션 정보를 보면 다음과 같게 되며 TEXTRELs 문제가 없게 된다.
$ objdump -r test.o test.o: file format elf32-i386 RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 00000008 R_386_GOTPC _GLOBAL_OFFSET_TABLE_ 0000000e R_386_GOTOFF .data 00000014 R_386_PLT32 puts
※참고:
http://nullprogram.com/blog/2016/12/23/ - GLOBAL_OFFSET_TABLE 및 x86에서 리로케이션에 대한 설명이 되어있다.
| mpg123의 x86상에서 text relocation 문제해결 (0) | 2017.03.14 |
|---|---|
| x86 공유 라이브러리의 TEXTRELS 오류 찾기 (0) | 2017.03.10 |
지금에야 64비트를 주로 쓰는 환경이므로 x86 32비트 환경에서 Text relocation문제가 크게 문제될 만한 사항은 아니지만, 안드로이드 6.0 이후로는 x86/arm 32비트의 경우, TEXTREL 문제가 있는 공유 라이브러리를 사용하는 경우 아예 실행조차 되지 않기때문에 (API 23 이상으로 빌드된 APK의 경우는 실행 안됨) 이 문제를 정리 차원에서 적도록 하겠다.
예를 들어 x264 / mpg123 / FFmpeg 등등의 꽤 널리 알려진 오픈소스 프로젝트의 경우, x86 32비트로 컴파일을 하면 TEXTRELs 문제가 있게 된다. 문제있는 공유라이브러리는 어떻게 찾을 수 있을까?
먼저 TEXTRELs 문제가 있는 라이브러리는 readelf, scanelf 등을 사용하여 찾을 수 있다.
예를 들어 FFmpeg의 libavcodec.so는 TEXTRELs 문제가 있으며 다음과 scanelf -T 명령을 이용하면 다음과 같은 식의 매우 긴 출력을 한다.
https://wiki.gentoo.org/wiki/Hardened/Textrels_Guide 참고
$ scanelf -T libavcodec.so TYPE TEXTRELS FILE libavcodec.so: (memory/data?) [0x845599] in (optimized out: previous put_cavs_qpel8_h_mmxext) [0x845560] libavcodec.so: (memory/data?) [0x8455EB] in (optimized out: previous put_cavs_qpel8_h_mmxext) [0x845560] libavcodec.so: (memory/data?) [0x845669] in (optimized out: previous avg_cavs_qpel8_h_mmxext) [0x845630] libavcodec.so: (memory/data?) [0x8456BB] in (optimized out: previous avg_cavs_qpel8_h_mmxext) [0x845630] libavcodec.so: (memory/data?) [0x845771] in (optimized out: previous avg_cavs_qpel8or16_v1_mmxext) [0x845700] libavcodec.so: (memory/data?) [0x84577B] in (optimized out: previous avg_cavs_qpel8or16_v1_mmxext) [0x845700] libavcodec.so: (memory/data?) [0x8457A8] in (optimized out: previous avg_cavs_qpel8or16_v1_mmxext) [0x845700] libavcodec.so: (memory/data?) [0x8457C7] in (optimized out: previous avg_cavs_qpel8or16_v1_mmxext) [0x845700] libavcodec.so: (memory/data?) [0x8457D1] in (optimized out: previous avg_cavs_qpel8or16_v1_mmxext) [0x845700] libavcodec.so: (memory/data?) [0x8457FE] in (optimized out: previous avg_cavs_qpel8or16_v1_mmxext) [0x845700] libavcodec.so: (memory/data?) [0x84581D] in (optimized out: previous avg_cavs_qpel8or16_v1_mmxext) [0x845700] ....
공유 라이브러리는 이미 리로케이션이 되어서 구체적으로 어떤 오브젝트 파일의 오류가 있는지는 알 수 없으나 TEXTRELs 문제가 있는지 없는지 정도는 간단히 파악할 수 있다.
readelf -a 혹은 readelf -d 명령을 사용하면 다음과 같은 더욱 요약된 정보를 볼 수 있다. -d 옵션은 --dynamic 옵션과 같고, dynamic 섹션 정보를 보여준다. -a 옵션은 모든 정보를 출력한다.
$ readelf -d x86/libavcodec.so Dynamic section at offset 0xc3d81c contains 36 entries: Tag Type Name/Value 0x00000003 (PLTGOT) 0xc3eb58 0x00000002 (PLTRELSZ) 2328 (bytes) 0x00000017 (JMPREL) 0x57748 0x00000014 (PLTREL) REL 0x00000011 (REL) 0x20b90 0x00000012 (RELSZ) 224184 (bytes) 0x00000013 (RELENT) 8 (bytes) 0x6ffffffa (RELCOUNT) 27939 0x00000006 (SYMTAB) 0x158 0x0000000b (SYMENT) 16 (bytes) 0x00000005 (STRTAB) 0xba18 0x0000000a (STRSZ) 60344 (bytes) 0x00000004 (HASH) 0x1a5d0 0x00000001 (NEEDED) Shared library: [libavutil.so] 0x00000001 (NEEDED) Shared library: [libswresample.so] 0x00000001 (NEEDED) Shared library: [libz.so] 0x00000001 (NEEDED) Shared library: [libmp3lame.so] 0x00000001 (NEEDED) Shared library: [libstdc++.so] 0x00000001 (NEEDED) Shared library: [libm.so] 0x00000001 (NEEDED) Shared library: [libc.so] 0x00000001 (NEEDED) Shared library: [libdl.so] 0x0000000e (SONAME) Library soname: [libavcodec.so] 0x0000001a (FINI_ARRAY) 0xc3cf94 0x0000001c (FINI_ARRAYSZ) 8 (bytes) 0x00000019 (INIT_ARRAY) 0xc3e818 0x0000001b (INIT_ARRAYSZ) 4 (bytes) 0x00000016 (TEXTREL) 0x0 0x00000010 (SYMBOLIC) 0x0 0x0000001e (FLAGS) SYMBOLIC TEXTREL BIND_NOW 0x6ffffffb (FLAGS_1) Flags: NOW 0x6ffffff0 (VERSYM) 0x1f41c 0x6ffffffc (VERDEF) 0x20b34 0x6ffffffd (VERDEFNUM) 1 0x6ffffffe (VERNEED) 0x20b50 0x6fffffff (VERNEEDNUM) 2 0x00000000 (NULL) 0x0
여기서 0x00000016 (TEXTREL) 0x0에 해당하는 부분이 TEXTREL 문제가 있는 라이브러리라는 것을 보여준다.
scanelf 혹은 readelf를 통해서 TEXTRELs문제를 어느정도 파악했다고 하자. 그렇다면 구체적으로 어떤 소스가 TEXTRELs문제를 일으키는지는 어떻게 알 수 있을까?
우선 이 문제를 원본 소스가 있을때를 가정으로 한다면 의외로 어렵지 않게 찾아낼 수 있다.
x86 32비트 라이브러리 하나를 예로 들어보자. 여기서는 FFmpeg라이브러리를 골라보았다. FFmpeg 라이브러리를 32비트 x86용 공유 라이브러리 형태로 컴파일한 후에, 각각의 오브젝트 파일에 대해서 살펴보도록 하자.
readelf를 사용하면 공유라이브러리뿐만 아니라 오브젝트파일의 정보도 볼 수 있는데, 특히 strip되지 않는 오브젝트 파일의 경우에는 다음과 같은 정보를 볼 수 있다. FFmpeg 라이브러리의 avcodec 모듈 소스중에 하나인 gif.c를 컴파일해서 얻어진 오브젝트 파일에 대한 정보를 readelf -r 명령으로 보면 다음과 같다.
Relocation section '.rel.text.pick_palette_entry' at offset 0xe98c contains 5 entries: Offset Info Type Sym.Value Sym. Name 0000000c 00004102 R_386_PC32 00000000 __x86.get_pc_thunk.bx 00000012 0000420a R_386_GOTPC 00000000 _GLOBAL_OFFSET_TABLE_ 0000001f 00004303 R_386_GOT32 00000000 __stack_chk_guard 000000cb 00004303 R_386_GOT32 00000000 __stack_chk_guard 000000f4 00004402 R_386_PC32 00000000 __stack_chk_fail_local Relocation section '.rel.text.gif_encode_close' at offset 0xe9b4 contains 6 entries: Offset Info Type Sym.Value Sym. Name 00000003 00004102 R_386_PC32 00000000 __x86.get_pc_thunk.bx 00000009 0000420a R_386_GOTPC 00000000 _GLOBAL_OFFSET_TABLE_ 0000001f 00004504 R_386_PLT32 00000000 av_freep 0000002a 00004504 R_386_PLT32 00000000 av_freep 00000042 00004604 R_386_PLT32 00000000 av_frame_free 0000004a 00004504 R_386_PLT32 00000000 av_freep Relocation section '.rel.text.put_bits' at offset 0xe9e4 contains 4 entries: Offset Info Type Sym.Value Sym. Name 0000000a 00004102 R_386_PC32 00000000 __x86.get_pc_thunk.bx 00000010 0000420a R_386_GOTPC 00000000 _GLOBAL_OFFSET_TABLE_ 0000006a 00002a09 R_386_GOTOFF 00000000 .LC2 0000007a 00004704 R_386_PLT32 00000000 av_log ...(생략)
복잡해보이지만, 이 오브젝트 파일에는 그 심볼 타입이 R_386_PC32, R_386_GOTPC, R_386_GOTOFF, R_386_PLT32등등이 있다는 것 정도를 알 수 있다. c언어로 작성된 소스코드로 얻어진 오브젝트 파일은 (이 경우 -fPIC 옵션으로 컴파일 되어) TEXRELs문제가 없는 경우이다. 반면, x86에 최적화된 x86/fft.asm 어셈블리어 소스를 컴파일해서 얻은 오브젝트 파일의 경우에는 readelf -r 명령 출력이 다음과 같으며, 이 경우는 TEXTRELs 문제가 있는 경우이다.
$ readelf -r fft.o Relocation section '.rel.text' at offset 0x2db4 contains 273 entries: Offset Info Type Sym.Value Sym. Name 00000015 0000a201 R_386_32 00000000 .rodata 0000001e 0000a201 R_386_32 00000000 .rodata 0000003a 0000a201 R_386_32 00000000 .rodata 00000052 0000a201 R_386_32 00000000 .rodata 000000a6 0000a201 R_386_32 00000000 .rodata 000000db 0000a201 R_386_32 00000000 .rodata 000000e4 0000a201 R_386_32 00000000 .rodata 00000100 0000a201 R_386_32 00000000 .rodata 00000118 0000a201 R_386_32 00000000 .rodata 00000148 0000a201 R_386_32 00000000 .rodata 00000150 0000a201 R_386_32 00000000 .rodata 000001f1 0000a201 R_386_32 00000000 .rodata 00000232 0000a201 R_386_32 00000000 .rodata 0000023a 0000a201 R_386_32 00000000 .rodata 0000028a 0000a701 R_386_32 00000000 ff_cos_32 00000292 0000a701 R_386_32 00000000 ff_cos_32 00000393 0000a201 R_386_32 00000000 .rodata 000003d3 0000a201 R_386_32 00000000 .rodata 00000411 0000a201 R_386_32 00000000 .rodata ...(중략) 0000176c 0000a701 R_386_32 00000000 ff_cos_32 0000179e 0000a801 R_386_32 00000000 ff_cos_64 000017d0 0000a901 R_386_32 00000000 ff_cos_128 00001800 0000aa01 R_386_32 00000000 ff_cos_256 00001830 0000ab01 R_386_32 00000000 ff_cos_512 00001860 0000ac01 R_386_32 00000000 ff_cos_1024 00001890 0000ad01 R_386_32 00000000 ff_cos_2048 000018c0 0000ae01 R_386_32 00000000 ff_cos_4096 ...(생략)
위에서 나오는 ff_cos_* 심볼은 fft.asm 소스상에서 .data 섹션에 들어가는 여러 상수들이다. 이 데이터의 타입이 R_386_32라고 나오고 있다. 바로 이러한 경우에 TEXTREL문제가 나게 되는 것이다. 다른 형식의 타입(GOTOFF,GOTPC 등등)이 보이지를 않고 있다.
readelf뿐만 아니라, 오브젝트 파일에 대한 정보는 objdump를 사용해도 알 수 있는데 objdump -r 명령으로 fft.o 파일을 살펴보면 다음과 같고 readelf 명령의 결과와 거의 대동소이하다. (물론 이 경우 역시 strip되면 아무 정보도 나오지 않는다.)
$ objdump -r fft.o fft.o: file format elf32-i386 RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 00000015 R_386_32 .rodata 0000001e R_386_32 .rodata 0000003a R_386_32 .rodata 00000052 R_386_32 .rodata 000000a6 R_386_32 .rodata 000000db R_386_32 .rodata 000000e4 R_386_32 .rodata 00000100 R_386_32 .rodata 00000118 R_386_32 .rodata 00000148 R_386_32 .rodata 00000150 R_386_32 .rodata 000001f1 R_386_32 .rodata 00000232 R_386_32 .rodata 0000023a R_386_32 .rodata 0000028a R_386_32 ff_cos_32 00000292 R_386_32 ff_cos_32 00000393 R_386_32 .rodata 000003d3 R_386_32 .rodata 00000411 R_386_32 .rodata ...(생략)
이렇게만 봐서는 어셈블리어 소스 fft.asm으로 얻은 오브젝트 파일과, 일반 c언어 소스로 얻은 gif.o 오브젝트 파일의 차이점을 발견하기 어렵지만, fft.o는 TEXTRELs문제가 있고, gif.o는 이 문제가 없는 경우이다. 그렇다면 그것을 어떻게 판별할 수 있을까?
gcc의 다음 명령을 사용하면 x86 / 32비트 공유 라이브러리를 만들 수 있다. (내부적으로 ld 명령이 실행된다.)
gcc -m32 -shared -fPIC -Wl,-soname,libmy.so -o /tmp/libmy.so -lc foo.o bar.o
위 명령은 foo.o bar.o 오브젝트 파일을 공유라이브러리 libmy.so라는 이름으로 생성시키는 명령이다. (-m32 옵션은 32비트 옵션, -shared 옵션은 ld명령으로 공유라이브러리를 생성하라는 옵션. -o는 출력 파일 지정 옵션)
이 명령을 응용하면, gcc의 -Wl,--warn-shared-textrel옵션을 함께 써서 TEXTRELs 문제를 가지는 것으로 추측되는 오브젝트 파일을 검사할 수 있다.
예를 들어 위에서 예를 들어 사용했던 gif.o 오브젝트 파일을 단독적으로 사용해서 공유 라이브러리를 만드는 명령은 다음과 같다.
(공유 라이브러리 이름은 임의로 my.so라고 하였고, 출력은 /tmp/mygif.so,
$ gcc -Wl,--warn-shared-textrel -m32 -shared -Wl,-soname,my.so -o /tmp/my.so gif.o
이 명령을 실행하면 아무런 오류도 없이 /tmp/my.so 공유 라이브러리가 생성되며, readelf -d 명령으로 TEXTRELS 문제를 살펴봐도 아무 문제가 없다.
반면 fft.o 오브젝트 파일에 대해 동일한 방식으로 임시 공유라이브러리를 생성하면 어떻게 될까?
$ gcc -Wl,--warn-shared-textrel -m32 -shared -Wl,-soname,my2.so -o /tmp/my2.so fft.o fft.o: warning: relocation in readonly section `.text'
이 경우 위와 같은 오류가 나며 my2.so 공유 라이브러리가 생성되었고, readelf -d 명령으로 TEXTREL 문제를 살펴보면 다음과 같이 TEXTREL 오류가 있음을 알 수 있다.
$ readelf -d /tmp/my2.so |grep TEXT 0x00000016 (TEXTREL) 0x0
종종 공유라이브러리 생성이 안될 수도 있는데, 오브젝트 파일에 심볼을 발견할 수 없는 경우, 다른 오브젝트 파일이 필요한 경우가 그러한 경우이며, 이러한 오류 등으로 링크가 안되어 공유 라이브러리가 생성이 안될 수도 있지만 여전히 리로케이션 문제가 있다는 워닝은 볼 수 있다.
$ gcc -Wl,--warn-shared-textrel -m32 -shared -Wl,-soname,my2.so -o /tmp/my2.so /tmp/foo.o /usr/bin/ld: /tmp/foo.o: relocation R_386_GOTOFF against undefined symbol `print' can not be used when making a shared object /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status
| mpg123의 x86상에서 text relocation 문제해결 (0) | 2017.03.14 |
|---|---|
| x86 어셈블리어 배우기 - Text relocation 문제 재현 및 수정. (0) | 2017.03.11 |
지난번에는 간단한 C언어 예제를 objconv 및 nasm/yasm을 통해서 x86 어셈블리어로 변환하는 방식을 살펴본 바 있다. objconv 프로그램은 상당히 완성도가 높았으며, MASM 혹은 인텔 어셈블리어 문법에 익숙한 사용자에게 쓸만한 고급언어 -> x86 어셈블리어 변환 용도로 활용될 수 있을 것이고, 어셈블리어를 최적화하는 용도 혹은 기타 어셈블리어를 배우는 등의 활용을 할 수 있다는 점을 살펴 보았다. 이번에는 인라인 어셈블리어에 대해 살펴보려고 한다.
상당히 많은 수의 유명 라이브러리는 고급 언어로 작성되어있지만, 게중에 일부는 특정 CPU에 더욱 최적화되어 있는데, 최적화된 부분은 보통 어셈블리어를 통해 이루어지고 있다. 프로그램 소스 전체가 모두 어셈블리어로 작성된 경우는 거의 찾아보기 어렵고 보통은 해당 라이브러리의 일정 부분이 어셈블리어를 통해 최적화 된 형태이다. 또한 어셈블리어가 별도의 소스로 완전히 분리되어 있는 경우도 있지만, C언어(혹은 다른 고급 언어)와 어셈블리어를 섞어서 사용하는 경우가 상당수인데, C 소스에 어셈블리어를 섞어서 사용하는 기법을 인라인 어셈블리(Inline Assembly)라고 부른다.
gcc는 내장된 GAS(GNU Assembler) 어셈블러를 가지며, 이것이 기본으로 지원하는 어셈블리어는 다음과 같은 AT&T 스타일의 어셈블리어이다.
mov $0x05, %eax # 주석
이것은 16진수 0x5값을 eax 레지스터에 넣으라는 명령이다. 이 명령에 대응하는 인텔 어셈블리어 스타일은 다음과 같다.
mov eax, 0x05
인텔 스타일과 AT&T 스타일을 비교해보면, 이 경우에는 명령코드의 소스와 대상의 위치가 바뀌고, 레지스터를 구분하는 prefix가 %, 숫자를 구분시켜주는 prefix로 $를 붙이는 것이 다를 뿐 거의 다를바가 없다. 최신 gcc의 경우에는 인텔 스타일 및 AT&T 스타일 모두 사용하는 것이 가능하나, 전통적으로(?) AT&T 스타일로 인라인 에셈블리어를 사용한다. 이미 x86 어셈블리어에 익숙한 사용자라면 조금 헷갈릴 수는 있으나, 이하 예제에서 나올 인라인 에셈블리 스타일은 모두 AT&T 스타일임에 유의하자.)
이제 다음의 아주 간단한 인라인 어셈블러 예제를 살펴보자.
int main() {
int dst = 0;
__asm__ volatile (
"mov $100, %%eax\n\t"
"add $10, %%eax\n\t"
"mov %%eax, %0\n\t"
: "=m" (dst)
);
return dst;
}
소스를 보면 대충 예측할 수 있을 정도로 간단하지만, 이 간단한 인라인 어셈블리 프로그램이 하는 것은 다음과 같다.
1) 숫자 100을 %eax 레지스터에 넣고, 2) 숫자 10을 %eax 레지스터에 더하여 얻어진 것을 0번째 출력 인자 dst에 넣는다. 그러므로 dst값은 110이 될 것이고 main() 함수는 110을 리턴하게 된다. 위의 경우 어셈블리어를 세줄로 나누어 보기 좋게 하였으나, 다음과 같이 한줄로 넣는 것도 물론 가능하다.
"mov $100, %%eax\n\tadd $10, %%eax\n\tmov %%eax, %0\n\t"
그러나 이렇게 소스를 만들면 조금 보기 불편하므로 여러줄로 보통 나누어 쓴다. 또한 각 줄은 "\n\t" 문자 즉, 줄넘김(\n) 문자를 필수적으로 넣어주어야 하고, 여기에 탭(\t) 문자를 추가적으로 넣어주어서 gcc -S 옵션으로 컴파일 할 경우 얻을 수 있는 어셈블리어 소스에 들여쓰기가 되도록 해준다.
위 소스코드 예제를 test.c라는 이름으로 저장하고 이를 다음과 같은 명령으로 컴파일을 해서 어셈블러 소스코드 test.s를 얻어보면 다음과 같다. (실행 환경 우분투 16.04.4 / gcc 버전 5.4.0)
$ gcc -O2 -m32 -S test.c
.file "test.c"
.section .text.unlikely,"ax",@progbits
.LCOLDB0:
.section .text.startup,"ax",@progbits
.LHOTB0:
.p2align 4,,15
.globl main
.type main, @function
main:
.LFB0:
.cfi_startproc
leal 4(%esp), %ecx
.cfi_def_cfa 1, 0
andl $-16, %esp
pushl -4(%ecx)
pushl %ebp
.cfi_escape 0x10,0x5,0x2,0x75,0
movl %esp, %ebp
pushl %ecx
.cfi_escape 0xf,0x3,0x75,0x7c,0x6
subl $20, %esp
movl %gs:20, %eax
movl %eax, -12(%ebp)
xorl %eax, %eax
#APP
# 3 "test.c" 1
mov $100, %eax
add $10, %eax
mov %eax, -16(%ebp)
# 0 "" 2
#NO_APP
movl -12(%ebp), %edx
xorl %gs:20, %edx
movl -16(%ebp), %eax
jne .L5
addl $20, %esp
popl %ecx
.cfi_remember_state
.cfi_restore 1
.cfi_def_cfa 1, 0
popl %ebp
.cfi_restore 5
leal -4(%ecx), %esp
.cfi_def_cfa 4, 4
ret
.L5:
.cfi_restore_state
call __stack_chk_fail
.cfi_endproc
.LFE0:
.size main, .-main
.section .text.unlikely
.LCOLDE0:
.section .text.startup
.LHOTE0:
.ident "GCC: (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609"
.section .note.GNU-stack,"",@progbits
인라인 어셈블리 소스코드 예제는 10줄밖에 안되는데 어셈블리어로 변환시키니 58줄이나 되어버려 복잡해 보이는데, 잘 살펴보면 인라인 어셈블리어 부분은 다음과 같은 부분에 해당된다. 원본 인라인 어셈블리 소스가 3줄이었는데 이것이 gcc에 의해 변환해서 얻어진 어셈블리어 소스에서도 마찬가지로 3줄이다.
...(생략)
#APP
# 3 "test.c" 1
mov $100, %eax
add $10, %eax
mov %eax, -16(%ebp)
# 0 "" 2
#NO_APP
...(이하 생략)
gcc 대신에 clang을 사용하면 어떤 결과가 나올까? clang으로 변환해서 얻어진 어셈블리어 소스는 다음과 같다. 출력 소스를 최대한 간단히 보기 위해서 -O2 옵션을 주어 보았다. (clang 3.8.0)
$ clang -O2 -m32 -S test.c
.text
.file "test.c"
.globl main
.align 16, 0x90
.type main,@function
main: # @main
# BB#0:
pushl %eax
movl $0, (%esp)
#APP
movl $100, %eax
addl $10, %eax
movl %eax, (%esp)
#NO_APP
movl (%esp), %eax
popl %ecx
retl
.Lfunc_end0:
.size main, .Lfunc_end0-main
.ident "clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)"
.section ".note.GNU-stack","",@progbits
자세히 살펴보면 인라인 어셈블리 부분의 명령 코드가 조금 달라졌음도 엿볼 수 있는데, 원래의 명령 코드는 mov였는데 movl로 바뀌는 등의 차이점도 있음을 알 수 있다. (movl의 l suffix는 long (32비트) 오퍼랜드에 대응하는 mov OP임을 뜻한다. l 이외에 b, s, w, q, t등의 suffix가 올 수 있다. 좀 더 자세한 내용은 https://en.wikibooks.org/wiki/X86_Assembly/GAS_Syntax 문서를 참고할 수 있다.
아무튼 clang의 경우 그 결과물이 훨씬 간단하니 이에 간단한 설명을 달아보자면 다음과 같다.
.text .file "test.c" .globl main .align 16, 0x90 .type main,@function main: # @main # BB#0: pushl %eax # %eax 레지스터를 스택에 넣어 스택이 하나 쌓았다. 하나의 스택 공간 확보. movl $0, (%esp) # 스택 최상위 주소"(%esp)"에 0을 넣음. # 해당 스택위치 자리를 0으로 초기화 한 것은 지역 변수 dst를 0으로 초기화 한 것에 해당 #APP movl $100, %eax # %eax 레지스터에 100을 넣음. addl $10, %eax # %eax 레지스터에 10을 더함 movl %eax, (%esp) # %eax 레지스터의 내용을 "(%esp)" 스택 최상위 주소에 넣음. # 해당 위치는 0으로 초기화 되어있었음 #NO_APP movl (%esp), %eax # 스택 최상위 주소의 내용"(%esp)"을 %eax 레지스터에 넣음. popl %ecx # 최상위 스택을 비움. 하나 쌓여있던 스택을 버림. retl # main() 함수 리턴/종료. %eax 레지스터에 리턴값이 보존되어 있다. .Lfunc_end0: .size main, .Lfunc_end0-main .ident "clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)" .section ".note.GNU-stack","",@progbits
여기에 조금 더 부연설명을 추가하자면, 메인 함수가 시작하면서 pushl %eax를 실행하여 스택을 하나 늘리고 해당 스택을 0으로 초기화 하고 있는데, 이는 "int dst = 0;" 소스가 어셈블리어로 변환된 것에 해당한다. 즉, c 소스 main()함수에서 지정된 지역 저장소 "int dst"를 위해 스택을 하나 늘리고 이것을 0으로 초기화 한 것이다.
그런 다음에 이어지는 인라인 어셈블리 부분이 실행되고 나면 해당 지역 저장소 dst의 위치인 스택 값이 %eax 레지스터에 옮겨서 저장되는데, 메인함수 main()이 리턴하는 값은 %eax 레지스터에 최종적으로 전달된다.
(스택은 함수의 인자 전달 및 지역 변수의 용도 등등으로 활용되는데, push를 하면 스택이 쌓이며, 스택 레지스터 esp는 감소를 하게 되며, ebp 주소를 기준으로 [ebp + offset] 형태의 주소로 스택을 지정하여 사용하게 된다. 초보자는 조금 헷갈릴 수도 있지만 스택이 쌓이는 방향에 유의해야 하는데, 메모리 상위 주소가 아래쪽인 경우 스택이 위쪽으로 쌓이고, 상위 주소가 위쪽이면 스택은 아래 방향으로 쌓인다.)
얻어진 어셈블리어 소스를 gcc 명령으로 컴파일해서 실행파일을 얻을 수도 있고, 이러한 과정을 거치지 않고 곧바로 실행을 해도 마찬가지 결과를 얻게 된다.
$ clang -m32 -O2 test.c $ ./a.out ; echo $? 110 $혹은
$ clang -m32 -O2 test.s $ ./a.out ; echo $? 110 $
다시 처음으로 돌아가서 test.c 소스를 다음과 같이 조금 바꿔보자.
int main() {
int dst = 0;
__asm__ volatile (
"mov $100, %%eax\n\t"
"add $10, %%eax\n\t"
"mov %%eax, %0\n\t"
: "=r" (dst)
);
return dst;
}
즉, 출력을 지정하던 부분이 원래는 "=m" (dst) 였던 것을 "=r" (dst)로 바꾼 것인데, 여기서 "="는 출력을 뜻하고 "=m"는 메모리 유형의 출력을, "=r"은 레지스터 유형의 출력을 의미한다. 즉, 출력 유형이 메모리였던 것을 레지스터 유형으로 제한(Constraint)을 바꾼 것이다.
새로 바꾼 소스를 clang으로 다시 컴파일해서 얻은 어셈블러 소스는 다음과 같다. (소스파일 이름을 2.c로 저장해 clang -O2 -m32 -S 2.c 명령으로 컴파일 하였다.)
.text
.file "2.c"
.globl main
.align 16, 0x90
.type main,@function
main: # @main
# BB#0:
#APP
movl $100, %eax
addl $10, %eax
movl %eax, %eax
#NO_APP
retl
.Lfunc_end0:
.size main, .Lfunc_end0-main
.ident "clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)"
.section ".note.GNU-stack","",@progbits
와우! 어셈블리 소스가 매우 간단해졌다. 추가적으로 들어간 어셈블리어 소스가 전혀 없이 인라인 어셈블리 소스 단 3줄만 남아있다. 이 경우에는 gcc로 컴파일을 하더라도 대동소이한 결과물을 얻을 수 있었는데, 아래와 같았다. (add가 addl로 변환되는 등의 약간의 차이점이 있으나 이는 gcc/clang 컴파일러가 동일하게 해석한다.) gcc -O2 -m32 -S 2.c
...(생략)
.globl main
.type main, @function
main:
.LFB0:
.cfi_startproc
#APP
# 3 "2.c" 1
mov $100, %eax
add $10, %eax
mov %eax, %eax
# 0 "" 2
#NO_APP
ret
...(생략)
그러면 이번에도 간단한 다른 예제를 살펴보자.
int main() {
int src = 3;
int dst = 5;
__asm__ volatile (
"imul %1, %0"
: "=r" (dst) /* 출력 인자 지정 */
: "r" (src) /* 입력 인자 지정 */
);
return dst;
}
이번에는 3과 5를 곱하고(imul 정수 곱셈 OP) 그 결과를 dst로 저장하려는 것이다. 이번에는 출력 인자와 입력 인자가 각각 하나씩 이며, src와 dst 유형 모두 레지스터로 지정하였고, 컴파일러에서 각 레지스터를 자동으로 지정할 수 있도록 해 보았다.
$ gcc -m32 -O2 -S test2.c 명령으로 컴파일해서 test2.s 소스를 살펴보니 다음과 같이 조금 이상하다.
컴파일을 하고 얻어진 어셈블리 소스가 의도한 대로 얻어지지 않고 있다. src와 dst 모두 %eax로 동일하게 지정되어 버린 것이다. (gcc / clang 모두 동일하며 아래는 gcc의 출력 결과.)
...생략
main:
.LFB0:
.cfi_startproc
movl $3, %eax
#APP
# 4 "test2.c" 1
imul %eax, %eax
# 0 "" 2
#NO_APP
ret
...생략
그 이유는 출력 인자에 대한 제약 유형을 잘 못 지정했기 때문인 것인데, 출력 인자를 "=r" (dst)라고 하면 출력을 쓰기전용으로 지정하겠다는 뜻이기 때문이다. 의도대로 작동되려면 dst 값은 5이므로 읽기/쓰기가 모두 가능해야 한다. 따라서 출력 인자를 "=r"가 아닌 읽기/쓰기가 모두 가능한 변경자(Modifier) "+"를 써서 "+r"로 지정해야 한다. 즉, 소스를 조금 고쳐서 다음과 같이 해야 한다.
int main() { int src = 3; int dst = 5; __asm__ volatile ( "imul %1, %0" : "+r" (dst) /* 출력 인자를 읽기/쓰기 가능한 출력("+") 레지스터로 제한 */ : "r" (src) /* 입력 인자를 레지스터로 제한 */ ); return dst; }
이를 컴파일해서 소스코드를 얻으면 다음과 같다. (clang/gcc 모두 동일한 결과를 얻으며, 아래는 clang의 출력 결과)
...생략
main: # @main
# BB#0:
movl $3, %ecx
movl $5, %eax
#APP
imull %ecx, %eax
#NO_APP
retl
...생략
최종 확인하기 위해 컴파일 하고 실행을 하면 그 결과가 맞다는 것을 알 수 있다.
$ clang -m32 -O2 test2.c $ ./a.out ; echo $? 15
여기까지 인라인 어셈블리를 넣는 방식을 간단히 살펴보았는데, 정리해보면 인라인 어셈블리는 다음과 같은 형식으로 요약할 수 있다.
__asm__ volatile ( "인라인 어셈블리어 #1\n\t" "인라인 어셈블리어 #2\n\t" "인라인 어셈블리어 #3\n\t" "인라인 어셈블리어 #4" : 출력 인자1, 출력 인자 2, 출력 인자 3, : 입력 인자4, 입력 인자5, );
출력 인자의 유형을 "=r"라고 지정했을 경우 r은 레지스터 유형으로 제약(Constraint)을 하겠다는 것을 뜻하며, "+"는 읽기/쓰기 가능하게끔 제약 변경자(Constraint Modifier)를 걸어준다는 것을 뜻한다.
입출력 유형에 대한 제한/제약(Constraint)은 https://gcc.gnu.org/onlinedocs/gcc/Simple-Constraints.html 문서를 참고할 수 있으며,
추가적인 제약 변경자(Constraint Modifier)는 https://gcc.gnu.org/onlinedocs/gcc/Modifiers.html 문서를 통해 자세히 살펴볼 수 있다.
인라인 어셈블리에 대해 더 자세히 알고싶다면 다음 문서를 참고하길 바란다.
https://wiki.kldp.org/wiki.php/DocbookSgml/GCC_Inline_Assembly-KLDP
| 기타 케이블의 커패시턴스 효과 (4) | 2022.07.11 |
|---|---|
| x86 어셈블리어 배우기 - 리버스엔지니어링 기초 (0) | 2017.03.01 |
| 아멘 샬롬 (0) | 2015.04.21 |
| 아가페 프로토스 (1) | 2015.04.20 |
앱이 실행이 안된다는 보고가 있어서 이 문제를 살펴보았더니 인텔 CPU용 안드로이드 x86/x86_64에서 실행되지 않는 문제였다. 리포팅된 로그에 남아있는 오류는 대략 다음과 같았다.
java.lang.UnsatisfiedLinkError: dlopen failed: \ "/data/app-lib/org.dumpcookie.ringdroidclone-1/libffmpeg_jni.so" has unexpected e_machine: 40
특히 위 링크의 마지막 문서를 보면 1997년에 만들어진 Miller의 Recursive Make Considered Harmful 이라는 make에 대한 흥미로운 문서를 만날 수 있다. (2002년 2008년 개정판(?)을 pdf로 볼 수 있다)
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을 보다 손쉽게 할 수 있는 방법이 있다. 공식 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 역시 컴파일이 잘 된다.
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에 올려두었다.
위에서 기술한 방식으로 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 스크립트의 다음과 같은 내용을 수정하였다.
이정도 수정을 하니 ndk-build 시스템을 AOSP 빌드시스템과 마찬가지로 외부 라이브러리 의존성에 대해서 덜 걱정하도록 해 주었고 쓸만해졌다.
이렇게 수정을 한 ndk-build를 통해서 arm64용으로 FFmpeg + lame + 기타 jni 소스등을 빌드해서 테스트하여 잘 실행이 됨을 확인하였다.
(※주의: arm64와 같이 64비트의 경우는 AOSP 롤리팝 이후부터 지원됨)
안드로이드 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 문제가 있는 라이브러리는 다음과 같았다.
| 클론리플레이어 오디오 인코딩 변환 지원 (0) | 2015.04.24 |
|---|---|
| 구간반복 학습앱 소개 (20) | 2014.11.02 |
| ringdroid 클론 반복 학습기 (0) | 2014.09.12 |
오랫동안 프로그래밍을 해본 사용자라 할지라도 어셈블리어가 필요하거나 리버스엔지니어링(역공학)이 필요한 경우는 별로 많지 않다. 본인도 90년대에 처음 GW 베이직을 시작으로 터보파스칼/터보C를 사용하며 프로그래밍의 기초를 배웠던 것이 그 시작이었지만 어셈블리어를 사용할 기회는 그다지 많지 않았다. 터보 파스칼의 그래픽 라이브러리를 사용하다가 마이크로소프트웨어 잡지책에 나와있던 원그리기/직선 그리기 알고리즘을 MASM 어셈블리어로 구현하고 이를 개선하려고 하면서 VGA 메모리 접근을 위해 주소를 어셈블리어로 직접 다루던 부분을 디버깅하던 기억이 아직도 남아있다. 당시 어셈블리어는 이해하기 어려웠고 고치기도 힘들었으나 최적화되고 나서 기대했던 속도가 나왔을 당시의 느꼈던 감격은 어셈블러의 단점을 보상하고도 남음이 있었다.
아무튼 지금 이 글을 쓰고있는 시점에서 조차도 본인은 어셈블리어에 대한 경험이 별로 없지만, 어셈블리어 혹은 리버스엔지니어링에 대한 기초적인 입문서도 많지 않다는 것에 조금 의아스럽게 생각하며, 어셈블리어에 완전히 생초짜라도 누구나 쉽게 따라해보면서 어셈블리어의 기초와 리버스엔지니어링을 같이 배워가며 문서를 쓸 예정이다.
C언어 기초 및 리눅스/유닉스에 어느정도 익숙한 분들을 대상으로 하지만 내용은 훨씬 쉽게 쓰려고 한다.
가장 먼저 초간단 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 명령과 똑같다.
이렇게 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
그러면 이제 조금 더 그럴듯한 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 -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 -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/
| 기타 케이블의 커패시턴스 효과 (4) | 2022.07.11 |
|---|---|
| 인라인 어셈블리 기초 - x86 어셈블리어 예제를 통해서 배우기 (0) | 2017.03.05 |
| 아멘 샬롬 (0) | 2015.04.21 |
| 아가페 프로토스 (1) | 2015.04.20 |
RECENT COMMENT