반응형


<photo : skedonk on flickr>

"끓을 만큼 끓어야 밥이 되지, 생쌀이 재촉한다고 밥이 되나."

윤오영님의 수필 [방망이 깎던 노인] 에 나오는 구절입니다.
필수적인 과정을 거쳐야 제대로 된 결과가 나온다는 뜻이지요.


리버싱을 제대로 하려면 공부해야 할 내용이 무척 많다는 것을 잘 아실 것입니다.
우리는 리버싱 공부에 시간과 노력을 쏟아야 합니다.

하지만 조급한 마음이 사람을 초조하게 만들고 반복된 실패를 참을 수 없게 만드는 것 같습니다.
리버싱을 하다 보면 매 순간마다 (내가 알지 못하는) '벽'에 부딪힙니다.
이러한 '벽'을 도전 과제로 삼고 극복하는 과정에서 희열이 느껴집니다.
제 생각에는 이게 바로 리버싱의 본질이 아닐까 생각합니다.

잘 안 된다고 스트레스 받지 마세요.
리버싱은 원래 "잘 안 되는 속성"을 가지고 있습니다.
마음을 편안하게 먹고 차근차근 정보를 수집하세요.
성공할 때까지 계속 시도해보는 겁니다.
머리 아프면 쉬었다 하세요.
중요한 건 포기하지 말고 꾸준히 하는 것입니다.

마치 퍼즐 조각을 맞추는 것과 같습니다.
해결 방법은 분명히 있습니다.
노력과 시간을 투자한다면 결국에는 성공할 수 있습니다.

어찌 보면 모든 엔지니어링의 본질적인 속성이 이와 같다고 생각됩니다.
결국 시간을 투자하고 노력할 수록 실력이 늘어나는 이치는 똑 같은 것이니까요.

"시간과 노력을 투자한 만큼 정직하게 실력이 쌓여간다."

전 이 맛에 리버싱을 하나 봅니다.

여러분은 어떠신가요?


+---+


요즘 과도한 업무에 심신이 많이 지쳤답니다.
피곤하고, 스트레스 받고, 시간에 쫓기면 사람은 초심을 잃게 되지요.
제 스스로 초심을 되새기고 목표를 향해 끊임없이 나아가고자 다짐하며 글을 올려봅니다.

ReverseCore

반응형
반응형


<사진 출처 : UPack 제작자 dwing's homepage>


그 동안 총 5 회에 걸쳐서 UPack 의 PE Header 분석과 Debugging 에 대해서 연재를 하였습니다.

UPack 상세 분석 – PE Header 완전 정복 (1)
UPack 상세 분석 – PE Header 완전 정복 (2)
UPack 상세 분석 – PE Header 완전 정복 (3)
UPack 상세 분석 – PE Header 완전 정복 (4)
UPack 디버깅 - OEP 찾기


다른 Packer 도 많은데 굳이 이 UPack 에 이렇게 많은 공(?)을 들인 까닭은 제 개인적인 추억(경험) 때문입니다.

예전에 PE 공부를 마치고 PE File Format 에 자신 있던 그때에, 전혀 새로운 PE 세계가 있다는 걸 알려준 소중한 Packer 입니다. 또한 PE 스펙은 그냥 스펙일 뿐이고, 실제 구현은 PE Loader 개발자에 의해 좌우되기 때문에 OS 별로 실제 테스트를 해봐야 한다는 깨우침(?)을 주었습니다.

제 블로그를 방문하시는 여러분들께서도 저와 같은 경험과 느낌을 가져보시라는 뜻으로 UPack 을 상세히 소개하였습니다.

물론 UPack 에서 소개된 내용이 PE Header Patch 의 전부는 아닙니다.

하지만 제가 분명히 장담할 수 있는 것은 "UPack 을 정복한 사람에겐 앞으로 어떤 PE Header 변형이 나타나더라도 두렵지 않다." 는 것입니다. PE Header 에서 실제 사용되는 값들과 사용되지 않는 값들을 잘 숙지 하고 있다면 어떤 변형도 무리 없이 분석이 가능합니다. (제 경험입니다. ^^)

감사합니다.


ReverseCore


반응형
반응형

2009년 7월 7일부터 시작된 무차별 DDoS 공격으로 인하여 나라 전체가 큰 혼란에 빠져버렸습니다.

이번 DDoS 사이버 테러를 지켜보면서 풀리지 않는 3 가지 의혹(누가? 왜? 어떻게?) 에 대해서 제 나름의 생각을 정리해 보겠습니다.



#1. Who?


누가 이러한 사이버 공격을 감행하는 걸까요?


개인? 혹은 단체?

규모있는 단체일 가능성이 높습니다.

이에 대한 근거로는 DDoS 공격에 사용된 좀비 PC 가 수 만대에 이를 정도로 널리 악성코드를 감염시켰다는 점입니다.
통상적으로 이렇게 기존 AV 제품에 걸리지 않고 단기간에 널리 퍼지기 위한 조건은 아래와 같습니다.

  • 악성코드의 제작이 마치 상용 SW 제품과 같은 단계(기획, 개발, 테스트, 배포)를 거칩니다.
    => 버그 없이 잘 동작하는 악성코드가 만들어집니다.
  • 진단을 회피하기 위하여 AV 제품들에 대한 연구가 선행되어야 합니다.
    => 많은 테스트를 거쳐서 기존 AV 제품들에게 진단되지 않을때까지 소스를 고치고 또 고칩니다.
  • 빠른 시간내에 다양한 변종을 만들어 냅니다.
    => 시간이 지나면 AV 제품들이 진단을 하기 시작합니다.
         그때 바로 변종을 퍼뜨려 추가적인 공격을 시도합니다.

위 조건들을 모두 만족하기 위해서는 각 분야의 전문가 집단이 필요할 수 밖에 없습니다.


이와 같은 사이버 테러 단체의 특징을 한번 생각해 보죠.

이들은 2009.07.09 현재까지 총 3 회의 DDoS 공격을 무차별로 퍼붓고 있습니다.
만약 경찰에 잡히기라도 하는 날에는 인생이 그대로 끝장남에도 불구하고, 지속적으로 대담하게 공격을 반복하고 있습니다.

이 사이버 테러 단체는 한 마디로 대한민국 공권력은 안중에도 없습니다.
즉, 대한민국 공권력의 영향을 받지 않는 사람들일 가능성이 높습니다.

또한 정교한 악성코드를 기획/제작/테스트/배포하는 데에는 많은 리소스(인력, 자금)가 필요하기 때문에, 이들의 배후에는 든든한 후원세력이 있다고 생각해 볼 수 있겠습니다.



#2. Why?


도대체 그들은 왜 이런 공격을 하는 걸까요?
이 공격으로 뭘 원하는 거죠?

이번 DDoS 공격 의도를 정확히 알 수는 없지만, 아래와 같이 추정해 볼 수는 있습니다.

  • 사회 혼란을 노림
  • 대한민국의 전반적인 IT 인프라 테스트
    => 인터넷 의존도, 시스템 의존도, 대한민국의 사이버 안보 능력, DDoS 대처 능력 등
  • 자신들의 공격 실력 검증
    => 악성코드 제작/배포 능력, 역추적 방지 능력 등

아직까지도 의도가 불분명합니다.
저도 확신이 서지 않습니다. 아마도 위의 3 가지 모두를 노렸다고 밖에는 생각되지 않네요.

더군다나 하드디스크의 MBR 을 날리는 기능이 포함되었다고 하는데요, 기존의 돈을 노리는 악성코드들과는 차원이 틀립니다.
말 그대로 "사이버 테러" 입니다.

하지만 이번 DDoS 사이버 테러에 의해서 우리도 큰 교훈을 얻었습니다.

우리 나라 인터넷 환경은 DDoS 공격에 매우 취약하며, 맘 먹고 달려들면 중요 사이트를 다운시키는것은 일도 아니라는 것을 말이죠.

사실 http 프로토콜 자체가 DDoS 공격에 취약하도록 설계되었기 때문에, 이것은 비단 우리 나라만의 문제라고 볼 수 는 없습니다. 단, 사후 대응 능력은 분명 짚고 넘어가야 할 것입니다. 며칠째 반복되는 공격에 속수무책으로 당하고만 있다는 건 분명 문제가 있습니다.

대표적인 예로 중국에서는 오래전부터 군대 조직내에 사이버전을 수행할 수 있는 특수부대를 양성하고 있다고 합니다. 우리나라도 이번 기회에 그에 대한 대비를 철저히 해야 할 것입니다.
인터넷도 국가 기간망(도로, 통신, 기타)으로 볼 수 있으니까요. 충분히 적들의 공격대상이 될 수 있습니다.



#3. How?


엔지니어로써 가장 궁금했던 부분입니다.

도대체 어떻게 수 만대의 PC 가 악성코드에 감염되어 DDoS 공격을 위한 좀비 PC 가 되었을까요?
사용된 악성코드들을 살펴보니 그 중에 웜(자체 전파 기능을 가짐)은 없었는데 말이죠.

아직까지도 정부기관과 AV 업체들은 좀비 PC 가 어떤 경로를 통하여 감염이 되었는지 파악하지 못하고 있습니다.
(아예 감염 경로 파악이 불가능하다는 말도 나오고 있는 실정입니다.)

잠깐 기억을 되돌려서 예전에 세상을 떠들썩하게 했던 악성코드 사건들을 생각해 보겠습니다.

  • CIH 바이러스 - 감염된 시스템은 특정 날짜에 ROM BIOS 가 날라감
    => 각 AV 업체에서 사건 발생 1년 전에 이미 대응을 마쳤으며, 지속적으로 주의 경보를 하였습니다.
    => 문제는 사람들이 경보를 무시하고 최신 엔진으로 업데이트 하지 않아서 피해가 엄청났었죠.
  • 1.25 인터넷 대란 - Slammer 웜이 MS-SQL DB Server 의 보안 취약점을 공격하여 전세계 인터넷이 마비 되었습니다.
    => MS 에서 이미 사건 발생 6 개월 전에 보안 패치를 내려보냈으며,
        각 AV 업체 또한 Slammer 웜에 대한 진단 시그니처를 가지고 있었습니다.
    => 사람들이 윈도우 보안패치와 AV 최신엔진 업데이트를 소홀히 하였기 때문에 엄청난 피해가 발생하였습니다.


위 두 사례 모두 PC 사용자들이 윈도우 보안패치AV 최신엔진 업데이트만 했었어도 충분히 막을 수 있는 사건이었습니다.

전 이번 DDoS 사이버 테러에 사용된 악성코드들 또한 (과거와 같이) 기존의 보안 취약점을 이용한 것이라고 생각합니다.

제가 생각하는 감염 시나리오는 이렇습니다.

1) 해커가 사람들이 많이 접속하는 사이트(예:포탈, 관공서 등)를 해킹하여 특정 페이지를 변조하여 IFrame 을 심어둡니다.
2) 해당 페이지에 접속한 사람들은 자신도 모르게 IFrame 에 쓰여진 주소로 이동하여 IE 취약점을 통하여 악성 파일을 다운 받아 실행하게 됩니다.
3) 해커는 역추적을 방지하기 위해 일정 시간이 지나면 변조한 페이지를 원래대로 복원시킵니다.

외부로 전파하는 기능을 가진 웜(Worm)을 사용하지 않고 단기간내에 불특정 다수를 감염시키면서, 동시에 감염 경로를 숨기기 위해서는 위 방법이 가장 좋다고 봅니다.

기존 웜을 통한 악성코드 전파 방법은 다른 시스템에 전파하기 위해 네트워크 스캐닝(윈도우 보안 취약점 패킷 전송)을 하는데, 이런 흔적은 AV 업체의 주목을 끌어 사전에 걸릴 확률이 높습니다.

따라서 이번 DDoS 사이버 테러의 경우는 매우 설계가 잘 되어 있고, 효과가 좋다고 볼 수 있습니다.
(공격자들은 프로가 맞습니다.)

좀 더 위험한 추정을 하자면 공격자는 사이트 관리자 중 한명과 내통하고 있다고 볼 수 도 있습니다.
이건 제가 영화를 너무 좋아하는 관계로 너무 지나친 비약이라고 할 수 있지요.
하지만 자고로 최고의 해킹은 내부 해킹이라고 하였습니다. 절대 발각 될 수 없지요.



+-----+

위 얘기들은 모두 제 자신의 추정일 뿐이며 사실로 밝혀진게 아닙니다. ^^

참고만 하시기 바랍니다.

마지막으로 한 말씀 드리겠습니다.

좀비 PC 가 되지 않도록 윈도우 보안 업데이트와 AV 최신 엔진 업데이트를 철저히 하도록 해야 겠습니다.




반응형
반응형

#0. prologue

분야를 막론하고 기술자(특히 엔지니어)들은 자신만의 작업환경과 손에 익은 도구(장비)가 있습니다.

기술자(특히 엔지니어) 란 특정 업무를 위해서 필요한 도구를 아주 능숙하게 다룰 줄 아는 사람들입니다.

같은 도구를 사용하더라도 기술자의 능력에 따라서 전혀 다른 결과를 보여줍니다.
(더 나아가서 필요한 도구를 직접 만들어 내기도 합니다.)

또한 기술자들은 각자 자신만의 도구를 가지고 있으며
한번 손에 익힌 도구를 되도록 오래 쓰고 왠만해서는 바꾸려 하지 않습니다.
(바꿀 때도 될 수 있으면 같은 회사의 후속 제품으로 바꾸려고 하지요.)

남의 도구, 남의 작업환경에서 일을 하면 아무래도 불편하다고 생각합니다.

즉, 자신만의 작업환경과 자신만의 도구가 갖춰져야 그 기술자의 진정한 실력이 100% 발휘 된다고 할 수 있습니다.



#1. Reverse Code Engineer (Reverser)

리버서들은 어떨까요?

리버서도 역시 IT 엔지니어 범주에 들어가기 때문에 위에서 언급한 일반적인 기술자의 성향과 다를 바가 없습니다.

리버싱을 하기 위한 도구의 종류만도 수십 가지가 넘으며, 각 종류별로 다양한 제품들이 존재합니다.
또한 IT 분야의 특성상 계속해서 새로운 도구가 개발되고 있습니다.

도구의 종류만도 아래와 같이 매우 많습니다. (언급하지 못한 것도 많을 것입니다.)

disassembler
debugger - PE, script, etc
development tool - assembly, C/C++, etc
editor(viewer) - text, hex, resource, retistry, string, PE, etc
monitoring tool - process, file, registry, network, message, etc
memory dump
classifier
calculator - hex, binary
compare tool - text, hex
packer/unpacker
encoder/decoder
virtual machine
decompiler - VB, Delphi, etc
emulator
...



#2. 좋은 분석 도구 선택의 5 가지 기준

아래에 ReverseCore 만의 도구 선택 기준(가이드)을 제시합니다. (참고만 하세요~)


첫째, 도구 개수를 최소화시킨다.

남들이 쓴다고 해서 기능을 알지도 못하는 도구를 잔뜩 가지고 있어봐야 도움이 되지 않습니다.
자신에게 필요한 도구만을 각 종류별로 하나씩만 사용하는 것이 좋습니다.

자신의 실력에 맞는 것만을 고르고 차츰 하나씩 늘려나가시면 됩니다.

또한 중복된 기능의 도구들은 하나로 정리하는 것이 좋습니다.


둘째, 도구는 기능이 단순하고 사용방법이 편리한 것이 좋다.

실력이 늘어날 수록 사용해야 할 도구의 개수도 늘어납니다.
기능이 단순하고 인터페이스가 직관적일 수록 사용하기에 편리합니다.

여기서 기능이 단순하다는 말은 리버싱 도구치고는 단순하다는 말입니다.
(Windows 의 계산기, 메모장 수준을 생각하시면 안됩니다. ^^)

따라서 아무리 단순한 리버싱 도구를 하나 익히는 데만도 어느 정도 시간이 필요합니다.


셋째, 기능을 철저히 익힌다.

아무리 좋은 도구라도 사용할 줄 모르면 무용지물 입니다.

자신이 이미 가지고 있는 도구에서 제공되는 기능인데도,
그걸 알지 못하고 다른 도구를 찾는 분들이 많습니다.

일단 도구를 선택한 후에는 제공되는 메뉴얼을 한번 정독해보시는 것이 좋습니다.
자주 사용하는 기능의 단축키 정도는 외워 두시면 작업이 훨씬 수월합니다.
(단축키를 잘 쓰면 확실히 자타공인 전문가처럼 느껴집니다.)


넷째, 꾸준히 업데이트 한다.

리버싱도 IT 범주에 속하기 때문에 기술 발전 속도가 매우 빠릅니다.

새로운 기술에 대응하기 위해 도구들도 빠르게 변화하기 때문에
사용하는 도구의 업데이트는 매우 중요한 일입니다.

따라서 꾸준히 업데이트를 지원하는 도구를 선택하는 것이 좋습니다.


다섯째, 도구의 핵심 동작 원리를 이해한다.

도구를 더 잘 사용하기 위해서 동작 원리를 이해하는 것이 좋습니다.
더 나아가 테스트용 프로토타입을 만들 수 있다면 금상첨화 입니다.

이 부분을 간과하시는 분들이 매우 많습니다.
하지만 높은 수준의 리버싱 실력을 쌓기 위해서는 필수적인 사항입니다.

예를 들어 debugger 의 동작원리를 이해하고 있으면,
anti-debugging 기법을 잘 회피할 수 있습니다.

원리를 이해하지 못하고 도구에만 의존하면,
간단한 트릭도 해결하지 못하고 다른 도구를 찾아 나서야 합니다.
소위 말하는 "도구의 노예"가 되는 것이지요. (이것만은 꼭 경계해야 겠습니다.)



#3. epilogue

debug.exe 라는 프로그램을 아시나요?
MS-DOS 시절부터 존재하던 16-bit debugger 입니다. (XP 에도 존재합니다.)

커맨드 창에서 debug.exe 를 실행하고 '?' 명령으로 도움말을 보겠습니다.


위에 보이는 명령어가 전부입니다.

단순하지요?

제가 아는 어떤 분이 debug.exe 로 16 bit DOS 프로그램을 분석하시는 걸 본 적이 있습니다.

뭔가를 실행시키더니 키보드를 다다다다 두들기면서 화면이 번쩍 번쩍 넘어가는데,
바로 옆에서 지켜보면서도 무슨 작업을 하는지 도저히 알 수 없었습니다.
(눈이 그분의 작업 속도를 따라가지 못한 거죠.)

처음에는 실행되는 프로그램이 debug.exe 인지 조차도 몰랐었습니다.
(전 그때 당시 이미 debug.exe 를 한달 정도 써본 경험이 있었음에도 불구하고 말이죠.)

그리고는 다 됐다면서 결과를 넘겨 주시더군요.
그때 그분이 사용하신 프로그램이 debug.exe 라는 걸 알고 충격에 휩쌓였었죠.

'저 단순한 debug.exe 만으로 이 일을 이렇게 빨리 해냈단 말인가?' 하고 말이죠.

그 이후로 제가 어떤 도구를 고를 때 나름대로의 기준을 세우게 되었습니다.

그리고 하나의 깨달음을 얻었습니다.

"평범한 도구라도 극한까지 연마하면 천하에 다시 없는 비범한 도구가 된다."

마치 무림고수(武林高手)가 수련에 수련을 거듭해서 검(劍)을 버리고
결국에는 초(草)/목(木)/죽(竹)/석(石)을 모두 검처럼 사용할 수 있듯이 말이죠.


여러분은 어떻게 생각하시나요? ^^


반응형
반응형

요즘 Windows 어플리케이션을 개발할 때 Assembly 언어로 개발하시는 분들은 보기 드물죠.
보통은 C/C++, VB, Delphi 등의 4GL 로 개발을 하게 됩니다.

이렇게 만들어진 프로그램을 에디터로 열어보면 아래 그림과 같이
소스 코드는 보이지 않고 뭔가 이상한 기호들이 가득하지요.


<Fig. 1>

전 리버싱을 접하기 전에는 컴파일러와 링커가 소스 코드를 이상하게 변화시키기 때문에
그 내용을 아무도 이해 할 수 없을꺼라고 생각했었습니다.

더 정확히는 그 내용을 이해할 수 있는 사람은 몇명 되지 않을꺼라 생각했던 거지요.
컴파일러는 사람이 보기 편한 소스코드를 CPU 가 이해할 수 있는 이진 코드로 바꿔놓고,
링커는 OS 에서 실행이 가능한 형태로 파일을 재구성하는 것 뿐이기 때문에,
이진 코드를 이해할 수 있는 리버서가 봤을때는 그 파일의 내부구조가 훤히 보이게 되는 것입니다.

즉, 극소수(?)의 사람들에게는 소스코드가 그대로 노출된다고 봐야겠지요.
이것이 리버스 엔지니어링의 묘미이기도 하구요.

세상 모든 이치가 그렇듯이 모를 때는 어려워 보이지만, 일단 알고나면 쉬워집니다.
4GL 개발자가 리버스 엔지니어링을 몰랐을때는 뭔가 대단히 어려워 보이고,
자기가 할 수 없을것 같지만 사실 알고보면 쉽습니다.
(그 중에 더 열심히 한 사람은 물론 더 잘하겠지요.)

알.고.보.면. 이라는 말이 상당히 많은 내용을 함축하고 있어서 처음에 좀 힘든것 뿐입니다.
앞으로 올리게 될 'analysis' 포스트들을 보시고 직접 따라해 보시면
아마도 조금은 ‘리버스 엔지니어링 이라는게 대충 이런 거구나’라고 느낄 수 있으실겁니다.

반응형

+ Recent posts