이미 알려진 패킹에 대한것들은 넘어가도록하고.

일단 낮은수준의 패킹들부터.

코드에 push로 이상한것처럼 보이는 데이터들을 많이 넣는다.

물론 push로 넣는것 외에도 alloc,free 계열의 함수들도 있을것이다.

끝을 따라가다 보면 jmp rax(eax), 또는 call rax(eax)등등의 방식으로 oep로 이동한다. 그걸 찾아서 가면 끝.

근데 결국 감으로 하게 된다 ㅜㅜ

메모용

IDA View에서 단축키

p = 분석되지 않은 부분 함수화

a = 문자열화

c = 코드화

d = 데이터화

n = 변수 및 함수이름 바꾸기

tab or f5= 해당함수 수도코드화

; = 주석

전체

shift+f12 문자열 목록

https://blog.h3x0r.kr/2019-01-15-about-pdb/

여기서 확인

1. XOR decode. XOR키는 대부분 유일한 것을 쓰므로 XOR연산을 반복하고 있다면 유심히 보자

2. 문자열들. 각 악성코드마다 특별한 문자열이 있을 것이다. 그것을 이용하자

3. unpack 함수들. 상용 packer를 쓴경우가 아니라면 그것은 자신만의 packer일 가능성이 높다. 이를 패턴화하자

4. icon. icon 역시 unique한 icon을 넣는다. 물론 안넣는경우도 있다만...

5. rich header정보. 컴파일 시의 정보는 역시 환경이 같으면 같을 것이고 특히 rich header의 xor키는 비슷한시기 같은 컴파일의 경우 XOR key가 같은 경우가 많다.

6. pdbpath나 pdb의 guid(or signiture)또한 같은 visual studio project에서 컴파일 되었다면 같기 때문에 사용할 수 있다.

위의 내용 모두 없을 때도 있고  있어도 아닌 경우가 있으므로 종합해서 따지도록 하자

바이너리의 rich header가 얼마나 유사한지 알려주기 위한 프로그램의 아이디어를 떠올려 봤는데 rich header에서 나온 각 prodid 중 몇개나 일치하는지를 가지고 유사성을 구별 할 수 있을 것 같아 짜보았다.

I thinks idea of ​​a program to let me know how similar the binary's rich header is.

this idea is matching prodid.

rich 헤더는 문서화 되지 않은 구조이며 컴파일 정보가 담겨있다.

실행할때 사용되는 정보가 아니기 때문에 없더라도 상관이 없다. 하지만 컴파일 정보를 사용하여 유사도 분석에 참고하는 것이 가능하다. 물론 신뢰성은 매우 낮다. 변조도 쉽고 이를 검사하는 것이 없기 때문.

이제 rich header의 구조에 대해 알아보자.

먼저 offset 0x3C부터 0x3F까지는 PE헤더의 시작부분을 나타낸다.

하지만 rich header는 stub와 PE헤더 사이에 있으므로 이것을 padding을 포함한 rich header의 끝으로 보기도 한다.

그리고 0x80부터 rich header가 시작된다.

Rich라는 문자열 이후. 즉 52 69 63 68 뒤의 4byte가 XOR key로 사용된다.

위 XORkey로 Rich의 앞을 복호화 하면 rich header의 평문이 나오게 된다.

이렇게 평문은 언제나 DanS라는 문자열로 시작하게 된다. 이걸 이용해서 XORkey를 얻을 수도 있다.(XOR된 첫 4byte를 DanS로 XOR하면 XOR key가 나온다.)

이렇게 나온 byte들을 prodid값들과 매칭하여 컴파일러 정보를 보여준다.

yara rule에서 많이 쓰이는 strings에 대해 자세히 알아보자

각 strings는 $로 시작하는 식별자(알파벳, 숫자 그리고 _를 사용가능)를 text나 hex, 정규식(이후 regex) 형태로 정의한다.

text의 형태로 넣을때는 "(큰 따옴표)로 hex의 형태로 넣을 때는 {}(중괄호)를 사용한다.

hex에서 띄어쓰기는 있어도 되고 없어도 된다. 하지만 hex형태에서 10진수는 사용불가함을 알자

regex형태는 양 끝에 "/"를 넣어서 만든다. 안에는 정규식을 넣으면 된다.

이제 진짜 활용성이 높은 jump([#-#]), wild-cards(??), alternatives(|)를 알아보자. 

먼저 wild-cards는 리눅스에서의 wild-cards와 매우 유사하다. ??면 그곳에 뭐가 들어가도 상관없다는 것이고 3?는 hex값이 3으로 시작하되 뒤는 상관없다는 것이다.(30,31,32 ....)

jump는 wild-cards여러개를 줄인 형태라고 보면 된다. 

[3-4]면 ?? ?? ??와 ?? ?? ?? ??를 대체한다. 3칸~4칸은 무시하고 다음것을 보겟다는 것이다.

alternatives는 생긴것 대로 그냥 or이다. 괄호로 묶고 앞과 뒤중 하나라도 만족하면 true가 된다.

마지막으로  ascii wide fullword nocase에 대해 알아보자

띄어쓰기로 되어있듯 각각은 모두 다른 옵션이다.

ascii는 기본 옵션,

wide는 유니코드,

fullword는 숫자이외의 문자로 표시,

nocase는 대소문자 구분안함

보통 저렇게 모두 사용한다.

strings는 여기까지 하자

해당 코드는 가장 기본적인 yara rule이다.

각 룰은 'rule'로 구별 되며, test의 위치에 식별자가 들어가게 된다.

위 표는 yara rule의 키워드들이다. 키워드는 식별자로 사용할 수 없음을 유의하자.

이제 yara rule의 구조를 알아 보자.

크게 3부분으로 나눌 수 있다. meta부분은 주석이나 마찬가지이다. 다른사람들에게 자신이 짠 yara rule의 정보를 전달하기위해 존재한다.

strings 부분은 상수를 저장한다고 생각 하면 된다.

condition에서는 조건의 참거짓을 판별한다.

지금까지가 기본적인 yara rule의 구조이다. 다음 것 부터 상세하게 알아보자