대충공부한거적어두는블로그

API 코드 패치 방법 - API 코드 시작 5바이트 값을 JMP xxxxxxxx 명령어(후킹 함수로 점프)로 패치 - 후킹하려는 API 코드의 길이가 최소 5바이트보다 커야 한다 - 반복적인 unhook/hook으로 성능 저하 - 멀티스레드 환경에서 프로세스의 다른 thread에서 해당 API를 read하고 있을 때 코드 패치를 시도하면 Access Violation Error 발생할 수 있음 (스레드 간 충돌) => 핫 패치 방식 (7바이트 코드 패치) - API 코드 바로 위에 5바이트의 'NOP' 명령어 존재하고 'MOV EDI, EDI' 명령어로 시작하는 API에 한해 가능 - API 코드 직전 5바이트를 FAR JMP 명령어로 변경(사용자 후킹 함수로 점프) - API 시작 코드 2바이트를 S..

InjectEjectDll.exe 코드 // InjectEjectDll.exe #include "stdio.h" #include "windows.h" #include "tlhelp32.h" #include "tchar.h" // Debug API를 사용하기 위해 엑세스 토큰의 privilege 변경 BOOL SetPrivilege(LPCTSTR lpszPrivilege, BOOL bEnablePrivilege) { TOKEN_PRIVILEGES tp; HANDLE hToken; LUID luid; if(!OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES|TOKEN_QUERY, &hToken)) { _tprintf(L"OpenProcessToke..

API 후킹 방식 - DLL Injection을 통해 타깃 프로세스의 IAT에 저장된 원함수 주소를 후킹 함수 주소로 조작 - 후킹하고자 하는 API가 대상 프로세스의 IAT에 존재하지 않으면 후킹 불가 타겟 API 파악하기 - 실행 중인 calc.exe에 Ollydbg attach, calc 모듈에서 호출하는 API들 목록 중 의심스러운 API들에 전부 bp ex) DrawTextW, DispatchMessageW, LoadStringW, PostMessageW, SetWindowTextW 등등 - 입력값에 대한 힌트는 'SetWindowTextW' API에서 찾을 수 있었다 => 후킹 대상 구현 코드 - InjectDllForHook.exe // InjectDllForHook.exe #include ..

타켓 API 확인 - 파일로 저장할 버퍼 관련: kernel32!WriteFile API - 파일로 불러올 버퍼 관련: ??? => ReadFile, CreateFile, CreateFileMapping 등이 의심스럽다 1) ReadFile인지 검증 - notepad 모듈에서 해당 API 호출하는 코드에 bp 걸고 달렸는데 멈추지 않음. 아니다!! 2) CreateFile & CreateFileMapping (+ MapViewOfFile ?) -알아보니 지정된 파일에 대한 명명되거나 명명되지 않은 파일 매핑 개체를 만들거나 여는 함수는 MapViewOfFile라고 함! - 파일 open시 CreateFile -> CreateFileMapping -> MapViewOfFile 순으로 API 호출이 이루어진..

Target API 확인 - Process Monitor로 Notepad.exe에서 파일을 저장하는 순간을 확인해보자 - 열려있는 notepad.exe의 PID, 저장할 파일의 이름을 필터에 세팅 후 저장 진행해보면 - 어떤 API들의 호출이 발생했는지 확인 가능 => kernel32.dll!WriteFile() API 의심 가능! BOOL WriteFile( [in] HANDLE hFile, [in] LPCVOID lpBuffer, // 파일에 쓸 데이터를 포함하는 버퍼 포인터 [in] DWORD nNumberOfBytesToWrite, // 파일에 쓸 바이트 수 [out, optional] LPDWORD lpNumberOfBytesWritten, [in, out, optional] LPOVERLAPP..

CodeInjection.exe를 디버깅하면서 생각했다. 어셈블리로 ThreadProc()을 짠 후 바이트 코드 배열을 넘겨주어도 되겠다 Assembly code of ThreadProc 1 PUSH EBP 2 MOV EBP, ESP 3 PUSH ESI 4 MOV ESI, DWORD PTR SS:[EBP+8] 5 CALL 7 6 ASCII "user32.dll\x00" 7 CALL DWORD PTR DS:[ESI]; LoadLibraryA("user32.dll") 8 CALL 10 9 ASCII "MessageBoxA\x00" 10 PUSH EAX 11 CALL DWORD PTR DS:[ESI+4]; GetProcAddress(hMod, "MessageBoxA") 12 PUSH 0 13 CALL 17 1..

Code Injection (Thread Injection) - 우리가 원격에서 실행하고픈 코드가 있을 때, 이를 DLL 파일 형태로 만든 후 CreateRemoteThread() 인자로 LoadLibraryA() API 주소와 dll name 주소를 건네주어 DLL을 inject하고 DllMain에서 코드를 실행시킴 => 흔적이 많이 남음(새로운 dll 로드되면 process explorer에서 즉시 확인 가능), 메모리 많이 차지 - 상대 프로세스에 독립실행 코드(Thread Procedure)과 데이터(Thread Parameter)만 삽입해 CreateRemoteThread()로 해당 thread를 실행시켜보자 => 메모리 덜 차지, 흔적 거의 남지 않음, 별도의 DLL 파일 필요 없음, 규모 작..

PE 파일에서 myhack3.dll을 임포트하도록 IDT를 비롯해 TextView.exe PE patch를 진행해보자. Step1. IDT 주소 확인 IDT는 .rdata 섹션에 포함되어 있으며, RAW = 0x84CC - 0x6000 + 0x5200 = 0x76CC 이고, IID 구조체(크기 0x14) 5개로 구성되어 있다. Step2. IDT 마지막에 IID 구조체 추가 여부 파악 .rdata 섹션을 살펴보면 IDT 다음에 바로 INT가 등장하므로 IID 구조체 덧붙일 수 없음 IDT를 파일의 빈 영역에 (NULL padding이면서 메모리에 로드되는 영역) 옮기면 됨 .rdata file offset: 0x5200 ~ 7E56 (사용되는 영역), 0x7E57 ~ 0x7FFF (NULL padding..

// EjectDll.exe #include "windows.h" #include "tlhelp32.h" #include "tchar.h" #define DEF_PROC_NAME L"notepad.exe" #define DEF_DLL_NAME L"myhack.dll" // process 이름 가지고 PID 찾기 DWORD FindProcessID(LPCTSTR szProcessName) { DWORD dwPID = 0xFFFFFFFF; HANDLE hSnapshot = INVALID_HANDLE_VALUE; // 시스템 스냅샷의 핸들 PROCESSENTRY32 pe; // 프로세스 정보 저장할 구조체 pe.dwSize = sizeof(PROCESSENTRY32); // 구조체 크기 초기화 hSnapsho..