최신목록

레이블이 linux인 게시물을 표시합니다. 모든 게시물 표시
레이블이 linux인 게시물을 표시합니다. 모든 게시물 표시

2018년 1월 17일 수요일

[GDB]strcpy break 가 안잡힐때(--no-builtin)

요즘 해공예(해킹 공격의 예술) 책을 보고 있다. 윈도우 개발자로 리눅스와 비교하는 재미가 쏠쏠하다. 몇번 펼쳤다가 덮기를 여러번 요즘 또 다시 보니 눈에 들어온다.

따라하다보니 shared library 함수인 strcpy에 break 를 걸었는데 책대로 되지 않았다.



break 1, 2, 3 를 차례로 찍고 실행시켰는데 break 1, 3만 걸리는걸 볼 수 있다.

소스코드를 디스어셈 해서봐도 printf는 보이는데 strcpy는 보이지 않는다.


구글신과 영접후 --no-builtin 옵션이 영향을 주고 있다는걸 알게되었다.
뭔가 간단한 함수들은 빌트인되어있는 내부 함수가 잇는것인듯...


break 잘 잡히네요. 디스어셈해서 봐도 strcpy가 잘 보이네요


이제야 좀 대화가 되는 바이너리가 됬군요...
근데 이게 컴파일러가 이렇게 빌트인된걸로 마음대로 컴파일 하면 나중에 디버깅할때 애좀 먹겠네요. 그래도 뭐 해커가 리버싱하는건 어려울수도 있고...뭐...익숙해지면 괸찮을라나요~

참고로 프로세스 뒤에 파라미터를 추가하려면
run 할때 뒤에 붙여주면 됨.
(gdb)run arg1 arg2

2017년 4월 28일 금요일

[linux][symbol]리눅스 바이너리 심볼 관련 옵션

윈도우즈는 debug/release가 명확한데 linux는 심볼이 일단 그냥 들어가있다. 음...
근데 또 심볼을 추가하는 옵션이 있긴한데 도대체 무슨 차이일까?

gcc compile

> gcc test.c -o nosym.out(기본적으로 심볼이 있다. 제한적인)

> gcc -s test.c -o strip.out(공용라이브러리 정보 외 심볼이 없다)

> gcc -g test.c -o sym.out(심볼이 모두 들어있다)

> gcc test.c
> strip a.out(기본심볼이 들어있었으나 심볼 제거)

위의 결과물이 아래와 같이 나왔다.


이제 차이를 좀 보자.

심볼이 보임
심볼이 없고 공유 라이브러리에 대한 정보정도는 보임
심볼이 보임

-g 를 붙이면 뭘 더 할수 있을까?
nosym.out을 디버깅을 시작해보자. 뭔가 부족함이 느껴지겠지 ㅎ


변수와 소스 등이 심볼테이블이 없다고 보이지 않는다.

sym.out을 디버깅해보자.
요차이군요 ㅎ 다보임~

2017년 4월 13일 목요일

[linux] process가 로드한 library 확인

윈도우에서는 process explorer라는 훌륭한 툴이 있는데
linux는 process explorer를 어떤 명령어로 대신할 수 있는지..
하나하나 알아가는 중이다. 막막하다 ㅎ

일단 공유 라이브러리에 대한 종속성은 ldd/readelf/objdump등을 통하여 확인이 쉬웠다.
하지만 동적라이브러리에 대한 확인은 되지 않았다.
그도 그럴것이 프로세스 실행후에야 디펜던시가 보일테니...
pid를 잡고 볼수 있는 뭔가가 있을거 같은데...빙고~! ㅋ

>pldd pid

위 명령어로 확인했다.

하지만 로드됬는지만 확인할 수 있을뿐 많은 정보가 있진 않다.
필요해지면 다시 찾아보자 ㅎ 일단 이걸로 만족 ~

2017년 4월 3일 월요일

[linux]core dump 생성 및 분석 방법

리눅스는 디버깅이 쉽지 않다. 오랫동안 윈도우 환경에서 개발을 해온 나는 참..답답하다..
크래쉬가 나고 segmentation fault (core dumped) 라는 메세지가 뜨는데..당췌 디버깅을 어떻게 해야하는지...로그파일로는 한계가 있다.

검색을 하다보니 core 파일을 생성하여 gdb로 디버깅이 가능하다 ㅎ 이런~ 좋은 방법이~
하지만 크래쉬가 났는데 core dumped라고 하는데 core파일이 없다...

코어파일 사이즈가 0인지 확인한다.(ulimit -a)


아래와 같이 코어 파일 사이즈를 변경합니다.



이제 크러쉬후에 core.xxxx라는 코어 파일이 생성되었음을 볼수 있습니다.

자 이제 core파일을 gdb로 분석해봅시다.
WinDbg와 분석 포인트는 유사해서 어렵진 않네요 깊이가 문제겠지만 ㅎ

#gdb 실행프로세스 코어파일 ->코어파일 분석시작
#bt -> call stack
#f n -> n frame으로 이동
#list -> 해당 스택의 소스 보여줌
#info locals -> 로컬 변수값 보여줌
#p val -> val 변수 값 보여줌
#x address -> 해당 주소의 값 보여줌