현시창을 어떻게 견디시나요?

winner의 이미지

일을 하다 보면... 특히 전문적인(?) 일을 하다 보면 이론과 현실의 괴리감을 느낄 때가 많습니다.
썩은 안쪽을 보여주지 않고 대충 덮어도 모르고 넘어가는 일이 많거든요.

회사에서 들어간지 2년 5개월이 되었습니다.
세상 뭐 별거 있나? 똥 치우며 사는거지 라고 생각하면서 지금까지 왔는데 이대로 살면 더이상 재미없을 것 같네요.

글쎄... 어찌보면 큰 그림 중에 약간의 얼룩일지도 모르겠습니다.
제가 민감한 걸지도 모르지요. 하지만 역시 이제는 못 견딜 거 같아요.

다들 어떻게 견디시나요? 자신의 일에 의문을 갖지 않으신가요?

-------------------------------------------------------------------------------------------------------------

너무 추상적으로 썼는데 좀 구체적으로 써보겠습니다.
Software에서 암호를 program 내에 내장을 했을 경우 Java, C# 등은 decompiler를 통해 매우 적나라하게 들어납니다.
Compile을 하지 않는 interpreter는 말할 것도 없겠지요.
설령 native와 연계를 한다고 해도 결국 interface는 들어나겠죠.

그렇다면 전체가 native binary 로 작성된 program은 어떤가요?
이론적으로는 의미가 없다고 하는데 binary 해석이 어렵다는 이유로 현실적으로 받아들여지는 경우가 많습니다.
사실 복호화된 평문을 쓰는 쪽한테 암호와 암호 알고리즘을 숨긴다는 것이 원천적으로 의미가 없기도 하지요.

원론적으로 보면 접근통제를 통해 이루어져야 할 보안 요구사항이 의미없는 암호화를 통해 처리되곤 합니다.
물론 접근통제과정에서 보호되어야할 기밀성은 있기 마련입니다만 위와 같은 방식을 쓰지는 않죠.

더욱 어이가 없는 점은 인증기관에서 이런 것을 요구합니다.

---------------------------------------------------------------------------------------------------------------

위의 이야기에서 좀 다른 기술적 의문이 있는데요. Native binary 해석을 통해 program에 내장된 암호를 찾는 것으
얼마나 어려운 것인가요? Compile 시점에서 source와 assembly 교차 출력을 하고, 이것을 binary의 decompile과 비교를
하니 암호 위치를 찾는 것이 어렵지는 않았습니다.
하지만 assembly 교차출력과 비교하지 않고 binary 만 가지고 작업한다면 저로서는 쉽지 않을 것 같긴 합니다.
아... 암호는 program의 .data section 에 넣지 않고, .text section 에 들어가도록은 해놨더군요.
그래서 byte 단위로 stack에 들어가는 것이 .text section에 기록되어 있습니다.
이런 조치가 실제로 암호를 찾기 어렵게 하는데 의미가 있는 궁금합니다.
Reversing을 해보신 분들은 이런 것을 분석하시는데 얼마나 시간이 걸리시나요?

익명 사용자의 이미지

역공학을 방해할만한 요소라는 것은 실행파일 압축, anti-debugging trap등을 말합니다. 그런 조치를 취했다면 며칠 정도까지 분석 시간을 낭비하게 할 수 있습니다. 그렇지 않으면 원하는 암호화 루틴을 찾고 해당 키를 찾는데는 길어도 하루면 충분할 겁니다. 단, 정말 마음먹고 분석할 경우에는 이렇게 되지만 대부분은 역공학도의 흥미를 끌만한 주제가 아니므로 세상은 평온하게 돌아갑니다. :)

익명 사용자의 이미지

어셈블리를 아주 잘 알 필요도 없이 학부생 수준에서 디컴파일러, 디버거, 어셈블리 책을 가지고 하루 정도면 winner님이 언급하신 형태의 바이너리에서 패스워드 추출 가능합니다.

winner의 이미지

제 생각에 source 가 역분석되지 않기를 바라는 상황밖에 없을 것 같네요.
난독화 정도가 아닌가 싶은데...

snowall의 이미지

어째, 그 인증기관만 리버싱을 못하면 된다. 라는 상황인것 같은데요...

피할 수 있을때 즐겨라! http://melotopia.net/b

winner의 이미지

아, 예.
현실이 그렇습니다. 인증이 필요했던 program은 전체가 native 였습니다.

그리고 연관된 program을 하나 작성했습니다.
작업능률과 회사의 업무협조능력을 고려하여 Java 로 작성했죠.
이것에 대해서 decompile 결과를 알리니까 당연히 문제가 되더군요.
제가 이것을 알린 것은 암호화 처리가 무의미함을 보이기 위해서였죠.
결과는 native interface 로 대충 얼버무려라... -_-.

인증과 이번 일을 겪으면서 사람이라는 존재는 자신이 못하면
남들도 다 못하는 줄 아는구나라는 것을 느꼈습니다.
마치 사냥꾼에게 고개를 돌리는 사슴처럼 말이죠.

Anti reversing 이라는 것이 여러가지 의미가 있을 거라고는 생각합니다.
기본적으로 malware / anti malware 의 경쟁이 그럴테고.
이런 것을 전제로한 사이버전쟁도 생각해볼 수 있겠죠.
제가 떠올릴 수 있는 것은 이 정도인데 그 외에도 의미가 있는지 궁금해서 추가로 질문해봤습니다.

익명 사용자의 이미지

불법 복제용으로 activation routine을 크래킹하는 것을 막기 위해 각종 방해 기법이 동원됩니다.
그리고 안 좋은 용도로는 malware나 virus등에서 antivirus 업체들의 분석에 애를 먹이기 위해 쓰기도 합니다.

이 문제에 있어서는 예민하게 생각할 필요없이 그냥 덮어두는 게 좋을 듯 싶습니다.
세상에는 아직 보안 개념 없이 잘 돌아가는 많은 물건들이 있습니다.
알고는 있지만 법에 저촉되니 안하는 것 뿐이죠.

winner의 이미지

이 문제를 열어 보는 것 자체가 사실 싸우자가 될지는 모르겠습니다만...

제 생각에 anti reversing 은 계속해서 변경이 이루어진다면 충분히 의미가 있을 겁니다.
CAPCHA 처럼 말이지요. 현실적으로 그 분야가 어떤 상황인지는 모르겠습니다만...

저 역시 법률에 의해서 보호되는 것을 기술적으로 고민할 이유는 없다고 생각합니다.
그렇기 때문에 무의미한 암호화 처리와 native code 에 의지하는 것이 싫은 겁니다.

제가 맘에 안 드는 것은 정확한 진실을 외면하는 것입니다.

기술적으로는 난독화까지 알아보고 덮어둘 생각입니다.
하지만 제 안에서 일어난 비뚤어짐은 덮어지지 않겠죠. ^_^.

snowall의 이미지

예상되는 위험성에 대해서 경고해줬는데도 그러고 있으면, 경고 내용은 문서화해서 잘 전달해주고(증거), 해달라는대로 해주시면 될듯 싶네요.

그럼 문제가 생기든 말든 그건 그쪽 사정입니다.

피할 수 있을때 즐겨라! http://melotopia.net/b

winner의 이미지

이 문제는 제가 회사에서 혼자서 작성한 program만의 문제라고 보기는 어렵습니다만... 준비해놓도록 하겠습니다.
신경써주신 점 감사드립니다.