baadf00d라거나 deadbeef라거나 0xcdcdcdcd라거나(…) 메모리 디버깅하다보면 가끔 보게되는 녀석들이네요;

근데 x5보다 느리면 문제가되긴하나보네요; 학부다닐때는 한 30배 느려져도 자고 일어나면 끝나겠지를 했는데 /먼산

그리고 제가 잘못 알았네요. Valgrind의 방식도 역시나 인스트루멘테이션해서 메모리 주소 값을 계속 측정하는 거네요. 하기야 Valgrind의 slowdown이 x30 이상이니 그런 식으로 해야죠.

이건 사실 만들기가 어렵지 않습니다. 아주 심심하시다면 PIN이라는 dynamic binary instrumentation 툴로 뚝딱(!) 만들어 낼 수 있습니다. PIN을 이용하면 메모리에 접근하는 명령어를 가로채서 그 주소를 가져올 수 있죠. 스택 영역은 이제 VC++ 컴파일러가 넣어주는 코드만으로도 충분히 버그를 잡고 힙은 정확히 하려면 말씀대로 Valgrind 방식을 써야 합니다. 대신 무진장 느립니다. 보통 x5 이상 늦어지면 고객들로부터 욕이 튀어나오죠. 그래서 multithread 버그 검출 (재현이 힘든 버그들) 프로그램 등이 실용화되기 매우 힘듭니다. 보통 50배 이상 느려지거든요. (모든 힙 영역 메모리 엑세스를 검출하면 한 30~60

VC++에서 디버그 모드로 컴파일 할 때는 new/malloc이 다른 버전으로 치환이 되어 메모리릭 추가 코드도 넣어주고 0xbaadf00d와 같은 값을 넣어서 체크하기도 하죠. HeapAlloc Win32 API 자체는 변함이 없습니다. 한 때 제 전공 분야라 답변이 길어졌습니다. -_-

ipkn / 자연어의 복잡도가 너무 커서; 근데 난 아직은(?) python 정도만되어도 편하게 써서 ㅎㅎ;

네 저도 댓글 보고 이상해서 고민하면서 출근했는데, 고치기 전 코드를 보니 strcpy_s가 아니라 memcpy_s네요. NULL만 빼놓고 복사한건 마찬가지 -_-;;;

데브파트너는 안써봐서 — Valgrind 비슷한거 없냐고 했더니 그거 라이센스를 줘서; 근데 Windows Server 2003/x64 라고 설치가 안되는 문제가 — 모르겠고, Valgrind는 MemCheck로 돌리면 아예 VM용 컴파일을 하고 VM 위에서 메모리 접근을 계산해서 스택 영역은 몰라도(이건 아마도 canary 값 검사) 힙 영역은 상당히 잘 잡아내던데요;;;

피앙 / 난 습관이고 자시고 문자열 길이를 내가 계산 안한다. std::string/wstring 쓰던가 strdup을 쓴단다[...]

MSDN을 보니

The strcpy_s function copies the contents in the address of strSource, including the terminating null character, to the location specified by strDestination.

널을 포함해서 카피한다고 나와있는데요. 그리고 이상하게 위의 코드를 그대로 돌려보면 디버그 모드에서 strcpy_s를 실행하면 버퍼가 부족하다고 assertion이 뜨네요. *_s 함수군들이 어설션이 풍부해서 사실 버퍼 부족 문제는 디버그 시간에 잡힐 수도 있었을 것 같은데 좀 의아하네요. new/malloc이 non-debug 버전으로 링크되었나 싶기도 하네요.

그리고 힙 영역이 망가지는 건 밸그린드, 데브파트너가 특별히 똑똑하게 하는 건 없구요. (설마 메모리 억세스를 다 디텍트해서 바운더리 넘는가를 체크할 수는 없겠죠. 현재의 하드웨어로는 거의 불가능합니다.) 디버그 모드의 힙 라이브러리처럼 그냥 canary value가 망가진 것 보고 디텍트 하는 정도입니다. 그래서 힙 관련 에러는 디버그 힙 라이브러리로도 보통 충분히 검출은 되죠.

근데 항상 좋은게 아닌게 debian 개발자들이 openssh에 valgrind 돌리고는 어째서인지(…) 임의성;randomness를 부여해야할 배열 하나를 통채로 초기화(?)해버려서, 보안 문제를 일으킨 일도 있음….(…)

요즘은 C++로 코어짜고, 한 두번 실행될 부분 — 데이터 파싱 같은 것 — 은 아예 lua나 python 임베딩 시켜서 처리하고 있어요(…)