소프트웨어 크랙을 막기 위한 방법 두번째 이야기

초보 개발자들을 위한 주(註)

리버스 엔지니어링 : Reverse Engineering 역 공학이라고 하며, 크랙을 하기 위해 또는 분석 자체만을 목적으로서 특정 파일이나 알고리즘, 프로세스(절차적 의미에서)를 분석하는 모든 행위들을 일컫는 말
(디컴파일이나 디스어셈블을 한다 함은 리버스 엔지니어링의 하위 개념의 방법론에 해당되며 크랙과 리버스 엔지니어링을 동일시하면 안된다. 즉, Crack != Reverse Engineering 이다!)

크랙 : Crack. 특정 보호장치를 무력화하거나 우회하거나 해제하는 일련의 소프트웨어 기술.

릴한다/릴되었다 : Release. 해방시키다 해제하다는 의미이지만 SW에 있어서 릴리즈(혹은 릴리스)는 흔히 공개한다는 의미로 해석하면 된다.

R.I.P(립/립버전) : Rest In Peace. 편히 잠들다라는 의미. 소프트웨어에서는 보호장치를 잠재워버렸다(즉 크랙을 말한다)거나 특정 구성요소를 잠재워버렸다(삭제했다)라는 의미로 쓰인다.

NFO : 아마도 모르는 사람이 대단히 많을 거라고 생각된다. 크랙과 함께 배포된 작은 텍스트 파일로 구성된 이 파일은 해당 크랙에 대한 정보를 담고 있다. 인포메이션, 즉 정보 iNFOrmation 를 의미하며 대개 이 NFO 파일에는 크랙한 팀에 대한 간단한 소개, 프로그램 정보, 보호장치 정보, 메일주소, 시리얼, 크랙판 설치방법 등이 설명되어 있다.

와레즈 : softWARES. 소프트웨어를 말하며 와레즈는 상용 프로그램을 크랙이나 키젠과 함께 배포하는 커뮤니티를 말한다. 해커(또는 크래커)들은 특정 문자를 숫자로 대체하거나 특정 알파벳을 다른 알파벳으로 바꾸어 적기를 좋아하는데 이 경우 와레즈의 경우 S를 Z로 바꾸어 표기한 것 뿐이다. 과거에 해커들 사이에서 유행한 것이 의미도 모른채 일반인들도 사용하기 시작했다. 대개 이러한 표기법은 유행을 많이 탄다.

──────────────────────────────────────────────────────────────────

첫번째 이야기를 읽어 보았다면 그리고 당신이 소프트웨어 개발자라면
크랙을 막기 위한 방법 따위는 지구상에 존재하지 않는다는 것을 알고 있다.

먹고 살기 힘든 세상.. 크래커들은 왜 그리 타인의 지적소유물을 크랙하고 배포하려 안달이 난 것일까?

 01. 단순한 지적 호기심

사실 이 경우는 솔직히 눈감아 줄 수 있다.
단지 소프트웨어의 보호 장치를 연구하고 크랙 그 자체를 즐기며 크랙을 밥먹듯이 하고 LOCK를 깨는데 많은 시간을 할애하고 데이트보다 크랙을 즐기는 사람은 거의 모두 프로그래밍에 대해서 잘 아는 사람이며 실력 또한 대부분의 고수인 경우가 많다.


단지 멋있어 보여서 또는 크랙을 만들어 돈을 조금 벌어보고 싶은 마음에 시작하여 인터넷 상의 크랙미나 HowTo 문서 몇 개 읽고는 밥먹는 것처럼 쉽게 LOCK을 깨지는 못한다. 대개 이러한 연구 목적인 리버서의 경우 같은 소프트웨어 개발자로서 충분히 이해해 줄 수 있으며 정말 선의의 목적으로 리버싱을 하는 사람들은 오히려 우리에게 취약점을 보고해줄지도 모른다. 본인도 시리얼과 관련된 취약점을 메일로 받아본 적이 있다. 이러한 리버서 분들은 정말이지 감사할 따름이다.

단순한 지적 호기심으로 연구 목적 그 자체로 크랙을 즐기는 사람들은 타인이 만든 보호장치를 무력화하면서 그에 따른 희열을 느낀다고나 할까? 아무튼 이러한 사람들은 LOCK을 깼다고 특정 SW를 재배포하거나 그 방법을 유포하지는 않는 사람들이다.

 02. 두번째, 돈과 명예

국외에서 전문적으로 활동하는 크래커들이 이 부류에 속한다. 특정 소프트웨어를 재빠르게 릴리즈하는데 그 목적을 두며, 대부분이 크랙 또는 시리얼을 운영하는 와레즈 사이트와 연계되어 대부분이 돈을 받고 크랙하여 그 크랙을 와레즈에 제공함으로서 운영된다. 철저한 그룹제로 운영되며 멤버 한명을 뽑는데에도 상당한 조건을 따진다. 물론 조건이라 함은 오직 실력(Coding/Cracking/Release/Supplies)이며 온라인상에서는 그룹 id로만 활동하고 나머지는 베일에 가려져 있어 멤버가 누구인지는 모른다. 당연한 이야기지만 이들은 모두 불법을 저지르기 때문에 대놓고 활동할 수가 없다.

 03. 세번째, 어설픈 명예

무개념, 무뇌아로 일컬어지는 이 집단은 소수의 회원제 또는 개인으로 행동한다.
특정 SW를 보호장치를 해제함으로서 느껴지는 기쁨과 성취감에 도취되어 상용 소프트웨어의 크랙이나 키젠을 드러내놓고 공개한다.

이러한 크랙이나 키젠 따위를 공개함으로서 타인으로부터 대단한 사람이라는 인식을 심어주고 싶어 안달이 난 인간들이 대부분이지만 이들 역시 불법이 대부분이라서 이들의 미성숙한 생각과는 달리 알아주는 사람도 별로 없고 지지하는 사람들도 별로 없다. 아~ 몇 몇 사용자들로부터 OO님 최고!! 감사합니다 라는 댓글 한줄 따위는 볼 수 있겠다.

뭐 여러가지 목적과 범주가 있겠지만 이 정도로 압축은 가능하다.

그럼 이제 우리의 주적을 한번 알아보자.
아래 그룹들은 주로 유틸리티 소프트웨어를 전문적으로 크랙/공개하는 집단이다.

ROR, CORE, CiM, Lz0, Orthodox, ARN, nitrous, DVT, EXPLOSiON, HERiTAGE, The Black Riders Cult, CFF, rg, TEAM EMBRACE, RAZOR1911, DWP, Team F4CG, heritage, crude, TEAM ZERO WAiTiNG TiME

사실 정말 많다...내가 가진 리스트는 이것보다 더 많긴 한데, 활발히 운영되는 그룹들을 중심으로 필터링했다.

자 그럼 이제 본격적으로 1편에 했던 이야기들과 이어서 크랙과 관련된 흥미로운 이야기를 해보자.

10. 다중 보호, 다중 난도질

1편에서도 이야기했지만 소프트웨어를 공개하면 또한 그것이 셰어웨어라면 크랙은 시간문제이고 이길 수 없는 게임이니 담담히 받아들이라고 했다. 그리고 어차피 크랙당하는거 최대한의 어려움을 주고 크래커를 짜증나게 하는데 목적이 있는 글이라고도 했으니 오해는 없길 바란다.

다중 보호? 다중 난도질? 이게 뭔 헛소리인가?
다중 보호라는 말은 한가지만으로 보호되는 소프트웨어의 불법복제 장치를 여러 개 만들어 두라는 의미이다.

선뜻 이해가 가지 않는가? 그럼 더 쉽게 설명을 하겠다.
시리얼 넘버 1개로 소프트웨어를 보호해 왔다면 보다 적극적으로 여러가지의 보호장치를 두라는 말이다.

당장 인터넷을 둘러보고 우리가 많이 사용하는 소프트웨어들을 보자.
시리얼넘버만 입력하면 100% 모든 기능을 사용할 수 있는 소프트웨어가 천지이다.
대체 뭐냐 이건? 우리 모두 소프트웨어를 만드는데 얼마나 많은 노력이 들어가는지 알고 있지 않나..
근데 시리얼넘버 1개에만 의존하다니...그러지 말자.

나는 시리얼넘버 1개만 사용하여 SW를 보호하는 의견에 절대 반대이다.
검색을 통해서 손쉽게 구할 수 있는 것이 소프트웨어이고 시리얼 넘버이다. 시리얼 넘버만으로 소프트웨어를 보호하겠다는 생각은 인터넷 사용이 불가능한 무인도에서나 가능한 것이지 현재 시리얼넘버에만 의존한다는 것은 소프트웨어 퍼주기와 다를 바 없다.

그럼 어떻게 하라는 말인가?
쉽게 생각하자. 여러가지의 보호장치를 만들자는 말이다.
사용자가 시리얼을 입력했으면 시리얼과 함께 유니크 ID를 생성하거나 하드웨어에 의존적인 새로운 프로덕트 ID를 생성하거나 또 거기에 더해서 서버로 전송하여 중복 체크를 한다던지 유효성 검사를 한다던지 설치된 모든 파일에 대한 체크섬을 생성해서 서버의 체크섬과 비교해서 신규 버전에 과거 시리얼을 사용하려는것은 아닌지 이러한 복합적인 방법으로 소프트웨어를 보호해야 한다는 것이다. 1가지 보호장치만 더해도 더 극적으로 소프트웨어를 보호할 수 있다.

그럼 두번째, 난도질하라....흠 이게 사실이라면 조금 무섭다.
그러나 여기서는 코드를 난도질하라는 의미이다. 1편에서 이야기 한 내용을 보다 확장해서 생각해보자.
그리고 크래커의 입장에서 생각해보자.

당신은 셰어웨어 또는 상용 소프트웨어를 만들었고

 - 설치 전 시리얼넘버를 입력하도록 하고

 - 설치 후 시리얼넘버를 서버에 전송해서 이미 등록된 키가 있는지 없는지 또는 유효한지 체크

하려 했다면 크래커는 2부분만 손보면 깔끔한 크랙이 되어 소프트웨어를 쉽게 사용할 수 있게 된다.

여기서 난도질이 필요하다.
이렇게 고정적으로 설치 전, 설치 후 마치 누구나 그렇게 하듯이 만들지 말고
소프트웨어의 정상적인 특정 기능을 수행할 때 다른 보호장치의 액션을 추가해라.
가령 예를 들어서 위에 2가지 보호장치에 다음과 같은 보호장치를 추가하면 어떨까?

 - 사용자가 파일(소프트웨어에서 사용하는)을 열고 편집하려 할 때 3일에 한번 실행될 확률로서
   사용자의 시리얼넘버와 이더넷 카드 맥어드레스를 서버로 전송하는 기능

 - 전송하고 결과를 받은 후 이미 등록된 시리얼넘버라면 앞으로 2번째 실행 후 사용이 불가능하도록 한다

자 이렇게 되면 어떨까?


크래커의 입장에서는 한마디로 욕나오게 된다.
디스어셈블된 코드를 면밀히 조사하거나 해당 소프트웨어의 특정 기능을 실행할 때마다 보호장치가 실행되게 만들어 놓으면 일단 거의 모든 코드를 조사해야만 한다.


크래커가 분석해야할 분량은 방대하고 언제 어떤 보호장치가 튀어나올지 모르기 때문에 상당히 짜증나며 심지어 크랙을 완벽하게 끝마쳤다고 의의양양해 있겠지만 누군가의 "등록된 키라고 나오면서 사용이 안되는데요!!" 따위의 리포트로 인해서 크래커는 아마도 상당히 혼란스러울 것이다.

코드 자체는 상당히 지저분 해지겠지만 효과는 그 이상일 것이다.
만약 코드가 복잡해지길 싫어한다면 셰어웨어 버전을 위해서 하나쯤 버전을 하나쯤 브렌치하는 것도 하나의 방법이 될 수 있겠다. 아 먹고 살기 힘드네...ㅜ_ㅜ

11. 힌트? 그 딴건 없다!

힌트를 주지말자. 왜 힌트를 주려 하는가?
사용자가 시리얼넘버를 말도 안되게 입력하던지, 사용자 이름과 시리얼이 매치가 되어야 함에도 전혀 매치되지 않는다던지, 셰어웨어로 공개했는데 15일의 기간이 남아있던지, 실행회수 제한을 걸었는데 7번의 실행이 남아 있다던지 이러한 힌트를 주지마라.

프로그램을 실행할 때마다 "등록을 하세요! 지금 등록하시면 모든 기능을 100% 사용할 수 있답니다!" 처럼 등록을 유도하는 내그(NAG)스크린 따위도 띄우지마라.

어차피 구매할 사용자라면 신경도 쓰지 않을 뿐더러 구매하지 않을 사용자라 할지라도 알고 다운받을 것이다.
프로그램 소개에 30일 사용제한, 30번 사용제한 이런 설명이면 충분하다. 사용자는 신경도 쓰지 않는다.

우리는 크래커의 입장에서 생각해야 한다고 했다.
크래커의 입장에서는 이러한 메시지는 정말이지 고맙기도 하다. 만약 소프트웨어에 내그 스크린이나 메시지 박스를 띄워서 보여준다면 "크래커님 이 부분에 브포를 걸어주세요!" 라고 말하는 것과도 같다.


아마도 이러한 메시지를 읽게 되면 크래커는 힌트를 찾았다는 듯이 살포시 웃으며 해당 프로그램을 닫고 올리나 IDA를 실행시켜 해당 부분에서 브포를 걸어보자는 생각과 함께 일이 쉽게 진행될 것 같다며 담배를 물지도 모른다...-_-;

그리고 두번째.
여러분의 소프트웨어가 25자리로 구성된 시리얼넘버를 갖게된다고 가정하자.
사용자 편의를 위해서 문자 5개씩 입력할 수 있는 에디트박스를 5개를 둘 것인가? 아니면 길다란 에디트박스 1개를 덩그러니 놓을 것인가? 당연히 두번째다.

아무것도 하지않고 크래커에게 "우리 소프트웨어는 25자리의 시리얼넘버로 구성되어 있습니다! 건투를 빌어요!!" 라고 알려주는 것과도 같다.

그러지말자. 크래커 스스로가 알아내도록 하자. 물론 크래커는 몇자리로 구성된 시리얼인지 대소문자는 체크하는지 시리얼은 어떻게 구성되는지에 대해서 당연히 알아낸다.


물론 5자리씩 입력할 때마다 포커스를 설정해두어 사용자의 편의를 고려해야 하는 부분은 무시되겠지만, 실제로 정품을 구입한 사용자라면 어서 빨리 설치하고 실행하고 싶은... 기쁜(?) 마음으로 시리얼을 입력할 것이다.

또한 중요한 부분으로 메시지박스나 다이얼로그 등을 통해서 절대 힌트는 주지도 말고 모든 일은 내부적으로 조용히 처리하도록 하며 보여줘야 할 메시지들은 모두 암호화한다.

절대 Hex Editor로 열어서 검색되지 않도록 하자.

힌트를 아무것도 찾지 못한 불쌍한 Newbie 크래커들은 닥버(닥치고 Burrow)하게 될지도 모른다.

/*

내그 스크린에 관련된 추억

95년도 당시에 꽤나 유명한 소프트웨어였는데 OOOO Viewer라고 있었습니다. 지금은 사라졌죠.
당시엔 이 프로그램은 셰어웨어로서 매달 PC사랑이나 HowPC등에 부록CD에 함께 제공되었는데
이 프로그램은 기간 제한이 있는 셰어웨어로서 프로그램을 시작하면 다이얼로그를 띄워서 몇 일 사용기간이 남았다고 알려주며 3초가 지나면 창이 자동으로 닫히도록 만들어져 있어서 꽤나 불편함을 초래했습니다.

전 WinHex로 해당 실행 파일을 열고 여기 저기 둘러보았는데 해당 내그 스크린을 보여주는 부분이 항상 00 20 00 이라는걸 알아내었습니다. 물론 이 00 20 00 이라는 수치는 다이얼로그에서 보여주는 메시지를
Hex Editor에서 검색하고 해당 스트링이 위치한 곳에서 가장 앞쪽에 있는 수치입니다.


00 20 00을 00 00 00 으로 변경하고 저장하였을 때 놀랍게도 다이얼로그는 띄우지 않았습니다. 당연히 해당 다이얼로그에 설정된 타이머도 사라지기에 무의미한 3초를 기다리지 않아도
사용할 수 있었습니다. -_-;


비록 30일이라는 시간제한은 없애지 못하였지만 단순 Hex Editor만으로 내그 스크린을 없앤 것이었습니다.
더욱 놀라운 것은 다른 윈도우 응용 프로그램(특히 셰어웨어도)도 같은 방법으로 모든 내그 스크린을 없앨 수 있다는 것을 알고는 충격에 휩쌓인 적이 있었습니다.

따라서 때로는 별것 아닌 것처럼 보이는 HINT도 프로그램에 상당히 치명적일 수 있음을 말하고 싶습니다.

*/


소프트웨어 개발자들이 보호장치를 넣는 이유는 무엇일까?
단지, 불법복제를 막기 위해서? 팀장 혹은 사장이 시켜서? 지적재산권을 보호하기 위해서?


바로 불법복제를 방지함으로서 회사의 수익을 극대화하는 것이 주목적이다.
일단 공개하면 무조건 크랙된다고 첫번째 이야기와 여기에서도 몇 번이나 강조했다.


보호장치에 있어서 몇가지 예를 통해서 절대 HINT는 금물이라는 것을 상기하자.


예제로 다음과 같이 CD Space 6를 보자.

자 몇가지 보호장치와 연계되어 있다고 의심이 드는 파일명이 있다.
왜? 왜? 왜? 왜? 이렇게 대놓고 알려줘야 하나?
어차피 크랙당하는건 불보듯 뻔한건데 보기와 같이 힌트를 주고 있다. 왜 이렇게 해야 하는지 알 수가 없다.


CD Space 5에는 내 기억이 맞다면 LicenseMgr.exe가 있었는데 너무 노골적이라 생각했던지
버전 6에서는 파일명을 바꾸었다. 그게 뭘까?
바로 cdscrm.exe 가 그것이다. 딱 봐도 알겠다.
CDSpace LiCense (R)....? Manager 요걸 줄여서 cdsrcm.exe라고 한게 틀림없다...OTL


이렇게 힌트를 줌으로서 크랙에 크자도 모르는 사람이라 할지라도 우회할 수 있는 여지를 만들어 두게 된다.
버전 5에서는 해당 LicenseMgr.exe만 지우면 사용 가능하다는 단점이 있었다.


버전 5에서 사용했던 방법이 너무 노골적이라 생각했는지 버전 6에는 파일 존재 유무는 체크한다.
따라서 해당 파일이 없으면 다음과 같이 경고를 하고 프로그램 실행이 되지 않는다.

말 그대로 시디스페이스 버전6에서는 cdscrm.exe 파일의 존재 유무만 체크한다.


즉 그말은 결국 아무 EXE파일을 CDSCRM.EXE로 바꾸어도 실행에 관계가 없다는 뜻이다.
당장 콘솔용 헬로 월드를 하나 만들어서 EXE를 대체해보자. 와우 축하드립니다. 크랙하셨네요^^.....-_-;


대체 왜 이래야 하나?
물론 파일 이름만으로 거론하는 것은 아니다.
본인이 대학교 졸업후 첫번째로 입사한 회사에서 두번째로 한 일이 바로 블로그에 적었던 일과 같은
시디키 라이브러리를 만드는 작업이었는데 그 때 파일이름이 엘 아이 씨 엘 아이 비.DLL이었다...
..................................................................................LICense LIBrary.....OTL


아무리 다른 파일 이름이라 할지라도 크래커는 알아낸다. 아니 뭔 짓거리를 해도 알아낸다구요!
그렇지만 이렇게 대놓고 힌트를 줄 필요가 있을까요?


라이센스와 관련있다고 꼭 파일이름을 그렇게 할 필요는 없을 뿐더러 한다고 했으면 보호 장치를 위한
보호 장치 하나쯤 더 만들어 두어야 하는게 정상 아닌가 하는 생각이 든다.
두번째 이야기는 이쯤에서 마무리하고 못다한 이야기는 세번째 이야기에서 하겠습니다.


두번째 이야기의 결론...아놔 먹고 살기 힘드네 ㅜ_ㅜ


관련 코드를 기대하거나 자세한 기법을 원하는 분들도 있을테지만, 코드나 기법을 남기지는 않겠습니다.
추상적인 이야기만 했지만 뛰어난 프로그래머가 되기 위해서는 추상적인 면만 보고도 훌륭하게
실제 세상에서 적용할 수 있도록 구현할 수 있어야 합니다. 그것이 우리 프로그래머가 해야할 일이죠.