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

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

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);  
   }
  

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

• 의미 없는 더미 호출 및 트램폴린(분해 출력 시 점프의 톤)
• 수 톤의 주조물(난독화된 분해용)

내 말은, 이것들은 내가 생각해왔던 것들이지만, 그것들은 모두 적절한 시간대를 주어진 코드 분석가들에 의해 해결되거나 해결될 수 있다.다른 대안은 없을까?

하지만 이 모든 것들은 적절한 시간이 주어지면 코드 분석가들에 의해 해결되거나 밝혀질 수 있다.

만약 당신이 사람들에게 그들이 실행할 수 있는 프로그램을 제공한다면, 그들은 또한 충분한 시간이 주어졌을 때 그것을 역설계할 수 있을 것이다.그것이 프로그램의 속성이다.바이너리를 해독하고자 하는 사람이 바이너리를 사용할 수 있게 되는 즉시, 궁극적으로는 역엔지니어링을 막을 수 없다.결국 컴퓨터는 그것을 작동시키기 위해서는 그것을 해독할 수 있어야 하고, 인간은 그야말로 느린 컴퓨터다.

코드를 역엔지니어링하기 어렵게 만드는 것을 코드 난독화라고 한다.

당신이 언급한 대부분의 기술은 작업하기가 꽤 쉽다.그들은 몇 가지 쓸모없는 코드를 추가하는 것에 중점을 둔다.그러나 쓸모없는 코드는 탐지하고 제거하기 쉬워서 깨끗한 프로그램을 남긴다.

효과적인 난독화를 위해서는 프로그램의 동작을 실행 중인 쓸모없는 비트에 의존하게 할 필요가 있다.예를 들어 다음과 같은 작업을 수행하지 마십시오.

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();

효과적인 난독화는 순수하게 컴파일 단계에서 할 수 있는 것이 아니다.컴파일러가 할 수 있는 일이 무엇이든, 디컴파일러는 할 수 있다.물론, 당신은 디컴파일러들의 부담을 늘릴 수 있지만, 그것은 멀리 가지 않을 것이다.효과적인 난독화 기법은 존재하는 그대로, 첫날부터 난독화된 원천을 쓰는 것을 포함한다.암호를 스스로 수정하십시오.다수의 입력에서 파생된 계산된 점프를 사용하여 코드를 폐기하십시오.예를 들어, 간단한 통화 대신

some_function();

이렇게 하면, 비트의 정확한 예상 레이아웃을 알 수 있다.some_data_structure:

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

만약 난독화에 대해 진지하게 생각한다면, 난독화는 비용이 적게 들지 않는다.그리고 사람들이 역설계하는 것을 피하는 가장 좋은 방법은 그들이 신경 쓰지 않도록 그것을 쓸모 없게 만드는 것이라고 생각해라.그것은 간단한 경제적 고려사항이다: 만약 그들에게 주는 가치가 비용보다 크면 그들은 역엔지니어링을 할 것이다; 하지만 그들의 비용을 올리는 것 또한 당신의 비용을 많이 증가시키므로, 그들에게 가치를 낮추도록 시도하라.

난독화가 힘들고 비싸다고 말했으니, 어쨌든 그것은 너를 위한 것이 아니라고 말할 것이다.네가 써라

내가 작업하고 있는 현재의 의전은 여러 사람들의 안전을 위해 결코 검사되거나 이해되어서는 안 된다.

그것은 빨간 깃발을 든다.기록이 매우 빈약한 무명의 보안이다.프로토콜의 보안이 프로토콜을 모르는 사람들에게 달려있다면, 당신은 이미 패배한 것이다.

권장 판독치:

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

앰버의 말이 정확히 맞아.역공학을 더 어렵게 만들 수는 있지만 결코 막을 수는 없다.역공학의 예방에 의존하는 「보안」을 절대 믿어서는 안 된다.

그렇긴 하지만, 내가 본 최고의 반역공학 기술은 코드를 난독하게 만드는 것이 아니라, 사람들이 보통 어떻게 코드가 작동하는지 이해하기 위해 사용하는 도구를 깨는 데 초점을 맞췄다.분해기, 디버거 등을 분해할 수 있는 창의적인 방법을 찾는 것은 단순히 무시무시한 스파게티 코드를 만들어 내는 것보다 더 효과적일 뿐만 아니라 지적 만족도도 더 높다.이것은 결심한 공격자를 막는데 아무런 도움이 되지 않지만, J Random Cracker가 방황하고 대신 더 쉬운 일을 할 가능성을 증가시킨다.

Safe Net Sentinel(이전의 Aladdin).하지만 주의 사항 - API는 형편없고, 문서화는 형편없으며, SDK 툴과 비교하여 두 가지 모두 훌륭하다.

나는 수년 동안 그들의 하드웨어 보호 방법(Sentinel HASP HL)을 사용해 왔다.그것은 소프트웨어의 '라이선스' 역할을 하는 독점적인 USB 키 리모컨을 필요로 한다.그들의 SDK는 당신의 실행 가능성과 라이브러리를 암호화하여 난독화시키고, 당신이 당신의 어플리케이션의 다른 기능들을 키에 태우는 기능들에 묶을 수 있게 해준다.허가자가 제공하고 활성화한 USB 키가 없으면 소프트웨어는 해독할 수 없으므로 실행되지 않는다.키(Key)는 가상 키를 구축하기 어렵게 하거나, 런타임 래퍼와 키 사이의 통신을 변조하기 위해 맞춤형 USB 통신 프로토콜(내 지식 영역 밖에서, 나는 장치 드라이버 가이드가 아니다)을 사용하기도 한다.SDK는 개발자 친화적이지 않으며, 추가 보호 기능을 자동화된 빌드 프로세스(그러나 가능)와 통합하는 데 상당히 어려움을 겪고 있다.

우리가 HASP HL 보호를 시행하기 전에, 7명의 알려진 해적들이 제품에서 도트퓨저 '단백질'을 벗겨냈다.실시간 비디오에서 다소 무거운 계산을 수행하는 소프트웨어의 주요 업데이트와 동시에 HASP 보호를 추가했다.프로파일링과 벤치마킹에서 내가 가장 잘 알 수 있듯이, HASP HL 보호는 집중적인 계산을 약 3%만 늦췄다.그 소프트웨어가 약 5년 전에 출시된 이후, 그 제품의 새로운 해적은 단 한 명도 발견되지 않았다.그것이 보호하는 소프트웨어는 그것의 시장 부문에서 수요가 높으며, 고객들은 여러 경쟁자들이 (지금까지 성공하지 못한 채) 적극적으로 역엔지니어링을 시도하는 것을 알고 있다.우리는 그들이 다양한 뉴스 그룹과 포럼에 있는 수많은 게시물들이 보호 제품의 최신 버전을 포함하고 있기 때문에 소프트웨어 보호를 깨기 위한 서비스를 광고하는 러시아의 몇몇 그룹으로부터 도움을 요청하려고 노력했다는 것을 안다.

최근에 우리는 그들의 소프트웨어 라이센스 솔루션(HASP SL)을 좀 더 작은 프로젝트에 사용해 보았는데, 이미 HL 제품에 익숙하다면 작업을 시작할 수 있을 정도로 간단했다.효과가 있는 것 같다; 해적판 사건은 보고되지 않았지만, 이 제품은 수요가 훨씬 적다.

물론 어떤 보호도 완벽할 수는 없다.만약 누군가가 충분히 동기부여가 되어 있고 심각한 현금을 태울 수 있다면, 나는 HASP가 제공하는 보호는 피할 수 있을 것이라고 확신한다.

올바른 옵션을 선택할 수 있으려면 다음과 같은 측면을 생각해야 한다.

1. "새로운 사용자"가 지불하지 않고 귀하의 소프트웨어를 사용하길 원하는가?
2. 기존 고객이 보유한 것보다 더 많은 라이선스를 필요로 할 가능성이 높은가?
3. 잠재 사용자들은 얼마를 지불할 의향이 있는가?
4. 사용자/동시 사용자/워크스테이션/회사별로 라이센스를 부여하시겠습니까?
5. 소프트웨어에 유용한 교육/사용자 정의가 필요한가?

5번 질문에 대한 대답이 "예"인 경우, 불법 복사에 대해 걱정하지 마십시오.어차피 쓸모가 없겠지.

1번 질문에 대한 대답이 "예"인 경우, 먼저 가격에 대해 생각해 보십시오(3번 질문 참조).

2번 질문에 "예"라고 대답할 경우 "사용량에 따른 결제" 모델이 귀하에게 적합할 수 있다.

내 경험상, 사용당 비용 + 사용자 정의 및 교육이 귀하의 소프트웨어를 보호하는 가장 좋은 방법:

• 새로운 사용자가 가격 모델에 이끌림(작은 사용 -> 적은 급여)
• 훈련과 맞춤화가 필요하기 때문에 "익명 사용자"가 거의 없다.
• 어떤 소프트웨어 제한도 잠재 고객을 겁주지 않는다.
• 기존 고객들로부터 계속 돈이 몰리고 있다.
• 장기적인 비즈니스 관계 때문에 고객으로부터 개발에 대한 귀중한 피드백을 받을 수 있다.

DRM이나 난독화를 도입하기 전에, 당신은 이러한 점들과 그것이 당신의 소프트웨어에 적용 가능한지 생각할 수 있다.

2013년 7월부터 아밋 사하이(Amit Sahai)의 독창적인 연구로부터 자극을 받은 것으로 보이는 암호학적으로 강력한 난독화(Canifishability Obfuscation)에 대한 관심이 새롭게 일고 있다.

• Sahai, Garg, Gentry, Halevi, Raykova, Waters, 후보 식별 불가 난독화 및 모든 회로에 대한 기능 암호화(2013년 7월 21일).
• Sahai, Waters, Unifiable Obuscation 사용 방법: Denucable Encryption 및 기타.
• 사하이, 바락, 가르그, 칼라이, 파네스, 대수학 공격에 대한 난독화 보호(2014년 2월 4일).

당신은 이 Quanta Magazine 기사와 그 IEEE Spectrum 기사에서 몇 가지 증류 정보를 찾을 수 있다.

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

나는 매우 무심코 이렇게 말하지만, 난독화 기술을 본능적으로 무시하는 것에 익숙한 모든 사람들에게 이것은 다르다.만약 그것이 진정으로 효과가 있고 실용적이라는 것이 증명된다면, 이것은 단지 난독화만을 위한 것이 아니라 정말로 중요한 것이다.

만약 누군가가 당신의 이진을 되돌리기 위해 시간을 보내고 싶다면, 그들을 막기 위해 당신이 할 수 있는 일은 절대 없다.적당히 더 어렵다면 만들 수 있지만 그게 다야.만약 당신이 이것에 대해 정말 알고 싶다면, http://www.hex-rays.com/idapro/의 사본을 입수하고 이너리 몇 개를 분해해라.

CPU가 코드를 실행해야 한다는 사실은 당신의 실행취소다.CPU는 시스템 코드만 실행...프로그래머들은 기계 코드를 읽을 수 있다.

그 말은...당신은 다른 방법으로 해결될 수 있는 다른 문제를 가지고 있을 것이다.뭘 보호하려는 거야?문제에 따라 암호화를 사용하여 제품을 보호할 수 있다.

스스로에게 알리려면, 코드 난독화에 관한 학술 문헌을 읽어라.애리조나 대학의 크리스천 콜버그는 이 분야에서 명성이 있는 학자다; 하버드 대학의 살릴 바단 또한 좋은 일을 했다.

나는 이 문헌에 뒤쳐져 있지만 내가 알고 있는 본질적인 생각은 공격자가 당신이 실행할 코드를 보지 못하도록 막을 수는 없지만, 실행되지 않는 코드로 둘러쌀 수 있다는 것이고, 당신의 코드의 어떤 파편들이 실행되고 어떤 것이 실행되지 않는지 알아내는 데는 공격자가 기하급수적으로 많은 시간이 든다(가장 잘 알려진 기법을 사용함).

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

이것은 완벽하게 난독화된 프로그램 진술의 한 예로서 나의 요점을 증명한다.

printf("1677741794\n");

그것이 실제로 무엇을 하는지 결코 짐작할 수 없다.

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

이 주제에 대한 흥미로운 논문이 있는데, 이것은 몇몇 불가능한 결과를 증명한다.그것은 "난독화 프로그램의 실현 가능성"이라고 불린다.

비록 그 논문이 프로그램을 그것이 구현하는 기능으로부터 구별할 수 없게 만드는 난독화가 불가능하다는 것을 증명하지만, 어떤 약한 방법으로 정의되는 난독화는 여전히 가능할지도 모른다!

기존의 역 엔지니어링 기술은 스마트 에이전트가 코드에 대한 질문에 답하기 위해 분해기를 사용하는 능력에 따라 달라진다.만약 당신이 강한 안전을 원한다면, 당신은 대리인이 그러한 대답을 얻는 것을 확실히 막는 일을 해야 한다.

일반적으로 해결할 수 없는 할팅 프로그램("X프로그램이 멈추는가?")에 의존하면 그렇게 할 수 있다.프로그램에 대해 추론하기 어려운 프로그램을 추가하면 프로그램에 대해 추론하기가 어려워진다.그런 프로그램을 해체하는 것보다 구성하는 것이 더 쉽다.추론 난이도가 다른 프로그램에 코드를 추가할 수도 있다. 훌륭한 후보자는 가명("점퍼")에 대한 추론 프로그램이다.

Collberg 외 연구진은 다음과 같은 주제를 논의하고 코드에 대해 매우 이해하기 어려운 다양한 "불투명" 술어를 정의하는 논문("제조 비용이 저렴하고 탄력적이며 은밀한 불투명 구조")을 가지고 있다.

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

특히 C나 C++ 소스 코드가 아닌 생산 코드에 적용된 콜버그의 구체적인 방법을 본 적이 없다.

DashO Java 난독화자는 비슷한 생각을 사용하는 것 같다.http://www.cs.arizona.edu/~collberg/Teaching/620/2008/Assignment/툴/DashO/

역엔지니어링을 피하려면 사용자에게 코드를 줘서는 안 된다.그렇긴 하지만, 나는 온라인 어플리케이션을 사용하는 것을 추천한다.하지만 그건 당신에겐 무의미할 수도 있어

종종, 당신의 제품이 역설계되는 것에 대한 두려움은 잘못된 것이다.그렇다, 그것은 역설계될 수 있다; 하지만 그것이 짧은 기간 동안 그렇게 유명해져서 해커들은 역설계할 가치가 있을 것이다. 그것은? (이 일은 상당한 코드 라인의 작은 시간 활동이 아니다.)

만약 그것이 정말로 돈을 버는 사람이 된다면, 당신은 특허권이나 저작권 같은 법적인 방법을 사용하여 그것을 보호하기 위해 충분한 돈을 모았어야 한다.

IMHO, 당신이 취할 기본적인 예방조치를 취하고 그것을 풀어라.정말 잘했다는 뜻의 역공학의 지점이 된다면, 스스로 더 나은 극복 방법을 찾을 수 있을 것이다.행운을 빈다.

특히 가변 단어 길이 명령 집합에 대한 최고의 분해 방지 트릭은 C가 아니라 조립자/기계 코드에 있다.예를 들면

CLC
BCC over
.byte 0x09
over:

분해자는 분기 목적지가 멀티 바이트 명령의 두 번째 바이트라는 문제를 해결해야 한다.그러나 명령 집합 시뮬레이터는 문제가 없을 것이다.C에서 야기할 수 있는 계산된 주소로 분기하는 것도 분해를 어렵게 만든다.명령 집합 시뮬레이터는 그것에 문제가 없을 것이다.시뮬레이터를 사용하여 분기 행선지를 정렬하면 분해 과정을 도울 수 있다.컴파일된 코드는 분해자가 비교적 깨끗하고 쉽다.그래서 나는 약간의 집회가 필요하다고 생각한다.

나는 그가 간단한 분해 방지 및 데버거 방지 속임수를 보여준 것이 마이클 애브래쉬의 조립 언어의 시작에 가까웠다고 생각한다.8088/6호기는 프리페치 대기열을 가지고 있었고, 당신이 한 일은 다음 지시사항이나 몇 가지 지시사항을 수정하는 것이었습니다.한 번의 스텝으로 수정된 명령을 실행한 경우, 명령 집합 시뮬레이터가 하드웨어를 완전히 시뮬레이션하지 못한 경우 수정된 명령을 실행한 경우.정상적으로 실행되는 실제 하드웨어에서는 실제 명령이 이미 대기열에 있을 것이고 수정된 메모리 위치는 그 지시를 다시 실행하지 않는 한 손상을 일으키지 않을 것이다.당신은 아마도 파이프라인 프로세서가 다음 지시사항을 가져올 때 오늘날에도 여전히 이런 속임수를 사용할 수 있을 것이다.또는 하드웨어에 별도의 지침과 데이터 캐시가 있다는 것을 알고 있는 경우 캐시 라인에 이 코드를 적절하게 정렬하면 몇 바이트 앞쪽에 수정이 가능하며, 수정된 바이트는 명령 캐시가 아닌 데이터 캐시를 통해 기록되며, 적절한 캐시 시뮬레이터가 없는 명령 집합 시뮬레이터가 실행되지 않는다.알맞게소프트웨어 전용 솔루션으로는 별로 도움이 안 될 것 같아.

위의 것들은 오래되고 잘 알려져 있는데, 나는 그들이 이미 그런 것들을 하고 있는지 알기에 현재의 도구들에 대해 충분히 알지 못한다.자가 수정 코드는 디버거를 넘어뜨릴 수 있고, 그러나 인간은 문제를 좁힐 수 있고, 그런 다음 자가 수정 코드를 보고 그 주변에서 작업할 수 있다.

예전에는 해커들이 무언가를 해결하는데 약 18개월이 걸릴 것이다. 예를 들어 DVD.현재 그들은 평균 이틀에서 2주 정도 (동기 부여 시) (블루 레이, 아이폰 등)를 하고 있다.그것은 내가 보안에 며칠 이상을 쓴다면, 나는 시간을 낭비하고 있다는 것을 의미한다.당신이 얻을 유일한 진짜 보안은 하드웨어를 통해서이다. (예를 들어, 당신의 명령은 암호화되어 있고 오직 실행 직전에 칩 안의 프로세서 코어만이 암호화된 지시를 노출할 수 없는 방식으로 해독된 지시를 노출할 수 없다.그렇게 하면 며칠이 아니라 몇 달은 벌 수 있을 거야.

또한 케빈 미트닉의 책 기만술을 읽으세요.그런 사람은 전화를 받고 당신이나 동료가 그것이 회사의 다른 지역 동료나 하드웨어 엔지니어인 줄 알고 시스템에 비밀을 전달하게 할 수 있다.그리고 당신의 보안은 파괴되었다.보안이 기술을 관리하는 것만이 아니라 인간도 관리해야 한다.

http://en.wikipedia.org/wiki/Security_by_obscurity#Arguments_against을 읽어 보십시오.나는 다른 사람들도 왜 무명에 의한 보안이 나쁜 것인지에 대한 더 나은 정보를 줄 수 있을 것이라고 확신한다.

현대 암호기술을 이용하여, 당신의 시스템이 개방되도록 하는 것은 전적으로 가능해야 하며(열려야 한다는 것이 아니라, 그럴 수도 있다는 것만을 말하는 것이 아니라), 여전히 완전한 보안을 가지고 있어야 하며, 암호 알고리즘에 구멍이 나지 않는 한(좋은 것을 고르면 그럴 것 같지 않은 한), 당신의 개인 키/암호어는 사적인 것으로 남아 있고, 당신은 비밀에 부쳐지지 않는다.코드에 보안 구멍이 있다(이것이 당신이 걱정해야 할 사항이다).

가상 머신에서 보호된 코드는 처음에는 역엔지니어링이 불가능해 보였다.테미다 패커

하지만 이젠 그렇게 안전하지 않아그리고 당신이 코드를 어떻게 포장하든 당신은 항상 어떤 로드된 실행 파일의 메모리 덤프를 할 수 있고 IDA Pro와 같은 어떤 디스어셈블러와도 그것을 분해할 수 있다.

IDA Pro는 생성된 코드가 포인터/주소 수학적 혼란과 더 유사하지만 C 소스 코드 변압기에 nifty 어셈블리 코드와 함께 제공된다.만약 당신이 그것을 오리지널과 비교한다면 당신은 모든 오류를 고칠 수 있고 무엇이든 찢어버릴 수 있다.

아마도 가장 좋은 대안은 바이패스(passed)에 의해 필요한 다른 수준의 간접/불확산을 도입하는 가상화를 여전히 사용하는 것일 수 있지만, SSoke가 답변에서 말했듯이, 이 기술 또한 100% 안전하지 않다.

---

요점은 당신이 궁극적인 보호를 받을 수 없다는 것이다. 왜냐하면 그런 것은 존재하지 않기 때문이다. 그리고 만약 그렇게 된다면, 그것은 그것이 애초에 궁극적인 보호가 아니었다는 것을 의미한다.

어떤 사람이 모이든지 분해할 수 있다.

보통 (적절한) 분해는 (적당하게) 좀 더 어려운 일이므로 상대가 더 숙련되어 있어야 하는 것은 사실이지만, 언제나 그런 자질의 사람이 있다고 가정할 수 있고, 그것은 안전한 내기다.

RE로부터 무언가를 보호하려면 RE가 사용하는 일반적인 기법을 알아야 한다.

그러므로 단어

인터넷은 역엔지니어링에 대한 예방에 그다지 도움이 되지 않지만, 역엔지니어링 방법에 관한 많은 정보를 보여준다.

너의 나쁜 태도를 보이다나는 보호를 이용하거나 포함시키기 위해서는 그것을 깨뜨릴 방법을 알아야 한다고 말하는 것이 아니라, 그것을 현명하게 이용하기 위해서는 그것의 약점과 함정을 알아야 한다.이해해주셔야죠.

(소프트웨어가 보호를 잘못된 방법으로 사용하는 사례가 있으며, 이러한 보호는 실질적으로 존재하지 않는다.모호하게 말하는 것을 피하기 위해 인터넷에 간단히 기술된 예를 하나 들겠다.옥스포드 영어 사전 CD-ROM v4의 제2판.SecuROM 사용 실패에 대한 자세한 내용은 다음 페이지를 참조하십시오.16비트, 32비트 또는 64비트 Windows 환경에서 CD-ROM의 OED(Oxford English Dictionary): 하드 디스크 설치, 버그, 워드 프로세싱 매크로, 네트워킹, 글꼴 등)

모든 일에는 시간이 걸린다.

이 주제에 익숙하지 않고 RE에 대해 제대로 이해할 수 있는 시간이 몇 달 또는 몇 년도 없다면, 다른 사람들이 만든 사용 가능한 솔루션으로 진행하십시오.여기서의 문제는 명백하다, 그들은 이미 그곳에 있기 때문에, 이미 100% 안전하지 않다는 것을 알고 있지만, 독자적으로 새로운 보호를 하는 것은 역공학과 보호에 관한 예술의 상태를 정말 잘 알지 못하는 한, 보호받는다는 잘못된 느낌만 줄 뿐이다(그러나 적어도 지금 이 순간에는 그렇지 않다).

소프트웨어 보호의 요점은 새로운 사람들을 놀라게 하고, 흔한 RE를 지연시키고, 당신의 어플리케이션의 중심으로 여행한 후 노련한 RE의 얼굴에 미소를 띄우는 것이다.

비즈니스 토크에서는 경쟁을 최대한 지연시키는 것이 전부라고 말할 수 있다.

(Black Hat 2006에 나온 필립 비온디와 파브리스 데스클로스의 멋진 프레젠테이션 Silver Needle in the Skype를 보십시오.)

---

RE에 대한 내용이 많다는 것을 알고 있으니 읽기 시작하라. :)

가상화에 대해 말씀드렸으니 EXETools FORPORATION: 최고의 소프트웨어 보호자: 테미다 아니면 에니그마 수호자?그것은 추가 검색에 조금 도움이 될 수 있다.

"프로그램 난독화와 일회성 프로그램"이라는 최근 논문이 있다.응용프로그램 보호에 대해 진지하게 생각한다면.논문은 일반적으로 단순하고 보편적인 하드웨어의 사용에 의한 이론적 불가능성에 관한 결과를 다룬다.

만약 당신이 여분의 하드웨어를 요구할 여유가 없다면, 이론적으로 가장 가능성이 높은 난독화 "On-possible-possible-probable 난독화"를 제공하는 또 다른 논문도 있다.그러나 이 논문은 정보-이론적 최선의 가능성이 다항식 서열체계의 붕괴를 내포하고 있음을 보여준다.

만약 이러한 결과가 당신의 필요에 맞지 않는다면, 적어도 관련 문헌을 살펴보기에 충분한 문헌적 단서를 당신에게 주어야 한다.

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

코드모스: http://www.sourceformat.com/code-obfuscator.htm? 아니면 테시다: http://www.oreans.com/themida_features.php?

나중에 하나가 더 약속하는 것처럼 보인다.

AES 알고리즘을 예로 들어보자.아주, 아주 공개적인 알고리즘이고, 매우 안전해. 왜?두 가지 이유:그것은 많은 똑똑한 사람들에 의해 검토되었고, "비밀" 부분은 알고리즘 그 자체가 아니다 - 비밀 부분은 알고리즘에 대한 입력들 중 하나인 열쇠다.코드 자체를 비밀로 하는 것보다는, 생성된 "비밀"로 프로토콜을 설계하는 것이 훨씬 더 좋은 방법이다.그 코드는 당신이 무엇을 하든 항상 해석될 수 있고, (이상적으로) 생성된 비밀은 거대한 짐승 같은 힘 접근이나 절도를 통해서만 위태롭게 될 수 있다.

I think an interesting question is "Why do you want to obfuscate your code?" You want to make it hard for attackers to crack your algorithms? To make it harder for them to find exploitable bugs in your code? You wouldn't need to obfuscate code if the code were uncrackable in the first place. The root of the problem is crackable software. Fix the root of your problem, don't just obfuscate it.

Also, the more confusing you make your code, the harder it will be for YOU to find security bugs. Yes, it will be hard for hackers, but you need to find bugs too. Code should be easy to maintain years from now, and even well-written clear code can be difficult to maintain. Don't make it worse.

No dice, you cannot protect your code from disassemble. What you can do is to set up the server for the business logic and use webservice to provide it for your app. Of course, this scenario is not always possible.

I do not think that any code is unhackable but the rewards need to be great for someone to want to attempt it.

Having said that there are things you should do such as:

• Use the highest optimization level possible (reverse engineering is not only about getting the assembly sequence, it is also about understanding the code and porting it into a higher-level language such as C). Highly optimized code can be a b---h to follow.
• Make structures dense by not having larger data types than necessary. Rearrange structure members between official code releases. Rearranged bit fields in structures are also something you can use.
• You can check for the presence of certain values which shouldn't be changed (a copyright message is an example). If a byte vector contains "vwxyz" you can have another byte vector containing "abcde" and compare the differences. The function doing it should not be passed pointers to the vectors but use external pointers defined in other modules as (pseudo-C code) "char *p1=&string1[539];" and "char p2=&string2[-11731];". That way there won't be any pointers pointing exactly at the two strings. In the comparison code you then compare for "(p1-539+i)-*(p2+11731+i)==some value". The cracker will think it is safe to change string1 because no one appears to reference it. Bury the test in some unexpected place.

Try to hack the assembly code yourself to see what is easy and what is difficult to do. Ideas should pop up that you can experiment with to make the code more difficult to reverse engineer and to make debugging it more difficult.

As many already said: On a regular CPU you cant stop them from doing, you can just delay them. As my old crypto teacher told me: You dont need perfect encryption, breaking the code must be just more expensive than the gain. Same holds for your obfuscation.

But 3 additional notes:

1. It is possible to make reverse engineering impossible, BUT (and this is a very very big but), you cant do it on a conventional cpu. I did also much hardware development, and often FPGA are used. E.g. the Virtex 5 FX have a PowerPC CPU on them, and you can use the APU to implement own CPU opcodes in your hardware. You could use this facility to really decrypt incstuctions for the PowerPC, that is not accessible by the outside or other software, or even execute the command in the hardware. As the FPGA has builtin AES encryption for its configuration bitstream, you could not reverse engineer it (except someone manages to break AES, but then I guess we have other problems...). This ways vendors of hardware IP also protect their work.

2. You speak from protocol. You dont say what kind of protocol it is, but when it is a network protocol you should at least protect it against network sniffing. This can you indeed do by encryption. But if you want to protect the en/decryption from an owner of the software, you are back to the obfuscation.

3. Do make your programm undebuggable/unrunnable. Try to use some kind of detection of debugging and apply it e.g. in some formula oder adding a debug register content to a magic constant. It is much harder if your program looks in debug mode is if it where running normal, but makes a complete wrong computation, operation, or some other. E.g. I know some eco games, that had a really nasty copy-protection (I know you dont want copyprotection, but it is similar): The stolen version altered the mined resources after 30 mins of game play, and suddenly you got just a single resource. The pirate just cracked it (i.e. reverse engineered it) - checked if it run, and volia released it. Such slight behaviour changings are very hard to detect, esp. if they do not appear instantly to detection, but only delayed.

So finally I would suggest: Estimate what is the gain of the people reverse engineering your software, translate this into some time (e.g. by using the cheapest indian salary) and make the reverse engineering so time costing that it is bigger.

Security through obscurity doesn't work as has been demonstrated by people much cleverer than the both of us. If you must protect the communication protocol of your customers then you are morally obliged to use the best code that is in the open and fully scrutinized by experts.

This is for the situation where people can inspect the code. If your application is to run on an embedded microprocessor, you can choose one that has a sealing facility, which makes it impossible to inspect the code or observe more than trivial parameters like current usage while it runs. (It is, except by hardware invading techniques, where you carefully dismantle the chip and use advanced equipment to inspect currents on individual transistors.)

I'm the author of a reverse engineering assembler for the x86. If you're ready for a cold surprise, send me the result of your best efforts. (Contact me through my websites.) Few I have seen in the answers would present a substantial hurdle to me. If you want to see how sophisticated reverse engineering code works, you should really study websites with reverse engineering challenges.

Your question could use some clarification. How do you expect to keep a protocol secret if the computer code is amenable to reverse engineering? If my protocol would be to send an RSA encrypted message (even public key) what do you gain by keeping the protocol secret? For all practical purposes an inspector would be confronted with a sequence of random bits.

Groetjes Albert

FIRST THING TO REMEMBER ABOUT HIDING YOUR CODE: Not all of your code needs to be hidden.

THE END GOAL: My end goal for most software programs is the ability to sell different licenses that will turn on and off specific features within my programs.

BEST TECHNIQUE: I find that building in a system of hooks and filters like WordPress offers, is the absolute best method when trying to confuse your opponents. This allows you to encrypt certain trigger associations without actually encrypting the code.

The reason that you do this, is because you'll want to encrypt the least amount of code possible.

KNOW YOUR CRACKERS: Know this: The main reason for cracking code is not because of malicious distribution of licensing, it's actually because NEED to change your code and they don't really NEED to distribute free copies.

GETTING STARTED: Set aside the small amount of code that you're going to encrypt, the rest of the code should try and be crammed into ONE file to increase complexity and understanding.

PREPARING TO ENCRYPT: You're going to be encrypting in layers with my system, it's also going to be a very complex procedure so build another program that will be responsible for the encryption process.

STEP ONE: Obfuscate using base64 names for everything. Once done, base64 the obfuscated code and save it into a temporary file that will later be used to decrypt and run this code. Make sense?

I'll repeat since you'll be doing this again and again. You're going to create a base64 string and save it into another file as a variable that will be decrypted and rendered.

STEP TWO: You're going to read in this temporary file as a string and obfuscate it, then base64 it and save it into a second temp file that will be used to decrypt and render it for the end user.

STEP THREE: Repeat step two as many times as you would like. Once you have this working properly without decrypt errors, then you're going to want to start building in land mines for your opponents.

LAND MINE ONE: You're going to want to keep the fact that you're being notified an absolute secret. So build in a cracker attempt security warning mail system for layer 2. This will be fired letting you know the specifics about your opponent if anything is to go wrong.

LAND MINE TWO: Dependencies. You don't want your opponent to be able to run layer one, without layer 3 or 4 or 5, or even the actual program it was designed for. So make sure that within layer one you include some sort of kill script that will activate if the program isn't present, or the other layers.

I'm sure you can come up with you're own landmines, have fun with it.

THING TO REMEMBER: You can actually encrypt your code instead of base64'ing it. That way a simple base64 willnt decrypt the program.

REWARD: Keep in mind that this can actually be a symbiotic relationship between you and you'r opponent. I always place a comment inside of layer one, the comment congratulates the cracker and gives them a promo code to use in order to receive a cash reward from you.

Make the cash reward significant with no prejudice involved. I normally say something like $500. If your guy is the first to crack the code, then pay him his money and become his friend. If he's a friend of yours he's not going to distribute your software. Ask him how he did it and how you can improve!

GOOD LUCK!

ReferenceURL : https://stackoverflow.com/questions/6481668/protecting-executable-from-reverse-engineering