Broken Code (window31)

고고씽

이런, 나쁜짓을 해보셨군요 ㅋ

ㅋㅋ 친절한 해석

하하하

잘 아네 ^^

블로그 잘 봤습니다 ^^
OBT 잘하세요 !!

Ki 도 + 5 하면요? ^^;

KiAttachProcess()는 바로 호출하면 시스템이 크래쉬되더군요...

중간에 무슨 CRITICAL_SECTION 개체를 lock하던데...(?) lock 하는것도 undocumented함수라...

조금 더 힘들겠지요 ㅋㅋ

호출 방법에 문제가 있던 게 아닐까요?
Ki 를 바로 호출하는 넘을 여러번 봤는데 ^^;

무섭죠 ^^; n모사에서 어떻게 하는지는 모르겠네요

retn(0xC3) 블럭 까지를 전부 코드를 다른 메모리에 옮겨버린 후, JMP를 후킹 함수로 지정해버리더군요. 우회하지 못하도록...

네 그렇게 해도 위 스타일의 방법은 막을 수가 없는데요 ㅎㅎ

JMP뒤의 코드는 전부 0xCC로 바꿔버리면 우회할 수 없을 것으로 생각됩니다...

연구용으로는 그런 시도를 해볼 수도 있겠지만
실전에서는 그런 구조로 개발을 할 수가 없어요
여기를 나만 후킹하고 나만 사용한다면 이런처리가 가능하겠죠.
연구가 입장에서 왜 그건 이렇게 안하나? 라고 생각하는 상당히 많은 것들을
현업 개발자들이 몰라서 안하는게 아닙니다. 필드에서는 적용할 수 있는 기술이 있고
결코 건드려서는 안되는 부분이 존재합니다.
왜냐면 클라이언트는 너무도 다양하니까요.
그리고 나랑 똑같은 생각을 가진 똑같은 기술을 만드려는 개발자도 넘쳐나고요.
10만명의 유저중 10명의 해커를 막으려고 한 짓이
정상적인 1만명의 실행을 방해할 수도 있습니다.

결국, 제일 마지막 방법이 방법론적에서는 최강임에도 불구하고, 후방 호환성과 안정성을 고려하고 시장성과 효율성에 비추어볼 때, 그 방법을 사용할 수 없는 것이군요.

말씀을 듣고나니 추가적으로 궁금한 것이 생겼는데요. 그렇다면 이미 GG나 HackShield같은 게임 보안 솔루션을 보면 하나같이 후킹을 하면 죄다 강제 재부팅과 같은 증상을 보이는데, 그런 경우엔 어차피 보안 솔루션 혼자 후킹해서 먹고 살겠다는 거니 마지막 방법을 써도 되는것이 아닌가요? (실제로 GG의 경우 함수의 끝 부분인 RET 명령어 까지의 Code Snippet을 다른 메모리에 옮긴 후, 실제 함수의 첫 부분에 JMP를 삽입시켜두고, 첫 부분을 제외한 RET명령어까지의 부분을 쓰레기 바이트로 채우는것 같더군요. - 이는 제가 위에서 언급한 방법에서 0xCC로 채우는 것을 쓰레기 바이트로 채우는 것이 다를 뿐, 본질적으로 같은 방법으로 보여집니다.)

네. 그래서 처음 그 기술을 만들었을 때 수많은 프로그램들과 문제가 불거졌고
핵을 쓰지도 않는데 문제가 계속된 애꿎은 유저들만 고생을 했습니다.
그리고 그 부분은 지금도 논쟁이 되고 있는 것 중 하나고요
GG가 다른 보안회사들에게 욕을 겁나게 들어먹고 있는 이유에도 포함이 됩니다.
혼자 먹고 살겠다고 해놓은 그 기술을 아직도 사용하고 있는 이유는
공개적인 자리에서 남의회사 사정을 밝힐수는 없고,
(머 비공개적인 자리에서도 얘기할 생각은 없습니다)
이 업계에서 직접 일을 해보시거나
아니면 그 회사에 입사해보시면 알 수 있을것 같네요.
HackShield는 혼자 먹고 살수는 없다고 판단하여 그 부분을 해제시켜놓은 것으로 알고 있습니다.
그리고 JMP뒤의 코드를 0xCC로 바꿨는데 다시 해커가 바꿔버린다면 어떻게 하시겠어요?
다시 또 0xCC로 바꾸실건가요? 또다시 해커가 바꾸면요?
저는 사실 이런 논쟁은 별로 좋아하지 않습니다.
끝이 없기 때문이죠.
그리고 어떤 것도 최강의 기능은 없다고 생각합니다