반응형

파일이나 폴더를 삭제하려고 할 때 아래와 같이 'XXX에서 열려 있어 작업을 완료 할 수 없다'는 메세지가 나오는 경우가 있다.

파일이 사용 중이기 때문에 삭제할 수 없다.

물론 이런 경우 대부분 엑셀을 종료하면 간단히 해결 할 수 있지만 간혹 엑셀이 종료되었는데도 파일을 삭제할 수 없는 상황이 발생하기도 한다. 파일(폴더)의 핸들을 어디선가 다른 프로세스가 잡고 있기 때문이다.

 

간단히 비슷한 상황을 만들어 해결책을 알아보자.

 

삭제하고 싶은 폴더(Target)를 만들고 안에 파일 하나를 생성한다.

 

생성된 파일을 열어준다.

 

폴더(Target) 삭제를 시도한다. 폴더 내 파일이 사용 중이기 때문에 실패한다.

물론 우리는 메모장(notepad)이 파일을 잡고 있다는걸 알지만 여기서는 메모장의 상황은 모르는걸로 가정하자.

 

 

어떤 프로그램이 폴더(Target)를 사용 하는지 알아내기 위해 프로세스 익스플로러를 실행하고 Find - Find Handle or DLL...을 선택한다.

 

찾고 싶은 이름(target)을 입력하고 Search 버튼을 클릭한다.

'target' 문자열이 들어가는 이름의 핸들을 잡고 있는 프로세스를 모두 찾아준다. 위 예에선 우리가 삭제하고자 하는 'G:\Test\Target'을 notepad.exe 프로세스가 잡고 있는걸 확인 할 수 있다. 클릭한다.

 

notepad.exe 프로세스가 소유한 파일 핸들 중 'G:\Test\Target'이 있다.

어떤 프로세스가 핸들을 잡고 있는지 알아냈으므로 그 프로세스를 종료시키거나 다른 작업을 통해 핸들을 반환하도록 할 수 있다.

 

※ 참고

Process Explorer

 

반응형
Posted by J-sean
:
반응형

프로그램의 어떤 함수가 컴퓨터 CPU 자원을 독점하는지 찾아보자.

 

프로세스 익스플로러를 실행한다.

 

Options - Configure Symbols... 를 선택한다.

 

Dbghelp.dll 경로와 분석할 프로그램 Symbols 경로를 지정한다.

 

CPU 자원을 많이 소비하고 있는 프로세스를 찾는다.

 

 

우클릭 - Properties... 를 선택한다.

 

Threads 탭을 선택하고 CPU를 많이 사용하는 스레드를 찾아 선택하고 Stack 버튼을 클릭한다.

 

ThreadFunc2 함수가 실행되고 있음을 확인한다.

 

ThreadFunc2()

 

반응형
Posted by J-sean
:
반응형

유저 모드 애플리케이션이 충돌한 후 덤프를 수집하고 저장하도록 해 보자.

 

위와 같이 레지스트리 값을 작성한다. DumpType 만 작성하고 나머지는 기본값을 사용했다.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps

Value Description Type Default value
DumpFolder 덤프 파일을 저장할 경로 REG_EXPAND_SZ %LOCALAPPDATA%\CrashDumps
DumpCount 폴더의 최대 덤프 파일 수 REG_DWORD 10
DumpType 다음 덤프 유형 중 하나
0: 사용자 지정 덤프
1: 미니 덤프
2: 전체 덤프
REG_DWORD 1
CustomDumpFlags 사용할 사용자 지정 덤프 옵션. 이 값은 DumpType 이 0으로 설정된 경우에만 사용. REG_DWORD  

 

애플리케이션이 충돌하면 덤프 파일이 생성된다.

 

※ 참고

Collecting User-mode dumps

 

반응형
Posted by J-sean
:
반응형

x32/x64 디버거에서 심볼파일(pdb)을 불러오자.

 

디버깅할 프로세스를 불러온다.

 

심볼파일을 불러온다.

symload module_name, path

 

심볼파일이 존재하면 완료 메세지가 뜬다.

 

심볼 윈도우에서 모듈을 선택하고 심볼을 확인한다.

만약 프로그램 파일이 존재하는 디렉토리에 심볼파일이 같이 존재하면 자동으로 로드된다.

 

※ 참고

symload/loadsym

symunload/unloadsym

 

반응형
Posted by J-sean
:
반응형

WinDbg 메모리 윈도우에서 변수를 확인해 보자.

 

g_dwGlobal 변수는 0x00007FF6DC7FE000 번지 메모리에 0x5678 값을 가지고 있다.

 

메모리 윈도우에서 변수명으로 확인해 보자.

Address 박스에 변수명(MyApp!g_dwGlobal)을 입력하면 변수값(0x5678)이 주소로 인식된다.

 

변수명 앞에 주소 연산자(&)를 붙이자.

주소 연산자(&)를 붙이면 변수 주소가 주소로 인식된다.

 

반응형
Posted by J-sean
:
반응형

아래 링크를 참조해 WinDbg를 설치한다.

Windows 디버거 설치

 

WinDbg를 실행하고 Settings를 클릭한다.

 

Debugging settings - Debugging paths - Default symbol path:에 위와같이 세팅한다.

심볼 파일이 디버깅 할 파일과 같은 경로에 있거나 path에 지정한 경로(I:\windbgsymbols)에 있으면 된다.

※ 기본 심볼 서버: https://msdl.microsoft.com/download/symbols

※ 기본 캐시 폴더: C:\ProgramData\dbg

 

Symbol path for Windows debuggers

 

디버깅할 파일을 로드하면 관련 심볼 파일도 로드된다.

 

심볼파일(.pdb)을 로드할 때 WinDbg는 타임 스템프 등을 고려한 버전 체크를 하는데 버전이 맞지 않으면 로드하지 않는다. 아래 명령을 사용하면 심볼파일의 버전에 관계없이 로드할 수 있다.

[한 모듈의 심볼파일만 로드]

.reload /i Module_Name

ex) .reload /i myapp.exe

[모든 모듈의 심볼파일 로드]

.reload /i

 

2023.07.02 - [Reverse Engineering] - WinDbg 버전(타임스템프) 일치하지 않는 심볼파일 로드하기

 

반응형
Posted by J-sean
:
반응형

기드라에서 디스어셈블되지 않고 Opcode로 표시된 명령을 디스어셈블하고 함수로 등록해 보자.

 

리스트창을 보면 디스어셈블되지 않고 Opcode로만 표시된 부분이 있을 수 있다.

 

디스어셈블 하고 싶은 부분의 첫 명령어에서 우클릭 - Disassemble을 클릭한다.

Disassemble(Restricted), Disassemble(Static)은 한 줄(혹은 블럭으로 지정된 부분)만 디스어셈블한다.

 

Opcode로만 표시되던 명령어가 디스어셈블되었다.

 

함수 전체가 디스어셈블 되지 않고 Opcode로만 표시되었다.

 

 

첫 코드에서 우클릭 - Disassemble을 클릭한다.

 

디스어셈블 되었으면 다시 우클릭 - Create Function을 클릭한다.

 

디스어셈블된 부분이 함수로 등록되었다.

 

반응형
Posted by J-sean
:
반응형

Ghidra로 패치한 파일을 저장해 보자.

 

패치할 프로그램을 임포트한다.

 

WindowsPE x86 Propagate External Parame... 옵션을 선택하고 분석한다.

 

패치가 필요한 코드에서 우클릭 - Patch Instruction을 선택한다.

 

어셈블리 명령을 수정한다.

 

 

수정이 완료되었다.

 

File - Export Program...을 선택한다.

 

Format은 PE로 바꾸고 Output File을 적당히 지정하고 OK를 클릭한다.

 

Export 결과가 표시된다.

 

 

패치된 파일을 실행해본다.

 

반응형
Posted by J-sean
: