일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- Tree/Binary_Search_Tree
- forensic
- Tree/RBTree/Insertion
- Tree/AVL/Insertion
- Tree/Binary_Tree
- ctf
- CS/자료구조/Stack
- tree
- CS/자료구조/Doubly_Linked_List
- UTCTF
- 코드엔진
- Tree/BST
- CS/자료구조/Circular_Queue
- Tree/Traversal
- CS/자료구조/Priority_Queue
- 리버싱
- CS/자료구조/Queue
- Tree/RBTree
- CS/자료구조/Singly_Linked_List
- Tree/AVL/Deletion
- Tree/AVL
- Tree/RBTree/Deletion
- reversing
- CS/자료구조/Linked_List
- CS/자료구조/Circular_Linked_List
- codeengn
- Today
- Total
목록코드엔진 (15)
SuperVingo

0. 실행화면 실패 화면과 시리얼은 정수로 이루어져야한다는 조건을 알 수 있었다. 1. ExeInfoPE 분석 델파이로 작성되었으며 패킹은 되어있지 않으므로 바로 분석을 들어간다. 2. 올리디버거 분석 비교적 쉬웠다. 성공문자열을 찾았고, 분기문이 바로 위에있었다. BP를 걸고 이름에 CodeEngn, 시리얼에 12345를 입력하니 입력한 값은 EAX로 들어가니, 0x45B844에 우리가 원하는 시리얼 값이 들어있을 것이다. DWORD크기만큼 값을 불러와 10진수로 변환하여 다시 입력해보았다. 성공했다.

0. 실행화면 틀리면 위와같은 MessageBox를 보여준다. 1. ExeInfoPE 분석 또 UPX다. 이제는 언패킹 과정은 설명하지 않겠다. 2. 올리디버거 분석 올리디버거에서 Search for -> All referenced strings 에서 성공 문자열을 볼 수 있다. 이를 따라가면 분기점을 찾을 수 있었고, BP를 걸어 12345를 넣어 실행해보았다. EAX에는 입력한 값이 들어가고, CMP EAX, ESI를 통해 분기하므로 ESI에 들어있는 값이 키이다.

0. 실행화면 여러번 입력을 받고, 특정 password를 입력해야하는 것 같다. 1. ExeInfoPE 분석 C#으로 제작된 프로그램이다. C#의 경우에는 Decompiler가 많아서 바로 소스코드를 볼 수 있는 경우가 많다. 이번 문제는 본인이 자주 쓰는 툴인 dnSpy를 통해서 분석하겠다. 2. dnSpy 분석 dnSpy를 통해서 RijndaelSimpleTest라는 클래스를 찾았고, 이 안에서 암호화와 복호화 함수들을 모두 볼 수 있었다. public class RijndaelSimple { public static string Encrypt(string plainText, string passPhrase, string saltValue, string hashAlgorithm, int passwo..

0. 실행화면 Key가 틀리면 아무 변화가 없다. 1. ExeInfoPE 분석 패킹은 되어있지 않는듯 하다. 바로 분석들어가자. 2. 올리디버거 분석 올리 디버거를 열고 쭉 훑어보면 이와 같은 흐름으로 진행된다. GetDlgItemInt를 통해 값을 받아오므로, 키는 정수로 입력되어야한다. 그럼 1234를 넣고 테스트를 진행한다. GetDlgItemInt 직후 BP를 걸어두고 1234를 입력했다. 그후 EAX를 확인해보자. 이처럼 우리가 입력한 값이 정수로 들어간 것을 볼 수 있다. 그리고 무언가 엄청 긴 문자열과 함께 연산을 진행한 후, EAX값을 특정값과 비교한다. 이 과정이 키 생성과정이라고 생각했다. 그래서 비교하는 CMP 구문에 BP를 걸고 진행을 했는데... ??? 루틴을 진행해도 EAX값은 ..

다 했던거다... 슉슉 넘기자 0. 실행화면 쓱 넘기자. 1. ExeInfoPE 분석 UPX로 패킹되어있다. 하지만, 우리는 StolenBytes가 있다는 걸 알고있으니 언패킹툴을 이용하지 않는다. 바로 올리디버거로 넘어가자. 2. 올리디버거 분석 바로 PUSHAD가 보인다. 아래로 쭉쭉내리면... POPAD와 JMP OEP가 보인다. 또한 StolenBytes도.... 근데 여기서 중요한게 하나있다. OEP가 StolenBytes를 제외한 만큼 땡겨져있기 때문이다. 이를 고치기 위해서는 StolenBytes가 몇바이트인지 구한 후, OEP에서 빼줘야 원래 진정한 OEP가 된다. 주의하자. A. 사실 여기서는 문제 풀이가 끝이다. 다했던거라 너무 간단하다. 하지만 궁금증이 생겼다. 무슨 키파일을 찾는걸까..

OEP를 구하는 문제는 많이 해봤지만, UPX 패킹에 한정되서였다. 이번에는 다른 종류의 패킹을 보고, 직접 언패킹해볼 예정이다. 0. ExeInfoPE 분석 이번엔 익숙한 UPX가 아닌 생소한 Aspack이라는 패킹 툴이다. 하지만, 겁먹을거 없다. UPX와 언패킹 과정은 비슷하다. PUSHAD -> 언패킹 -> POPAD -> JMP OEP이다. 그럼 빠르게 시작해보자. 1. 올리디버거 분석 올리디버거가 딱 PUSHAD부분에서 멈춰줬다. 그러면 POPAD를 찾으면되는데, 우리는 무식하게 눈으로 확인했지만, 이제는 다르게 접근해보도록 하겠다. PUSHAD와 POPAD가 일단 어떤 명령어인지 알아보고 가자. PUSHAD: 범용 레지스터들의 값들을 Stack에 저장. POPAD: Stack에 값들을 범용 ..

이번 문제는 StolenByte를 구하는 문제이다. * StolenByte란? StolenByte란 언패킹 과정중에 프로그램의 일부를 다른 부분에서 실행시켜 언패킹을 어렵게 하기 위해서 숨긴 바이트라고 생각하면된다. 이를 쉽게 확인하는 방법은 단순하다. 언패킹을 해보면된다. 0. 실행화면 정상적으로 잘 실행된다. 1. ExeInfoPE 분석 익숙한 UPX다. 빠르게 언패킹을 진행해보자. 2. UPX 언패킹 후, ExeInfoPE UPX 언패킹을 진행했고, ExeInfoPE에서도 UPX가 언패킹된것을 볼 수 있다. 3. 실행하면.... 첫 화면이 깨져 나온다. 이런 식으로 언패킹을 어렵게 진행한다는 이야기이다. 이렇게 StolenByte가 존재할 경우, 언패킹을 직접 들여다 보아야한다. 4-1. 올리디버거..

이번 문제는 OEP를 구하는 문제이므로 빠르게 ExeInfoPE를 통해 압축확인 후, 언패킹, PEView를 통해 EP와 ImageBase를 구해 빠르게 구해보도록 하겠다. 0. ExeInfoPE UPX 패킹이 진행되어있다. 빠르게 언패킹을 진행해자. 1. UPX 언패킹 언패킹을 진행했으니 다시 ExeInfoPE를 확인해보자 언패킹이 진행된 것을 볼 수 있다. 2. PEView 분석 Image Base와 EP는 IMAGE_NT_HEADERS에 볼 수 있다. 이 두가지를 합치면 OEP가 된다.