Why should I know this?

regs.rip = addr;[injected address] 0x400fb0 instead of expected SIGTRAP, target stopped with signal 11: Segmentation fault (gdb) x/10i 0x400fae [0x7f602fd0173c] [130037] │=> 0x400fae: add %al,(%rax) [0x7f602fd0173c] [150037] │ 0x400fb0: push %rsi [0x7f602fd0173c] [110037] │ 0x400fb1: push %rdx [0x7f602fd0173c] [140037] │ 0x400fb2: push %r9 [0x7f602fd0173c] [160038] │ 0x400fb4: mov %rdi,%r9 [0x7f..

만약 gcc를 사용하는 중에 의도치 않게 메모리 관련 에러가 발생한 경우, gcc에서 제공하는 스펙이나 표준 스펙에서 벗어난 코딩을 했을 경우가 높다.하지만 gcc가 내재한 버그일 가능성은 여전히 존재한다. gcc의 최적화는 각 단계가 독립적으로 진행되기 때문에 이전 단계에서 발생한 버그가 차후 스텝에 영향을 미쳐이를 디버깅하는게 절망적으로 어렵게 느껴지기도 한다. 이를 gcc 측에서도 인지하고 있기 때문인지 각 단계마다 결과물을 dump하여 확인할 수 있도록 제공하고 있다. gcc는 front-end에서는 tree라는 구조체를 메인으로 사용하며, front-end가 종료되는 시점에 tree를 rtl로 변환하여 back-end에 전달한다. -fdump-tree-all; gcc front-end의 각 스텝..

-fno-inline static으로 선언된 함수들은 소스코드 상에서는 함수로 존재하지만, 바이너리에는 inline 됨. 컴파일 시에 GCC 옵션으로 이를 방지하면 tracing하기 편해짐. (참고 링크 : stackoverflow )-fkeep-inline-functionsinline function 유지 옵션. -gdwarf-2 dwarf 2이상의 format을 사용. -fdump-tree-alltree 생성 과정을 모두 덤프하여 파일로 저장 -fdump-tree-all-detailstree 생성 과정에서 발생하는 모든 event를 함께 저장 -fdump-rtl-all최적화 과정을 모두 덤프하여 파일로 저장

GCC 컴파일 관련 정리. 소스코드 다운 : (mirror - locate at japan) wget http://ftp.tsukuba.wide.ad.jp/software/gcc/releases/gcc-7.3.0/gcc-7.3.0.tar.gz 의존성 라이브러리 설치 : ./contrib/download_prerequisites 빌드 환경 설치 : sudo apt install build-essential configure :gcc source가 있는 곳에서 ./configure 하지 말 것을 권하므로, 한 단계 올라간다.cd.. mkdir buildcd build../gcc-7.3.0/configure make -j6 custom option:configure할 때 CFLAGS 와 CXXFLAGS 지정...

2017 컨트리뷰톤을 참여하는 도중에 의도치않게 GCC가 가진 버그를 발견하게 되었고, 해당 버그에 대한 patch를 gcc에 리포트하게 되었다. https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01259.html gcc에 버그를 리포트하는 절차를 간단하게 소개하는 글을 적어놓고자 한다.(나중에 또 한참 검색하게 될 일이 없게끔.)

안드로이드 혹은 리눅스에서 디버깅을 탐지하는 방법 중에 TracerPid를 읽는 방법이 있는데, 이것은 커널 코드를 수정하여 우회할 수 있다.(참고 : https://die4taoam.tistory.com/15) 다른 방법으로 Shared Object를 injection하여 (참고 : https://die4taoam.tistory.com/11) API를 hooking하는 방법도 있다. Android에서 안티디버깅을 위한 쉬운 트릭으로 현재 프로세스에서 fork를 한 뒤에 프로세스의 상태 변화를 모니터링 하는 방법과 그것에 추가로 ptrace의 PTRACE_TRACEME 를 사용하여 디버거의 attach를 미연에 방지하는 방법이 있다. 이 두 방식 모두 굉장히 쉽게 우회가 가능하다. 방법은 간단한데, -...

TracerPid는 /proc를 통해 조회 가능한 정보로, gdb 등을 통해 해당 프로세스에 attach하고 있는 process의 pid를 기록하고 있다. kernel을 빌드할 때 아래처럼 일부 코드를 수정하면, tracerpid를 읽어 anti-debugging하려는 시도를 차단할 수 있다. ========================================출처 - https://gist.github.com/doughgle/e3a8c350dbf2370e69212f8b91fa4c88#file-gistfile1-txt-L17========================================commit acc0182c3d3869802bc20c8bf4e04c3464936bcc Author: Doug..

Linux Custom Packer 분석 libandroid.so 를 분석하기 위해 IDA에서 열려고 하면, out of memory를 에러 메시지 알림창을 띄우고 열지 못합니다. 이유는 libandroid.so의 ELF Header에 기록된 메모리 상의 크기보다 파일 크기가 작기 때문에, 부족한 부분을 찾지 못해 발생시키는 에러입니다. 마찬가지의 이유로 readelf와 objdump 모두 libandroid.so를 정상적으로 분석하지 못합니다. readelf 등의 도구를 통해 section 정보와 segment 정보를 확인하고, 실제 파일 사이즈를 확인해보면 크기 차이가 크다는 것을 알 수 있습니다. 이런 형식의 SO파일이 메모리에 로드되면 segment 정보에 따라 메모리는 할당되지만, 실제 파일에는..

# name git config --global user.name "HanbumPark" # email git config --global user.email "kese111@gmail.com" # commit with signed off git commit -s