소규모 공급업체를 위한 소프트웨어 보호

Question

이것은 우리 모두가 언젠가는 고려해야 할 문제입니다.

수년간의 다양한 접근 끝에 나는 다음 진술에 일반적으로 동의하는 경향이 있습니다."수백 명이 넘는 사람들이 사용하는 보호된 소프트웨어의 경우 크랙된 버전을 찾을 수 있습니다.지금까지 모든 보호 체계는 변조될 수 있었습니다."고용주가 불법 복제 방지 소프트웨어 사용을 강요합니까?

더욱이, 내가 이 주제에 대해 포스팅할 때마다 누군가가 나에게 상기시켜 줄 것입니다."우선, 어떤 종류의 보호 장치를 사용하더라도 진정한 헌신적인 크래커는 결국 모든 보호 장벽을 통과하게 될 것입니다."단일 개발자를 위한 최고의 비용 대비 C# 코드 보호는 무엇입니까?

따라서 이 두 가지 폭넓은 면책 조항에도 불구하고 "보호"에 대해 이야기해 보겠습니다.

숙련된 크래커의 시간과 주의를 끌 수 없는 작은 앱의 경우 보호는 가치 있는 활동이라고 생각합니다.

당신이 무엇을 하든 크래커가 애플리케이션을 패치하여 IF 문(jmp)의 결과를 바꿀 수 있다면 세상의 모든 비밀번호와 동글이 도움이 되지 않을 것이라는 점은 분명해 보입니다.

그래서 나의 접근 방식은 다음과 같은 제품을 사용하여 가상화로 코드를 난독화하는 것이었습니다.http://www.oreans.com/codevirtualizer.php나는 이 제품에 매우 만족했습니다.내가 아는 한 그것은 패배한 적이 없습니다.Pecompact로 실행 파일을 압축 할 수도 있습니다. 다른 사람이 경험이 있습니까?

EXEcryptor에 문제만 있었습니다http://www.strongbit.com/news.asp사이트조차도 사용하기가 어렵습니다.WMI 호출을 수행하면 컴파일된 앱이 충돌합니다.

이 접근 방식을 사용하면 더 작은 코드 섹션을 난독화하여 보안 검사 등을 보호할 수 있습니다.

I 애플리케이션에는 정기적으로 서버의 데이터가 필요하므로 사용자가 장기간 오프라인으로 사용하는 것은 의미가 없으므로 온라인 인증 접근 방식을 사용합니다.정의에 따르면 앱은 크랙이 발생하더라도 그 시점에서는 쓸모가 없습니다.

따라서 간단한 암호화된 악수만으로도 충분합니다.난독화 보호 내에서 가끔 확인하곤 합니다.사용자가 다른 컴퓨터에 앱을 설치하는 경우 시작 시 새 ID가 업로드되고 서버는 이전 ID를 비활성화하고 새 인증을 반환합니다.

또한 컴파일된 앱의 해시를 사용하고 실행 시 단일 비트가 변경되었는지 확인한 다음 앱을 앱 내에서 파일(읽기 LOCK 사용)로 열어 실행 후 다른 사람이 변경하는 것을 방지합니다.

모든 정적 문자열은 .exe 파일에 명확하게 표시되므로 오류 메시지 등을 일반화하려고 노력합니다."Authorization failed"라는 문자열은 어디에서도 찾을 수 없습니다.

메모리 덤프를 방지하기 위해 간단한 텍스트 난독화 기술(예: 모든 문자를 XOR)을 사용합니다. 이렇게 하면 메모리의 일반 텍스트 데이터를 변수 등과 구별하기가 더 어려워집니다.

물론 매우 민감한 데이터에는 AES가 있습니다.저는 텍스트에 대한 카운터 모드를 좋아합니다. 이렇게 하면 일련의 공백과 같은 기본 데이터를 드러내는 반복 시퀀스가 ​​발생하지 않기 때문입니다.

그러나 이러한 모든 기술을 사용하여 키 또는 초기화 벡터를 메모리에서 덤프할 수 있거나 IF 문을 우회할 수 있다면 모든 것이 낭비됩니다.

나는 조건문보다는 스위치문을 사용하는 경향이 있다.그런 다음 실제로 원하는 작업을 수행하는 함수 대신 기본적으로 막다른 골목인 두 번째 함수를 만듭니다.

또 다른 아이디어는 변수를 추가하여 포인터를 코딩하는 것입니다.변수는 인증의 결과입니다(일반적으로 0).이는 어느 시점에서는 불가피하게 GPF로 이어질 것입니다.몇 가지 낮은 수준의 인증이 실패한 후 최후의 수단으로만 이 방법을 사용합니다. 그렇지 않으면 실제 사용자가 이 문제를 겪을 수 있습니다.그러면 소프트웨어의 평판이 낮아집니다.

어떤 기술을 사용합니까?

(이것은 무언가 구현의 장점을 논의하는 스레드가 아닙니다.뭔가를 하기로 결정한 사람들을 위해 설계되었습니다)

Answer 1

나는 xsl에 동의하지 않습니다.

우리는 우리의 코드를 보호합니다. 우리의 수익을 보호하기 위해서가 아닙니다. 우리는 라이선스 없이 사용하려는 사람들이 어쨌든 코드 비용을 지불하지 않을 것이라는 점을 인정합니다.

대신, 우리는 투자를 보호하기 위해 그렇게 합니다. 우리의 고객이 만든 우리의 소프트웨어.우리는 우리 소프트웨어를 사용하면 시장에서 더욱 경쟁력을 갖게 되며, 다른 회사가 비용을 지불하지 않고 해당 소프트웨어에 액세스할 수 있다면 불공평한 이점을 갖게 된다고 믿습니다. 즉, 라이센스 비용에 대한 간접비 없이도 경쟁력을 갖게 되는 것입니다.

우리는 자체적으로 개발된 보호 기능이 유효한 사용자에게 가능한 한 방해가 되지 않도록 매우 주의를 기울이고 있으며, 이를 위해 이에 영향을 미칠 수 있는 기성 솔루션을 '구매'하는 것을 결코 고려하지 않습니다.

Answer 2

소프트웨어를 크랙하는 데 수백 명의 사용자가 필요하지 않습니다.저는 셰어웨어가 여러 번 깨지는 것에 짜증이 나서 실험으로 Magic Textbox라는 프로그램(텍스트 상자가 있는 형식일 뿐임)을 만들어 셰어웨어 사이트에 공개했습니다(자체 PAD 파일과 모든 것이 포함되어 있음). ).하루 후 Magic Textbox의 크랙 버전이 출시되었습니다.

이 경험으로 인해 저는 기본적인 복사 방지 이상의 기능으로 소프트웨어를 보호하려는 시도를 거의 포기하게 되었습니다.

Answer 3

나는 개인적으로 코드 기술을 사용합니다 여기서 논의됨.이러한 트릭은 합법적인 최종 사용자의 삶을 더 어렵게 만들지 않으면서 해적을 불편하게 만드는 이점이 있습니다.

하지만 더 흥미로운 질문은 '무엇'이 아니라 '왜'입니다.소프트웨어 공급업체가 이러한 유형의 연습을 시작하기 전에 위협 모델을 구축하는 것이 매우 중요합니다.예를 들어 저가형 B2C 게임의 위협은 고가치 B2B 앱의 위협과 완전히 다릅니다.

Patrick Mackenzie는 좋은 에세이를 가지고 있습니다. 몇 가지 위협에 대해 논의합니다., 4가지 유형의 잠재 고객 분석을 포함합니다.비즈니스 모델을 보호하기 위한 선택을 하기 전에 자신의 앱에 대해 이러한 위협 분석을 수행하는 것이 좋습니다.

Answer 4

저는 하드웨어 키잉(동글)을 먼저 구현해 본 적이 있어서 이 문제가 전혀 익숙하지 않습니다.사실 저는 그것에 대해 많은 생각을 했습니다.나는 당신의 크래커처럼 저작권법을 위반하는 사람의 의견에 동의하지 않습니다.귀하의 소프트웨어 사본을 합법적으로 취득하고 싶지 않은 사람은 소프트웨어 사본을 취득하지 말아야 합니다.나는 소프트웨어 저작권을 위반한 적이 없습니다.그러고보니...

저는 여기서 사용된 "보호"라는 단어를 정말 정말 싫어합니다.당신이 보호하려는 유일한 것은 당신의 통제.당신은 ~ 아니다 소프트웨어를 보호합니다.사용자와 마찬가지로 소프트웨어도 어느 쪽이든 괜찮습니다.

사람들이 귀하의 소프트웨어를 복사하고 공유하는 것을 막는 것이 그렇게 불경스러운 PITA인 이유는 그러한 활동을 방지하는 것이 부자연스럽기 때문입니다.컴퓨터의 전체 개념은 데이터 복사를 중심으로 이루어지며, 유용한 것을 공유하고 싶은 것은 인간의 단순한 본성입니다.정말로 주장한다면 이러한 사실에 맞서 싸울 수 있지만, 그것은 평생의 싸움이 될 것입니다.하나님은 인간을 다르게 만드시지 않으며, 나는 복사할 수 없는 컴퓨터를 구입하지도 않습니다.아마도 일하는 방법을 찾는 것이 더 나을 것입니다. ~와 함께 컴퓨터와 사람과 항상 싸우기보다는요?

나는 대부분의 전문 소프트웨어 개발자들과 함께 사용자에게 "판매"하기 위해 인위적으로 부족한 "소프트웨어 제품"을 갖기 위한 것이 아니라 비즈니스를 수행하기 위해 개발된 소프트웨어가 필요한 회사에 정규직으로 고용되어 있습니다.일반적으로 유용한 것(여기서는 "경쟁 우위"로 간주되지 않음)을 작성하면 이를 자유 소프트웨어로 출시할 수 있습니다."보호"는 필요하지 않습니다.

Answer 5

일부 링크에서:

제가 설명하려고 했던 개념은 제가 "균열 확산"이라고 부르는 것입니다.귀하의 애플리케이션에 크랙(또는 키 생성기, 불법 복제품 등)이 존재하는지 여부는 중요하지 않습니다.중요한 것은 얼마나 많은 사람들이 크랙에 접근할 수 있느냐는 것입니다.

일련번호 확인 장소/시기:시작할 때 한 번 확인합니다.많은 사람들이 "모든 종류의 장소를 확인하세요"라고 말합니다. 이는 누군가가 수표를 벗겨서 해독하기 어렵게 만들기 위한 것입니다.크래커를 특별히 공격하고 싶다면 인라인 코드(예:모든 것을 SerialNumberVerifier.class로 외부화하지 마세요. 가능하다면 다중 스레드로 만들고 실패할 때 인식하기 어렵게 만드세요.그러나 이것은 크랙을 만드는 것을 더 어렵게 만들 뿐 불가능하지는 않습니다. 그리고 여러분의 목표는 일반적으로 크래커를 물리치는 것이 아니라는 것을 기억하십시오.크래커를 물리친다고 해서 상당한 돈을 벌지는 않습니다.대부분의 경우 일반 사용자를 물리치기만 하면 되며 일반 사용자는 디버거에 액세스할 수 없고 사용 방법도 모릅니다.

집에 전화를 걸려면 사용자 정보를 가지고 집에 전화를 걸어 일련번호를 서버 스크립트의 출력으로 받아들여야 합니다. 일련번호로 집에 전화하고 부울 등을 출력으로 받아들이면 안 됩니다.즉.키 확인이 아닌 키 삽입을 수행해야 합니다.키 검증은 궁극적으로 애플리케이션 내에서 이루어져야 하므로 공개 키 암호화가 이를 수행하는 가장 좋은 방법입니다.그 이유는 인터넷 연결도 적의 손에 달려 있기 때문입니다 :) 소프트웨어가 단지 인터넷에서 부울 값을 읽기를 기대한다면 당신은 한 번만 실행하면 어디에서나 실행되는 공격에서 벗어나 호스트 파일을 변경하는 것입니다.

"흥미롭거나" "도전적인" 보호 조치를 취하지 마십시오.많은 크래커들은 지적 도전만으로 크래킹을 합니다.보호 기능을 깨지기 어렵지만 최대한 지루하게 만드세요.

패치할 위치를 찾기 위해 바이트 패턴을 검색하는 일부 크랙이 있습니다.일반적으로 재컴파일로 해결되지는 않지만 .EXE가 ASProtect, Armadillo 등에 의해 압축된 경우 이러한 종류의 크랙은 먼저 .EXE의 압축을 풀어야 합니다.ASProtect와 같은 좋은 패커를 사용하는 경우 크래커는 SoftICE와 같은 어셈블리 수준 디버거를 사용하여 수동으로 EXE의 압축을 풀 수 있지만 .EXE의 압축을 자동으로 풀는 도구를 만들 수는 없습니다. 이후 바이트 패치).

Answer 6

xsl은 많은 가정이 내장된 매우 좁은 관점입니다.

귀하가 제어하는 ​​서버에서 무언가를 전달하는 데 의존하는 모든 앱은 누가 유효한 계정을 가지고 있는지 파악하는 데 꽤 능숙할 수 있어야 한다는 것이 제가 보기에는 분명합니다!

나는 또한 정기적인 업데이트(다른 위치에 코드가 포함된 새로 컴파일된 앱을 의미함)로 인해 크랙이 발생한 버전이 빨리 쓸모 없게 될 것이라고 믿습니다.앱이 서버와 통신하는 경우 매주 기본 실행 파일을 교체하기 위해 보조 프로세스를 시작하는 것은 매우 쉽습니다.

그렇습니다. 깨지지 않는 것은 없지만 영리하고 본질적인 디자인을 사용하면 논란의 여지가 있습니다.중요한 유일한 요소는 크래커가 그것에 기꺼이 소비하는 시간과 잠재 고객이 매주 또는 매일 노력의 산물을 찾으려고 얼마나 많은 노력을 기울이는가입니다!

나는 귀하의 앱이 유용하고 가치 있는 기능을 제공한다면 그들은 그에 대해 합당한 가격을 기꺼이 지불할 것이라고 생각합니다.그렇지 않다면 경쟁 제품이 시장에 출시될 것이고 귀하의 문제는 저절로 해결될 것입니다.

Answer 7

나는 과거에 .NET Reactor를 사용해 좋은 결과를 얻었습니다. http://www.eziriz.com/

이 제품에서 제가 마음에 들었던 점은 꽤 좋은 보호를 위해 코드를 난독화할 필요가 없다는 것입니다.