리버스 엔지니어링으로부터 실행 파일을 보호 하시겠습니까?

C / C ++ 코드를 디스 어셈블리 및 리버스 엔지니어링으로부터 보호하는 방법을 고민해 왔습니다. 일반적으로 나는이 행동을 내 코드에서 결코 용인하지 않을 것이다. 그러나 내가 작업했던 현재 프로토콜은 다양한 사람들의 보안을 위해 검사되거나 이해되어서는 안됩니다.

이제 이것은 나에게 새로운 주제이며, 인터넷은 리버스 엔지니어링 을 방지하는 데 실제로 유용 하지는 않지만 리버스 엔지니어링 방법 에 대한 많은 정보를 묘사 합니다.

지금까지 내가 생각한 것 중 일부는 다음과 같습니다.

• 코드 삽입 (실제 함수 호출 전후에 더미 함수 호출)
• 코드 난독 화 (바이너리의 디스 어셈블리 엉킴)

• 내 자신의 시작 루틴을 작성하십시오 (디버거가 바인딩하기가 더 어렵습니다)

  void startup();  
  int _start()   
  {  
      startup( );  
      exit   (0)   
  }  
  void startup()  
  {  
      /* code here */  
  }

• 디버거의 런타임 검사 (및 감지되면 강제 종료)

• 기능 트램폴린

   void trampoline(void (*fnptr)(), bool ping = false)  
   {  
     if(ping)  
       fnptr();  
     else  
       trampoline(fnptr, true);  
   }

• 무의미한 할당 및 할당 해제 (스택 변경이 많음)

• 무의미한 더미 호출 및 트램폴린 (분해 출력에서 ​​뛰어 넘는 톤)
• 주조 톤 (난독 처리 된 분해 용)

나는 이것이 내가 생각한 것들 중 일부이지만, 적절한 시간 프레임이 주어지면 코드 분석가가 해결하거나 해결할 수 있습니다. 다른 대안이 있습니까?

앰버가 말한 것은 정확히 맞습니다. 리버스 엔지니어링을 더 어렵게 만들 수는 있지만 결코 막을 수는 없습니다. 리버스 엔지니어링 방지에 의존하는 "보안"을 절대 신뢰해서는 안됩니다 .

즉, 내가 본 최고의 역전 방지 기술은 코드를 난독 화하는 것이 아니라 사람들이 일반적으로 코드 작동 방식을 이해하는 데 사용하는 도구를 깨는 데 중점을 두었습니다. 디스어셈블러, 디버거 등을 깰 수있는 독창적 인 방법을 찾는 것이 끔찍한 스파게티 코드를 생성하는 것보다 효과적이고 지능적으로 만족할 수 있습니다. 이것은 결정된 공격자를 막을 수는 없지만 J 랜덤 크래커가 방황하고 대신 더 쉽게 일할 가능성을 높입니다.

그러나 적절한 시간 내에 주어진 코드 분석으로 해결할 수 있습니다.

사람들에게 실행할 수있는 프로그램을 제공하면 충분한 시간이 주어지면 리버스 엔지니어링 할 수도 있습니다. 이것이 프로그램의 본질입니다. 바이너리를 해독하려는 사람이 바이너리를 사용할 수있게되면 결국 리버스 엔지니어링을 막을 수 없습니다. 결국, 컴퓨터는 그것을 실행하기 위해 해독 할 수 있어야하며, 인간은 단순히 느린 컴퓨터입니다.

안전망 센티넬 (이전의 알라딘). 주의 사항-API가 빨라지고 문서가 빨라지며 SDK 도구와 비교할 때 두 가지 모두 훌륭합니다.

나는 그들의 하드웨어 보호 방법 ( Sentinel HASP HL )을 여러 해 동안 사용해 왔습니다. 소프트웨어의 '라이센스'역할을하는 독점 USB 키 포브가 필요합니다. SDK는 실행 파일과 라이브러리를 암호화하고 난독 처리하며 응용 프로그램의 다양한 기능을 키에 기록 된 기능과 연결할 수 있습니다. 라이센스 제공자가 제공하고 활성화 한 USB 키가 없으면 소프트웨어를 해독 할 수 없으므로 실행되지 않습니다. 키는 심지어 사용자 정의 된 USB 통신 프로토콜 (내 지식 범위 밖에서는 장치 드라이버 사용자가 아님)을 사용하여 가상 키를 작성하기 어렵게하거나 런타임 래퍼와 키 사이의 통신을 조작하는 것을 어렵게합니다. 그들의 SDK는 개발자에게 친숙하지 않으며 자동화 된 빌드 프로세스에 보호 기능을 추가하는 것은 상당히 고통 스럽습니다 (그러나 가능합니다).

HASP HL ​​보호를 구현하기 전에 제품에서 dotfuscator '보호'를 제거한 7 명의 알려진 해적이있었습니다. 우리는 소프트웨어에 대한 주요 업데이트와 동시에 HASP 보호 기능을 추가하여 실시간으로 비디오에 대해 많은 계산을 수행했습니다. 프로파일 링 및 벤치마킹에서 알 수 있듯이 HASP HL ​​보호는 집중적 인 계산 속도를 약 3 % 느리게합니다. 이 소프트웨어가 약 5 년 전에 출시 된 이후, 새로운 제품 해적은 발견되지 않았습니다. 그것이 보호하는 소프트웨어는 시장에서 수요가 높으며 고객은 현재까지 성공하지 못한 리버스 엔지니어링을 적극적으로 시도하는 여러 경쟁사를 알고 있습니다. 우리는 그들이 소프트웨어 보호를 깨뜨리는 서비스를 광고하는 러시아의 몇몇 그룹의 도움을 구하려고 노력했다는 것을 알고 있습니다.

최근에 작은 프로젝트에서 소프트웨어 라이센스 솔루션 (HASP SL)을 사용해 보았습니다. HL 제품에 대해 잘 알고 있다면 작업하기에 충분히 간단합니다. 작동하는 것 같습니다. 불법 복제 사건이보고 된 바는 없지만이 제품은 수요가 훨씬 적습니다.

물론 완벽한 보호 기능은 없습니다. 누군가 동기가 충분하고 화상을 입을 심각한 현금이 있다면 HASP가 제공하는 보호 기능을 우회 할 수 있다고 확신합니다.

특히 가변 워드 길이 명령어 세트에서 최고의 디스어셈블러 방지 트릭은 C가 아닌 어셈블러 / 머신 코드에 있습니다.

CLC
BCC over
.byte 0x09
over:

디스어셈블러는 분기 대상이 다중 바이트 명령어의 두 번째 바이트라는 문제를 해결해야합니다. 명령어 세트 시뮬레이터에는 아무런 문제가 없습니다. C로 인해 발생할 수있는 계산 된 주소로 분기하면 분해가 어려워집니다. 명령어 세트 시뮬레이터에는 아무런 문제가 없습니다. 시뮬레이터를 사용하여 분기 대상을 정렬하면 분해 프로세스에 도움이 될 수 있습니다. 컴파일 된 코드는 비교적 깨끗하고 디스어셈블러에게 쉽습니다. 그래서 일부 조립이 필요하다고 생각합니다.

Michael Abrash의 Zen of Assembly Language의 시작 부분에 가까운 간단한 디스어셈블러 및 안티 디버거 트릭을 보여주었습니다. 8088/6에는 프리 페치 대기열에 다음 명령 또는 몇 가지 명령을 수정 한 명령이있었습니다. 단일 스테핑 후 수정 된 명령을 실행 한 경우 명령 세트 시뮬레이터가 하드웨어를 완전히 시뮬레이션하지 않은 경우 수정 된 명령을 실행했습니다. 정상적으로 실행되는 실제 하드웨어에서 실제 명령어는 이미 대기열에 있으며 수정 된 메모리 위치는 해당 명령어 문자열을 다시 실행하지 않는 한 손상을 일으키지 않습니다. 파이프 라인 처리 된 프로세서가 다음 명령어를 가져 오기 때문에 오늘날에도 이와 같은 트릭을 사용할 수 있습니다. 또는 하드웨어에 별도의 명령어 및 데이터 캐시가 있음을 알고있는 경우이 코드를 캐시 라인에 올바르게 맞추면 여러 바이트를 미리 수정할 수 있습니다. 수정 된 바이트는 명령어 캐시를 통해 기록되지 않고 데이터 캐시 및 적절한 캐시 시뮬레이터가없는 명령어 세트 시뮬레이터는 제대로 실행되지 않습니다. 소프트웨어 전용 솔루션으로는 크게 멀지 않을 것 같습니다.

위의 내용은 오래되었으며 잘 알려져 있습니다. 현재 도구가 이미 그런 것들을 해결하고 있는지 알 수있는 현재 도구에 대해 충분히 알지 못합니다. 자체 수정 코드는 디버거를 트립 (트립) 할 수 있지만 사람은 문제를 좁힐 수 있고 자체 수정 코드를 확인하고 해결할 수 있습니다.

예를 들어 해커들은 DVD를 사용하여 무언가를 해결하는 데 약 18 개월이 걸렸습니다. 이제는 2 일에서 2 주 정도 (동기 부여 된 경우) (파란 광선, 아이폰 등)의 평균을 내고 있습니다. 보안에 며칠 이상을 투자하면 시간이 낭비 될 수 있습니다. 실제로 얻을 수있는 유일한 보안은 하드웨어를 통해서만 가능합니다 (예 : 명령어가 암호화되고 칩 내부의 프로세서 코어 만 실행 직전에 해독되어 해독 된 명령어를 노출 할 수 없도록합니다). 며칠이 아닌 몇 달이 걸릴 수도 있습니다.

또한 Kevin Mitnick의 저서 The Art of Deception을 읽으십시오. 그런 사람은 전화를 들고 회사 나 다른 부분의 관리자 나 다른 동료 또는 하드웨어 엔지니어라고 생각하는 시스템에 비밀을 전달할 수 있습니다. 그리고 당신의 보안은 날아갔습니다. 보안은 기술 관리에 관한 것이 아니라 사람도 관리해야합니다.

예를 들어 AES 알고리즘 을 생각해보십시오 . 매우 공개적인 알고리즘이며 매우 안전합니다. 왜? 두 가지 이유 : 그것은 많은 똑똑한 사람들에 의해 검토되었으며 "비밀"부분은 알고리즘 자체가 아닙니다. 비밀 부분은 알고리즘의 입력 중 하나입니다. 코드 자체를 비밀로 만드는 것보다 코드 외부에 생성 된 "비밀"로 프로토콜을 설계하는 것이 훨씬 더 나은 방법입니다. 코드는 사용자가 무엇을 하든지 항상 해석 할 수 있으며 생성 된 비밀은 방대한 무차별 대입 접근 또는 도난을 통해서만 위험에 처할 수 있습니다.

흥미로운 질문은 " 왜 코드를 난독 화하고 싶습니까?"라고 생각합니다. 공격자가 알고리즘을 해독하기 어렵게 만들고 싶습니까? 코드에서 악용 가능한 버그를 찾기 어렵게하려면? 처음에 코드를 해독 할 수없는 경우 코드를 난독 처리 할 필요가 없습니다. 문제의 근원은 깨지기 쉬운 소프트웨어입니다. 문제의 근원을 고치십시오. 난독 화하지 마십시오.

또한 코드를 혼란스럽게 만들수록 보안 버그를 찾기가 더 어려워집니다. 예, 해커에게는 어려울 것이지만 버그도 찾아야합니다. 코드는 몇 년 전부터 유지 관리하기 쉬워야하며 잘 작성된 명확한 코드도 유지 관리하기 어려울 수 있습니다. 악화시키지 마십시오.

역 엔지니어링하기 어려운 코드를 코드 난독 화라고합니다.

언급 한 대부분의 기술은 해결하기가 매우 쉽습니다. 쓸모없는 코드를 추가하는 데 중점을 둡니다. 그러나 쓸모없는 코드는 쉽게 감지하고 제거 할 수있어 깨끗한 프로그램을 만들 수 있습니다.

효과적인 난독 화를 위해서는 실행중인 쓸모없는 비트에 따라 프로그램의 동작을 만들어야합니다. 예를 들어, 이것을하기보다는 :

a = useless_computation();
a = 42;

이 작업을 수행:

a = complicated_computation_that_uses_many_inputs_but_always_returns_42();

또는 이것을하는 대신 :

if (running_under_a_debugger()) abort();
a = 42;

수행 (여기서이 running_under_a_debugger코드가 디버거에서 실행되고 있는지 여부를 테스트하는 기능을 쉽게 식별 할 수 안된다 - 그것은 디버거 탐지와 유용한 계산을 혼합한다) :

a = 42 - running_under_a_debugger();

효과적인 난독 처리는 컴파일 단계에서 순전히 할 수있는 것이 아닙니다. 컴파일러가 할 수있는 것은 무엇이든 디 컴파일러는 할 수 있습니다. 물론 디 컴파일러에 대한 부담을 증가시킬 수는 있지만 멀지 않을 것입니다. 효과적인 난독 화 기술은 존재하는 한 1 일부터 난독 화 된 소스를 작성하는 것과 관련이 있습니다. 코드를 자동 수정하십시오. 많은 수의 입력에서 파생 된 계산 된 점프로 코드를 처리하십시오. 예를 들어 간단한 전화 대신

some_function();

비트의 정확한 예상 레이아웃을 알 수있는 곳 에서이 작업을 수행하십시오 some_data_structure.

goto (md5sum(&some_data_structure, 42) & 0xffffffff) + MAGIC_CONSTANT;

난독 처리가 심각한 경우 계획에 몇 개월을 추가하십시오. 난독 화는 저렴하지 않습니다. 그리고 사람들이 코드를 리버스 엔지니어링하는 것을 피하는 가장 좋은 방법은 코드를 쓸모 없게 만들어 귀찮게하지 않는 것입니다. 경제적 인 고려 사항은 간단하다. 가치가 비용보다 크면 리버스 엔지니어링 할 것이다. 그러나 비용을 올리면 비용도 많이 들기 때문에 가치를 낮추십시오.

지금은 당신을 말 했어요 것을 난처 어려운 비싼, 나는 당신에게 말할거야 어쨌든 당신을 위해 아니다 . 당신은 쓰기

현재 작업중 인 현재 프로토콜은 다양한 사람들의 보안을 위해 검사하거나 이해할 수 없어야합니다.

그것은 붉은 깃발을 일으킨다. 그것은의 은둔 보안 매우 가난한 기록을 보유하고 있습니다. 프로토콜의 보안이 프로토콜을 모르는 사람들에게 의존한다면 이미 잃어버린 것 입니다.

추천 자료 :

• 보안 성경 : Ross Anderson의 보안 엔지니어링
• 난독 화 성경 : Christian Collberg와 Jasvir Nagra의 소프트웨어

많은 경우에, 리버스 엔지니어링 된 제품에 대한 두려움이 잘못되었습니다. 예, 리버스 엔지니어링 될 수 있습니다. 그러나 단기간에 너무 유명 해지면 해커가 역전을 피할 가치가 있음을 알게 될 것입니다. 그것은? (이 작업은 상당한 코드 라인을위한 작은 시간 활동이 아닙니다).

그것이 실제로 돈을 버는 사람이되면, 특허 및 / 또는 저작권과 같은 법적 방법을 사용하여 돈을 보호하기에 충분한 돈을 모아야합니다 .

IMHO, 기본 예방 조치를 취하고 해제하십시오. 만약 당신이 정말로 훌륭한 일을했다는 것을 의미하는 리버스 엔지니어링의 포인트가된다면, 당신은 그것을 극복하는 더 좋은 방법을 찾을 것입니다. 행운을 빕니다.

http://en.wikipedia.org/wiki/Security_by_obscurity#Arguments_against를 읽어보십시오 . 다른 사람들이 아마도 모호성에 의한 보안이 나쁜 이유에 대한 더 나은 출처를 제공 할 수 있다고 확신합니다.

현대의 암호화 기술을 사용하여 시스템을 열어 두는 것이 가능 해야 합니다 (나는 그것이 열려 있어야한다고 말할 수 는 없지만 가능할 것입니다). 구멍을 뚫고 (좋은 것을 선택하지는 않겠지 만) 개인 키 / 암호는 비공개로 유지되며 코드에 보안 구멍이 없습니다 ( 이것이 걱정해야 할 것입니다).

2013년 7월 때문에, (의 형태로 암호화 된 강력한 난독에 새롭게 관심이 Indistinguishability 난독 에서 독창적 인 연구에서 촉발 것 같습니다) 아 미트 사 하이가 .

• Sahai, Garg, Gentry, Halevi, Raykova, Waters, 후보 구분 불명료성 및 모든 회로에 대한 기능적 암호화 (2013 년 7 월 21 일).
• Sahai, Waters, 구별 할 수없는 난독 화 사용 방법 : 거부 가능한 암호화 등 .
• Sahai, Barak, Garg, Kalai, Paneth, 대수 공격으로부터 난독 화 방지 (2014 년 2 월 4 일).

이 Quanta Magazine 기사 와 해당 IEEE Spectrum 기사 에서 증류 된 정보를 찾을 수 있습니다 .

현재이 기술을 사용하는 데 필요한 자원의 양은 실용적이지 않지만 AFAICT의 합의는 미래에 대해 다소 낙관적입니다.

나는 이것을 매우 부담없이 말하지만 난독 화 기술을 본능적으로 무시하는 데 익숙한 모든 사람들에게 이것은 다르다. 그것이 실제로 작동하고 실용적으로 입증 된 경우, 이것은 난독 화를위한 것이 아니라 실제로 중요한 것입니다.

자신에게 알리려면 코드 난독 처리 에 대한 학술 문헌을 읽으십시오 . 애리조나 대학교의 Christian Collberg는이 분야에서 유명한 학자입니다. 하버드 대학교의 Salil Vadhan도 좋은 일을했습니다.

나는이 문헌에 대해 배후에 있지만, 내가 알고있는 본질적인 아이디어는 공격자가 실행할 코드를 보지 못하게 할 수는 있지만 실행 되지 않는 코드로 코드를 둘러 쌀 수 있다는 것입니다. 가장 잘 알려진 기술을 사용하여 공격자 지수 시간을 사용하여 코드의 어떤 조각이 실행되고 어떤 조각이 실행되지 않는지를 발견합니다.

" 프로그램 난독 화 및 일회성 프로그램 " 이라는 최근 논문이 있습니다 . 애플리케이션 보호에 대해 진지한 경우. 이 백서는 일반적으로 단순하고 보편적 인 하드웨어를 사용하여 이론적으로 불가능한 결과를 다루고 있습니다.

추가 하드웨어가 필요없는 경우 동일한 기능과 동일한 크기를 가진 모든 프로그램 중에서 이론적으로 가장 적합한 난독 화 " 최상의 가능한 난독 화"를 제공하는 다른 문서도 있습니다. 그러나이 논문은 정보 이론적으로 가장 좋은 것은 다항식 계층 구조의 붕괴를 의미한다는 것을 보여준다.

이러한 결과가 귀하의 필요에 맞지 않을 경우 관련 논문을 훑어 볼 수있는 충분한 서지 정보를 제공해야합니다.

업데이트 : 구별 할 수없는 난독 화라고 불리는 새로운 난독 화 개념은 불가능한 결과를 완화시킬 수 있습니다 (종이)

누군가 바이너리를 뒤집기 위해 시간을 보내고 싶다면 절대 멈추지 않아도됩니다. 적당히 더 어려울 수 있지만 그 정도입니다. 당신이 이것에 대해 정말로 배우고 싶다면 http://www.hex-rays.com/idapro/ 의 사본을 얻고 몇 개의 바이너리를 분해 하십시오 .

CPU가 코드를 실행해야한다는 것은 실행 취소입니다. CPU는 머신 코드 만 실행하며 프로그래머는 머신 코드를 읽을 수 있습니다.

그 말은 ... 당신은 다른 방법으로 해결할 수있는 다른 문제가있을 수 있습니다. 무엇을 보호하려고합니까? 문제에 따라 암호화를 사용하여 제품을 보호 할 수 있습니다.

올바른 옵션을 선택하려면 다음 측면을 고려해야합니다.

1. "새 사용자"가 소프트웨어를 지불하고 싶지는 않지만 소프트웨어를 사용할 가능성이 있습니까?
2. 기존 고객이 보유한 것보다 더 많은 라이센스가 필요할 가능성이 있습니까?
3. 잠재적 인 사용자는 얼마를 지불 하시겠습니까?
4. 사용자 / 동시 사용자 / 워크 스테이션 / 회사별로 라이센스를 부여 하시겠습니까?
5. 소프트웨어를 유용하게 사용하려면 교육 / 사용자 지정이 필요합니까?

질문 5에 대한 답변이 "예"이면 불법 사본에 대해 걱정하지 마십시오. 그들은 어쨌든 유용하지 않을 것입니다.

질문 1에 대한 답변이 "예"이면 먼저 가격을 생각하십시오 (질문 3 참조).

2 번 질문에 "예"라고 대답하면 "PPU (Pay Per Use)"모델이 적합 할 수 있습니다.

내 경험에 따르면, PPU (Pay Per Use) + 사용자 지정 및 교육은 다음과 같은 이유로 귀하의 소프트웨어에 가장 적합한 보호입니다.

• 신규 사용자는 가격 책정 모델에 끌립니다 (소량 사용-> 소액 지불)
• 교육 및 사용자 지정이 필요하기 때문에 "익명 사용자"는 거의 없습니다.
• 잠재적 인 고객을 두려워하는 소프트웨어 제한이 없습니다.
• 기존 고객의 지속적인 자금 흐름이 있습니다.
• 장기적인 비즈니스 관계로 인해 고객으로부터 개발에 대한 귀중한 피드백을받습니다.

DRM 또는 난독 화 소개를 생각하기 전에 이러한 요점과 소프트웨어에 해당되는 점이있을 수 있습니다.

가상 머신의 보호 된 코드는 처음에는 리버스 엔지니어링하는 것이 불가능 해 보였습니다. 테미 다 패커

그러나 더 이상 안전하지는 않습니다. 코드를 어떻게 압축하든로드 된 실행 파일의 메모리 덤프를 항상 수행하고 IDA Pro와 같은 디스어셈블러로 디스 어셈블 할 수 있습니다.

IDA Pro에는 생성 된 코드가 포인터 / 주소 수학적 혼란처럼 보일지라도 C 소스 코드 변환기에 대한 훌륭한 어셈블리 코드가 함께 제공됩니다. 원본과 비교하면 모든 오류를 수정하고 모든 것을 제거 할 수 있습니다.

주사위는 없습니다. 코드가 분해되는 것을 막을 수는 없습니다. 비즈니스 로직을 위해 서버를 설정하고 웹 서비스를 사용하여 앱에 제공하는 것이 가능합니다. 물론이 시나리오가 항상 가능한 것은 아닙니다.

리버스 엔지니어링을 피하려면 코드를 사용자에게 제공해서는 안됩니다. 즉, 온라인 응용 프로그램을 사용하는 것이 좋습니다 (그러나 컨텍스트를 제공하지 않았기 때문에) 당신에게 무의미 할 수 있습니다.

아마도 가장 좋은 대안은 여전히 ​​가상화를 사용하는 것입니다. 가상화를 우회하는 데 필요한 또 다른 수준의 간접 / 난독 처리가 도입되었지만 SSpoke가 대답 한 것처럼 이 기술은 100 % 안전하지 않습니다.

요점은 그러한 보호가 없기 때문에 궁극적 인 보호를받을 수 없다는 것입니다. 앞으로도 오래 지속되지 않을 것입니다.

사람이 무엇이든 조립할 수 있습니다.

(적절한) 분해가 종종 (약간 이상) 어려운 작업이라는 것이 사실이므로 상대 는 더 숙련 되어야 하지만 항상 그러한 품질의 누군가가 있다고 가정 할 수 있으며 안전한 내기입니다.

RE로부터 무언가를 보호하려면 최소한 RE에서 사용하는 일반적인 기술을 알아야합니다.

따라서 단어

인터넷은 리버스 엔지니어링 방지를위한 유용한 리소스가 아니라 리버스 엔지니어링 방법에 대한 수많은 정보를 나타냅니다.

당신의 나쁜 태도를 보여주십시오. 보호를 사용하거나 포함 시키려면 보호 방법을 알아야하지만 현명하게 사용하려면 약점과 함정을 알아야합니다. 당신은해야 이해 를.

(부적절하게 보호를 사용하는 소프트웨어의 예가 있습니다. 이러한 보호는 실제로 존재하지 않습니다. 모호하게 말하지 않기 위해 인터넷에 간단히 설명되어 있습니다 : CD-ROM v4의 Oxford English Dictionary Second Edition. 다음 페이지에 SecuROM에 자사의 실패 사용 : 옥스포드 영어 사전 (OED) CD-ROM에 16, 32, 또는 64 비트 Windows 환경에서 : 하드 디스크 설치, 버그, 단어, 매크로를 처리 네트워킹 글꼴 및 등등 )

모든 시간이 걸립니다.

주제에 익숙하지 않고 RE에 제대로 들어가는 데 몇 개월 또는 몇 년이 걸리지 않으면 다른 사람들이 만든 솔루션을 사용하십시오. 여기의 문제는 분명합니다. 이미 존재한다는 것을 알고 있습니다. 이미 100 % 안전하지 않다는 것을 알고 있지만, 자신 만의 새로운 보호 기능을 사용하면 실제로 최신 기술을 알지 못하는 한 잘못 보호받을 수 있습니다. 리버스 엔지니어링 및 보호 (그러나 지금은 그렇지 않습니다).

소프트웨어 보호의 요점은 초보자를 놀라게하고, 일반적인 RE를 멈춘 다음, 응용 프로그램의 중심으로 향한 흥미 진진한 여행 후에 노련한 RE의 얼굴에 미소를 짓는 것입니다.

비즈니스 토크에서는 가능한 한 경쟁 지연에 관한 것이라고 말할 수 있습니다.

( Philippe Biondi 의 Skype의 Silver Needle 과 Blacke 2006의 Fabrice Desclaux 에서 멋진 프레젠테이션을 보았습니다 ).

RE에 대한 많은 것들이 있다는 것을 알고 있으므로 읽으십시오. :)

가상화에 대해 말 했으므로 EXETOOLS FORUM의 최고의 스레드 하나에 대한 링크를 제공합니다 . 최고의 소프트웨어 보호기 : Themida 또는 Enigma Protector? . 추가 검색에 도움이 될 수 있습니다.

나는 어떤 코드도 해킹 할 수 없다고 생각하지만 누군가가 그것을 시도하고 싶다면 보상이 커야합니다.

다음과 같이해야 할 일이 있다고 말했습니다.

• 가능한 최고의 최적화 수준을 사용하십시오 (역 엔지니어링은 어셈블리 시퀀스를 얻는 것뿐만 아니라 코드를 이해하고 C와 같은 고급 언어로 이식하는 것). 고도로 최적화 된 코드는 따라야 할 수 있습니다.
• 필요한 것보다 큰 데이터 유형을 갖지 않아 구조를 조밀하게 만듭니다. 공식 코드 릴리스간에 구조 멤버를 재 배열하십시오. 구조에서 재 배열 된 비트 필드도 사용할 수 있습니다.
• 변경해서는 안되는 특정 값이 있는지 확인할 수 있습니다 (저작권 메시지는 예입니다). 바이트 벡터에 "vwxyz"가 포함 된 경우 "abcde"를 포함하는 다른 바이트 벡터를 사용하여 차이점을 비교할 수 있습니다. 이를 수행하는 함수는 벡터에 대한 포인터를 전달해서는 안되며 다른 모듈에 정의 된 외부 포인터를 (의사 C 코드) "char * p1 = & string1 [539];" 및 "char p2 = & string2 [-11731];". 그렇게하면 두 문자열을 정확하게 가리키는 포인터가 없습니다. 비교 코드에서 " (p1-539 + i)-* (p2 + 11731 + i) == 일부 값"과 비교합니다. 크래커는 string1을 참조하는 사람이 없기 때문에 string1을 변경하는 것이 안전하다고 생각합니다. 예상치 못한 곳에 시험을 묻습니다.

어셈블리 코드를 직접 해킹하여 쉽고 쉬운 작업을 확인하십시오. 코드를 리버스 엔지니어링하기 어렵게 만들고 디버깅을 더 어렵게 만들기 위해 실험 할 수있는 아이디어가 나타납니다.

이미 많은 사람들이 말했듯이 : 일반 CPU에서는 중지하지 못하고 지연시킬 수 있습니다. 내 오래된 암호 교사가 말했듯이 : 완벽한 암호화가 필요하지 않으므로 코드를 깨는 것이 이익보다 훨씬 비쌉니다. 난독 화에 대해서도 마찬가지입니다.

그러나 3 가지 추가 사항 :

1. 리버스 엔지니어링을 불가능하게 할 수는 있지만 ( 그러나 이것은 매우 크지 만) 일반적인 CPU에서는 불가능합니다. 나는 또한 많은 하드웨어 개발을했으며 종종 FPGA가 사용됩니다. 예를 들어 Virtex 5 FX에는 PowerPC CPU가 있으며 APU를 사용하여 하드웨어에서 자체 CPU opcode를 구현할 수 있습니다. 이 기능을 사용하여 외부 또는 다른 소프트웨어에서 액세스 할 수없는 PowerPC의 설치를 실제로 해독하거나 하드웨어에서 명령을 실행할 수도 있습니다. FPGA는 구성 비트 스트림에 대한 AES 암호화 기능을 내장하고 있으므로 리버스 엔지니어링 할 수 없습니다 (누군가가 AES를 중단시키는 것을 제외하고는 다른 문제가있는 것 같습니다 ...). 이를 통해 하드웨어 IP 공급 업체도 업무를 보호 할 수 있습니다.

2. 당신은 프로토콜에서 말합니다. 어떤 종류의 프로토콜인지는 말하지 않지만 네트워크 프로토콜 인 경우 최소한 네트워크 스니핑으로부터 보호해야합니다. 이것은 실제로 암호화로 할 수 있습니다. 그러나 소프트웨어 소유자로부터 암호화 / 암호 해독을 보호하려면 난독 화로 돌아갑니다.

3. 프로그램을 논박 할 수 없거나 실행할 수 없게 만드십시오. 어떤 종류의 디버깅 감지를 사용하고 예를 들어 마법 상수에 디버그 레지스터 내용을 추가하는 공식에서 적용하십시오. 프로그램이 디버그 모드에서 보이는 것이 정상 실행 위치 인 경우보다 훨씬 어렵지만 계산, 연산 또는 기타 잘못된 계산이 완전히 이루어집니다. 예를 들어 나는 정말 불쾌한 복사 방지 기능을 가진 일부 에코 게임을 알고 있습니다 (복사 방지를 원하지 않는다는 것을 알고 있지만 비슷합니다). 자원. 해적은 방금 그것을 깨뜨 렸습니다 (즉, 리버스 엔지니어링)-실행 여부를 확인하고 volia가 공개했습니다. 이러한 작은 행동 변화는 감지하기가 매우 어렵습니다. 탐지에 즉시 나타나지 않지만 지연된 경우

그래서 마지막으로 나는 제안 할 것이다 : 사람들이 소프트웨어를 리버스 엔지니어링하는 것의 이득을 추정하고, 이것을 (예를 들어 가장 저렴한 인디언 급여를 사용하여) 한 시간으로 변환하고 리버스 엔지니어링을 시간이 많이 걸리도록 만드는 것.

대부분의 사람들이 직감과 개인적인 경험을 바탕으로 말한 것과 달리, 암호로 안전한 프로그램 난독 화는 일반적으로 불가능하다고 생각하지 않습니다.

이것은 내 요점을 보여주기 위해 완벽하게 난독 화 된 프로그램 설명의 한 예입니다.

printf("1677741794\n");

그것이 실제로하는 일은 결코 추측 할 수 없다

printf("%d\n", 0xBAADF00D ^ 0xDEADBEEF);

이 주제에 관한 흥미로운 논문이 있는데, 이는 불가능한 결과를 보여줍니다. 그것은이라고합니다 "난독 프로그램의 (임) 가능성에" .

이 논문은 프로그램이 구현하는 기능과 프로그램을 구별 할 수 없게 만드는 난독 화가 불가능하다는 것을 증명하지만, 다소 약한 방식으로 정의 된 난독 화는 여전히 가능할 수 있습니다!

모호함을 통한 보안은 우리 둘 다보다 훨씬 영리한 사람들에 의해 입증 된 것처럼 작동하지 않습니다. 고객의 통신 프로토콜을 보호해야하는 경우에는 전문가가 공개하고 철저히 조사한 최상의 코드를 사용해야합니다.

사람들이 코드를 검사 할 수있는 상황입니다. 응용 프로그램이 내장형 마이크로 프로세서에서 실행되는 경우 밀봉 기능이있는 것을 선택하여 코드를 검사하거나 실행 중에 현재 사용량과 같은 사소한 매개 변수를 관찰 할 수 없습니다. (하드웨어 침입 기술을 제외하고는 칩을 조심스럽게 분해하고 고급 장비를 사용하여 개별 트랜지스터의 전류를 검사합니다.)

저는 x86에 대한 리버스 엔지니어링 어셈블러의 저자입니다. 놀랄만 한 준비가 되셨다면 최선을 다해 결과를 보내주십시오. (내 웹 사이트를 통해 저에게 연락하십시오.) 답변에서 본 몇 가지가 내게 큰 장애물이 될 것입니다. 리버스 엔지니어링 코드가 얼마나 정교한 지 알고 싶다면 리버스 엔지니어링 문제가있는 웹 사이트를 연구해야합니다.

귀하의 질문에 약간의 설명이 필요할 수 있습니다. 컴퓨터 코드를 리버스 엔지니어링 할 수있는 경우 프로토콜을 어떻게 비밀로 유지 하시겠습니까? 내 프로토콜이 RSA 암호화 메시지 (공개 키 포함)를 보내려면 프로토콜을 비밀로 유지하면 무엇을 얻을 수 있습니까? 모든 실질적인 목적을 위해, 검사자는 무작위 비트 시퀀스에 직면 할 것이다.

그로 테스 앨버트

전통적인 리버스 엔지니어링 기술은 코드에 대한 질문에 대답하기 위해 디스어셈블러를 사용하는 스마트 에이전트의 능력에 달려 있습니다. 강력한 안전을 원한다면 상담원이 그러한 답변을 얻지 못하게 막는 일을해야합니다.

일반적으로 해결할 수없는 중지 프로그램 ( "프로그램 X 중지?")에 의존하여이를 수행 할 수 있습니다. 프로그램에 추론하기 어려운 프로그램을 추가하면 프로그램을 추론하기가 어렵습니다. 그러한 프로그램을 분리하는 것보다 그러한 프로그램을 구성하는 것이 더 쉽습니다. 추론하기가 다양한 정도의 프로그램에 코드를 추가 할 수도 있습니다. 훌륭한 후보는 별칭 ( "포인터")에 대한 추론 프로그램입니다.

Collberg 등은 이러한 주제에 대해 논의하고 코드에 대해 추론하기가 매우 어려운 다양한 "불투명 한"선언문을 정의하는 논문 ( "제조 저렴하고 탄력적이며 은밀한 불투명 구조")을 보유하고 있습니다.

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.39.1946&rep=rep1&type=pdf

Collberg의 특정 메소드가 프로덕션 코드에 적용되는 것을 보지 못했습니다. 특히 C 또는 C ++ 소스 코드는 아닙니다.

DashO Java 난독 화기는 비슷한 아이디어를 사용하는 것 같습니다. http://www.cs.arizona.edu/~collberg/Teaching/620/2008/Assignments/tools/DashO/

코드 숨기기 에 대해 기억 해야 할 첫 번째 사항 : 모든 코드를 숨길 필요는 없습니다.

최종 목표 : 대부분의 소프트웨어 프로그램의 최종 목표는 내 프로그램의 특정 기능을 켜고 끄는 다른 라이센스를 판매하는 능력입니다.

최고의 기술 : WordPress와 같은 후크 및 필터 시스템으로 구축하는 것이 상대방을 혼란스럽게 할 때 가장 좋은 방법이라는 것을 알았습니다. 이를 통해 실제로 코드를 암호화하지 않고도 특정 트리거 연관을 암호화 할 수 있습니다.

이렇게하는 이유는 가능한 한 적은 양의 코드를 암호화하고 싶기 때문입니다.

크래커 알기 : 알아 두기 : 코드 크래킹의 주된 이유는 라이센스의 악의적 인 배포 때문이 아니라 실제로 코드를 변경해야하고 무료 사본을 배포 할 필요가 없기 때문입니다.

시작하기 : 암호화하려는 적은 양의 코드를 제외하고 나머지 코드는 복잡성과 이해를 높이기 위해 하나의 파일로 작성해야합니다.

암호화 준비 : 당신은 내 시스템과 함께 계층으로 암호화 할 것입니다. 매우 복잡한 절차가 될 것이므로 암호화 프로세스를 담당하는 다른 프로그램을 작성하십시오.

1 단계 : 모든 것에 base64 이름을 사용하여 난독 처리합니다. 완료되면 난독 처리 된 코드를 base64로 작성하여 나중에이 코드를 해독하고 실행하는 데 사용되는 임시 파일에 저장하십시오. 말이 되나요?

이 작업을 반복해서 반복하므로 반복하겠습니다. base64 문자열을 만들어 다른 파일에 암호 해독 및 렌더링 할 변수로 저장합니다.

2 단계 :이 임시 파일을 문자열로 읽고 난독 처리 한 다음 base64로 두 번째 임시 파일로 저장하여 최종 사용자를 위해 해독 및 렌더링하는 데 사용합니다.

3 단계 : 원하는만큼 2 단계를 반복하십시오. 일단 암호 해독 오류없이 올바르게 작동하면 상대를 위해 지뢰를 짓기를 원할 것입니다.

LAND MINE ONE : 당신은 당신이 절대적인 비밀을 받고 있다는 사실을 유지하고 싶을 것입니다. 따라서 레이어 2에 대한 크래커 시도 보안 경고 메일 시스템을 구축하십시오. 문제가 발생하면 상대방에 대한 세부 정보를 알려주는 해고가 발생합니다.

LAND MINE TWO : 종속성. 상대방이 레이어 3, 4 또는 5, 또는 실제 설계된 프로그램없이 레이어 1을 실행할 수 있기를 원하지 않습니다. 따라서 레이어 1 내에 프로그램이 없거나 다른 레이어가 있으면 활성화되는 킬 스크립트가 포함되어 있는지 확인하십시오.

나는 당신이 당신 자신의 지뢰를 가지고 놀 수 있다고 확신합니다.

기억할 사항 : 실제로 코드를 base64 대신 암호화하지 않아도됩니다. 그렇게하면 간단한 base64가 프로그램을 해독하지 않습니다.

REWARD : 이것은 실제로 당신과 당신의 상대 사이의 공생 관계 일 수 있습니다. 나는 항상 계층 1 안에 주석을 배치하고, 주석은 크래커를 축하하고 그들에게 현금 보상을 받기 위해 사용할 프로모션 코드를 제공합니다.

편견없이 현금 보상을 중요하게 만드십시오. 나는 보통 $ 500와 같은 것을 말합니다. 당신의 남자가 코드를 해독 한 첫 번째 사람이라면, 그에게 돈을 지불하고 그의 친구가 되십시오. 그가 당신의 친구라면 그는 소프트웨어를 배포하지 않을 것입니다. 그에게 어떻게했는지, 어떻게 개선 할 수 있는지 물어보세요!

행운을 빕니다!

누구나 CodeMorth를 사용해 보셨습니까 : http://www.sourceformat.com/code-obfuscator.htm ? 또는 Themida : http://www.oreans.com/themida_features.php ?

나중에 하나는 더 어리석은 것처럼 보입니다.