Secure-Ark

Windows7 ( Vista) 이상에서는 어플리케이션에서 에러가 생겨도 Windows Error Reporting이 먼저 가로채가고 전송 후에 남기질 않아서 나의 덤프를 왜 가져가느냐! 하고 내 덤프를 뜨기 위해서는 레지스트리를 설정해야 한다. 하지만 이럴 때마다 귀찮기 때문에 레지스트리를 올려놓는다. 내용은 까보면 다음과 같다. --------------------------------------------------------------------------------------------------------------------- Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows E..

1. 최적화가 되어 있다. >> 소스코드에 존재하는 모든 지역변수가 '반드시' 다 보이는 것은 아니다. 그러므로 dv 혹은 로컬변수 출력창에서 memory access error 등 보이지 않을 수 있다. 저장되지 않은 변수는 레지스터에서 일시적으로 저장된다. 그러므로 레지스터를 추적해야 한다. 당연히 이전 함수 프레임의 레지스터는 휘발되었으니 이 때부터는... 디서셈을 시작하지. 2. x64의 함수 호출에서의 파라메터 >> x86은 함수 호출 시 파라메터를 4개까지 스택에 저장하지만, x64의 경우엔 레지스터가 늘어난 대신에 최대한 레지스터를 활용하여 함수 호출 시 파라메터를 레지스터에 저장해서 넘겨준다. 그렇기 때문에 마찬가지로 레지스터를 추적해야 한다. >> 하지만 컴파일 옵션 중에 파라메터를 스택..

심볼 서버가 왜 필요한가. windbg로 디버깅하면서 혹은 vs로 디버깅하면서 pdb를 물어버리면, 작업 중이던 코드의 빌드가 되지 않는다. pdb를 누가 물고 있으니까. 그래서 릴리즈된 제품이라면 따로 pdb나 출력물을 보관하고 있어야 하고, 현재 개발중인 상태라면 마찬가지로 개발 중이더라도 이를 인지하고 있는 편이 좋다. 괜히 왜 빌드가 안되는지 살펴보지 말고..

Windbg는 분명 좋은 툴에는 틀림이 없으나 문제가 있다. 바로, 우리에게는 '최적화'라는 헬모드가 있다. 최적화가 된 코드의 흐름은 함수 프레임이 생략되기도 하고(omit 옵션), 파라메터 등이 생략되기 때문에, 레지스터 어딘가에, 스택 어딘가에서 찾아내거나 역추적하면서 디서셈블 하면서 찾기가 너무 힘들기 때문이다. 이에 대한 해결할 필요가 있다. 대부분의 상용 프로그램이 최적화가 되어 있기 때문에 디버깅이 항상 헬모드가 될 수 밖에 없다. * 다음의 내용들을 읽고 해결을 해보자. codemachine.com/articles/x64_deep_dive.html CodeMachine - Article - X64 Deep Dive X64 Deep Dive In depth tutorial on the key..

github에 연동해놓을 것. 자주 쓰는 파이썬, dll 등의 Windbg 확장 모듈을 링크한다.