debug 모드와 release 모드의 바이너리를 둘다 가지고 있으면,
용량 비교만하면 되니 매우 간편 하지만, 하나만 가지고 있는 경우 정확히 알수가 없다.

이럴때 .net 컴파일러로 만들어 진 경우는 .net reflecter로 debugged 플래그가 있다고 한다.
http://blog.naver.com/PostView.nhn?blogId=techshare&logNo=100150127754
해당 내용은 이쪽을 참조하면되고,

나의 경우는 c++ 로 만들어진 바이너리 였기에 다른 방법이 필요했다.
그래서 로드되는 dll을 비교해보니 debug와 release 가 사용하는 msvcr이 다르다는 것을 확인하였다.

dependancy walker(http://www.dependencywalker.com/)로 로드되는 dll을 조사하여,

MSVCR90D.DLL
MFC90UD.DLL

가 포함되면 debug 빌드이다.
release 의 경우 D가 빠진

MSVCR90.DLL
MFC90U.DLL

이 로드된다. (뒤의 숫자는 빌드환경에 따라 달라질 수 있다.)

(0) (0)

보안솔루션 관점에서 이야기하는건 어짜피 병림픽이니, 제하고

외부 프로그램들은 항상 고정위치의 값을 변조하고나 읽어가서 악용하는 경우가 많다.

메모리풀을 만들때, 메쏘드에 얼록외에 추가로 보호얼록 같은걸 만들어서,
기존 풀의 랜덤한 영역에 할당해주는 것도 도움이 되지 않을까 싶다.
리눅스에는 os가 지원하는 기능으로 알고 있다.

추가로 변수 완전하게 추상화가 가능하면, 실제 저장 영역은 바이트 단위로 쪼개서 랜덤한 영역에 분포시키고, 오버라이드된 오퍼레이터 ( = ) 에서 합쳐서 돌려주는 식으로 구현하는 것도 괞찮을 듯 하다.

TCP는 신뢰성을 가진 통신 프로토콜이다.
이런 신뢰성 문제중에 하나가 Reordering이 있는데,
이는 패킷이 어떤 알수없는 사정에의해 순서가 뒤바껴서 온경우를 말한다.

자세히 설명하면
데이터를 전송혹은 다운로드 받을 때 ack가 고정이되고, seq를 통해서 현재 위치를 가늠하게 되는데,
이때 seq + len 으로 추정된 다음 seq의 패킷이 오지 않고, 다른 패킷이 왔을 때를 말한다.

크기 1 짜리 패킷 5개를 보냈을 때
1 -> 2 -> 3 -> 4 -> 5 이런식으로 seq를 확인하여 패킷을 합치면 된다.
1 -> 3 -> 2 -> 4 -> 5 로 왔을 때는?
이때 reordering이 발생하는데 WireShark에서는 TCP Out-of-Order라고 표시해준다.
TCP는 3이 도착했을 때 3이 현재 올바른 순서로 온것이 아닌 것으로 파악하고 ,
3을 버퍼에 쌓아둔다. 그리고 2가 도착했을 때 2를 사용하고, 버퍼에 쌓아둔 3을 사용하게 되는것.

이런 TCP Reordering은 보통 3개까지만 저장하되 이를 넘어가면
loss data로 간주하여 재전송을 요청하게 된다.

• SNMP Library Version Mismatch (5.3.1 vs 5.3.2.2)
  Net-Snmp 버전이 안맞는 경우로 Spine 최신버전을 깔거나(e버전), Net-Snmp를 5.3.1로 다운그래이드 한다.
• configure: error: Cannot find SNMP header files under
  Spine을 컴파일 할 때 Net-snmp-devel이 설치 되어 있지 않으면 발생하는 에러, Net-snmp-devel을 깔자.

HackJam을 둘러보다가 SSH패킷이 잔뜩 나오는 문제가 있었는데,
문득 난 스니핑을 할줄 알지만 SSH Stream이 나오면 아무것도 못하잖아! 라는 걸 깨닿고, 얘를 어떻게 하면 까볼 수 있을까 하고 노력을 하고 있음.

보통 SSH는 비대칭키를 이용해서 대칭키를 교환하는데 이로써 제 3자는 대칭키를 얻을 수 없게 되어 스니핑한 것을 복호화 할 수 없게 된다라는 스토리.

하지만 만약 내가 타깃의 컴퓨터의 쉘을 갖고 있다면? 서버가 아니라 내가 클라이언트일때 분명 어딘가에 대칭키를 가지고 있을 터인데, 현재 Putty같은 것으로 통신을 해보면 로그인 전에 비대칭키를 저장할거냐는 메세지가 나온다.