Bảo vệ thực thi từ kỹ thuật đảo ngược?

Tôi đã suy nghĩ làm thế nào để bảo vệ mã C / C ++ của mình khỏi sự tháo gỡ và kỹ thuật đảo ngược. Thông thường tôi sẽ không bao giờ bỏ qua hành vi này trong mã của mình; tuy nhiên, giao thức hiện tại tôi đang làm việc không được kiểm tra hay hiểu được, vì sự an toàn của nhiều người.

Bây giờ đây là một chủ đề mới đối với tôi và internet không thực sự tiết kiệm để ngăn chặn kỹ thuật đảo ngược mà chỉ mô tả hàng tấn thông tin về cách kỹ sư đảo ngược

Một số điều tôi nghĩ đến cho đến nay là:

• Mã tiêm (gọi hàm giả trước và sau khi gọi hàm thực tế)
• Mã obfustication (xé bỏ sự phân tách của nhị phân)

• Viết thói quen khởi động của riêng tôi (khó hơn để trình gỡ lỗi liên kết)

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

• Kiểm tra thời gian chạy cho trình gỡ lỗi (và buộc thoát nếu được phát hiện)

• Chức năng trampolines

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

• Phân bổ và giải quyết vô nghĩa (ngăn xếp thay đổi rất nhiều)

• Các cuộc gọi giả vô nghĩa và trampolines (tấn nhảy trong sản lượng tháo gỡ)
• Tấn đúc (đối với tháo gỡ bị xáo trộn)

Ý tôi là đây là một số điều tôi đã nghĩ đến nhưng tất cả chúng có thể được giải quyết và hoặc được các nhà phân tích mã đưa ra khung thời gian phù hợp. Có bất cứ điều gì khác thay thế tôi có?

Những gì Amber nói là hoàn toàn chính xác. Bạn có thể làm cho kỹ thuật đảo ngược khó hơn, nhưng bạn không bao giờ có thể ngăn chặn nó. Bạn không bao giờ nên tin tưởng vào "bảo mật" dựa trên việc ngăn chặn kỹ thuật đảo ngược .

Điều đó nói rằng, các kỹ thuật chống đảo ngược tốt nhất mà tôi thấy tập trung không phải vào việc làm xáo trộn mã, mà thay vào đó là phá vỡ các công cụ mà mọi người thường sử dụng để hiểu cách hoạt động của mã. Tìm cách sáng tạo để phá vỡ trình gỡ lỗi, trình gỡ lỗi, v.v ... vừa có khả năng hiệu quả hơn và cũng vừa thỏa mãn về mặt trí tuệ hơn là chỉ tạo ra các chuỗi mã spaghetti khủng khiếp. Điều này không có gì để chặn một kẻ tấn công xác định, nhưng nó làm tăng khả năng J Random Cracker sẽ đi lang thang và làm việc trên một cái gì đó dễ dàng hơn thay vào đó.

nhưng tất cả chúng có thể được làm việc xung quanh và hoặc được tìm ra bởi các nhà phân tích mã được đưa ra khung thời gian phù hợp.

Nếu bạn cung cấp cho mọi người một chương trình mà họ có thể chạy, thì họ cũng sẽ có thể thiết kế ngược lại cho nó đủ thời gian. Đó là bản chất của các chương trình. Ngay khi nhị phân có sẵn cho người muốn giải mã nó, bạn không thể ngăn chặn kỹ thuật đảo ngược cuối cùng. Rốt cuộc, máy tính phải có khả năng giải mã nó để chạy nó, và con người chỉ đơn giản là một máy tính chậm hơn.

Sentinel an toàn (trước đây là Aladdin). Hãy cẩn thận - API của họ rất tệ, tài liệu rất tệ và cả hai đều tuyệt vời so với các công cụ SDK của họ.

Tôi đã sử dụng phương pháp bảo vệ phần cứng của họ ( Sentinel HASP HL ) trong nhiều năm. Nó yêu cầu fob khóa USB độc quyền hoạt động như 'giấy phép' cho phần mềm. SDK của họ mã hóa và làm xáo trộn các thư viện & thư viện thực thi của bạn và cho phép bạn kết nối các tính năng khác nhau trong ứng dụng của mình với các tính năng được ghi vào khóa. Nếu không có khóa USB được cung cấp và kích hoạt bởi người cấp phép, phần mềm không thể giải mã và do đó sẽ không chạy. Khóa thậm chí sử dụng giao thức giao tiếp USB tùy chỉnh (ngoài kiến ​​thức của tôi, tôi không phải là người điều khiển thiết bị) để gây khó khăn cho việc xây dựng khóa ảo hoặc giả mạo giao tiếp giữa trình bao bọc thời gian chạy và khóa. SDK của họ không thân thiện với nhà phát triển và khá khó khăn để tích hợp thêm bảo vệ với quy trình xây dựng tự động (nhưng có thể).

Trước khi chúng tôi thực hiện bảo vệ HASP HL, đã có 7 tên cướp biển được biết đã tước bỏ 'bảo vệ' dotfuscator khỏi sản phẩm. Chúng tôi đã thêm bảo vệ HASP cùng lúc với một bản cập nhật lớn cho phần mềm, thực hiện một số tính toán nặng nề trên video trong thời gian thực. Như tốt nhất tôi có thể nói từ hồ sơ và điểm chuẩn, bảo vệ HASP HL ​​chỉ làm chậm các tính toán chuyên sâu khoảng 3%. Kể từ khi phần mềm được phát hành khoảng 5 năm trước, không có một tên cướp biển mới nào của sản phẩm được tìm thấy. Phần mềm mà nó bảo vệ đang có nhu cầu cao trong phân khúc thị trường và khách hàng nhận thấy một số đối thủ cạnh tranh đang tích cực cố gắng đảo ngược kỹ sư (cho đến nay vẫn chưa thành công). Chúng tôi biết họ đã cố gắng thu hút sự giúp đỡ từ một số nhóm ở Nga để quảng cáo dịch vụ phá vỡ sự bảo vệ phần mềm,

Gần đây, chúng tôi đã thử giải pháp cấp phép phần mềm của họ (HASP SL) cho một dự án nhỏ hơn, đủ đơn giản để làm việc nếu bạn đã quen thuộc với sản phẩm HL. Nó xuất hiện để làm việc; không có sự cố vi phạm bản quyền được báo cáo, nhưng sản phẩm này có nhu cầu thấp hơn rất nhiều ..

Tất nhiên, không có sự bảo vệ nào có thể hoàn hảo. Nếu ai đó có đủ động lực và có tiền mặt nghiêm trọng để đốt, tôi chắc chắn rằng các biện pháp bảo vệ mà HASP cung cấp có thể bị phá vỡ.

Các thủ thuật chống trình phân tách tốt nhất, đặc biệt trên các tập lệnh có độ dài từ thay đổi nằm trong mã trình biên dịch / mã máy, không phải C. Ví dụ:

CLC
BCC over
.byte 0x09
over:

Trình phân tách phải giải quyết vấn đề rằng đích đích là byte thứ hai trong lệnh đa byte. Một trình mô phỏng tập lệnh sẽ không có vấn đề mặc dù. Việc phân nhánh đến các địa chỉ được tính toán mà bạn có thể gây ra từ C cũng khiến việc tháo gỡ trở nên khó khăn. Hướng dẫn thiết lập giả lập sẽ không có vấn đề với nó. Sử dụng một trình giả lập để sắp xếp các điểm đến chi nhánh cho bạn có thể hỗ trợ quá trình tháo gỡ. Mã biên dịch tương đối sạch sẽ và dễ dàng cho một trình dịch ngược. Vì vậy, tôi nghĩ rằng một số lắp ráp là cần thiết.

Tôi nghĩ rằng đó là gần thời điểm bắt đầu Zen of Association Language của Michael Abrash, nơi ông đã cho thấy một thủ thuật chống phân tách đơn giản và chống gỡ lỗi. 8088/6 có một hàng đợi tìm nạp trước những gì bạn đã làm là có một hướng dẫn sửa đổi hướng dẫn tiếp theo hoặc một cặp đôi phía trước. Nếu một bước duy nhất thì bạn đã thực hiện lệnh đã sửa đổi, nếu trình giả lập tập lệnh của bạn không mô phỏng hoàn toàn phần cứng, bạn đã thực hiện lệnh đã sửa đổi. Trên phần cứng thực chạy bình thường, lệnh thực sẽ có trong hàng đợi và vị trí bộ nhớ đã sửa đổi sẽ không gây ra bất kỳ thiệt hại nào miễn là bạn không thực hiện lại chuỗi lệnh đó. Bạn có thể vẫn có thể sử dụng một mẹo như thế này ngay hôm nay khi các bộ xử lý pipelined tìm nạp lệnh tiếp theo. Hoặc nếu bạn biết rằng phần cứng có bộ đệm dữ liệu và lệnh riêng biệt, bạn có thể sửa đổi một số byte phía trước nếu bạn căn chỉnh mã này trong dòng bộ đệm đúng cách, byte được sửa đổi sẽ không được ghi thông qua bộ đệm của lệnh mà là bộ đệm dữ liệu và một trình giả lập tập lệnh không có trình giả lập bộ đệm đúng cách sẽ không thực thi đúng. Tôi nghĩ rằng các giải pháp chỉ phần mềm sẽ không giúp bạn đi rất xa.

Trên đây là cũ và nổi tiếng, tôi không biết đủ về các công cụ hiện tại để biết nếu chúng đã làm việc xung quanh những thứ như vậy. Mã tự sửa đổi có thể / sẽ tăng trình gỡ lỗi, nhưng con người có thể / sẽ thu hẹp vấn đề và sau đó xem mã tự sửa đổi và làm việc xung quanh nó.

Nó đã từng là các tin tặc sẽ mất khoảng 18 tháng để làm việc gì đó, ví dụ như dvd. Bây giờ họ đang trung bình khoảng 2 ngày đến 2 tuần (nếu có động lực) (tia xanh, iphones, v.v.). Điều đó có nghĩa với tôi nếu tôi dành hơn một vài ngày cho bảo mật, tôi có thể lãng phí thời gian của mình. Bảo mật thực sự duy nhất bạn sẽ nhận được là thông qua phần cứng (ví dụ: hướng dẫn của bạn được mã hóa và chỉ lõi xử lý bên trong chip giải mã ngay trước khi thực thi, theo cách mà nó không thể hiển thị các hướng dẫn được giải mã). Điều đó có thể mua cho bạn hàng tháng thay vì ngày.

Ngoài ra, hãy đọc cuốn sách Nghệ thuật lừa dối của Kevin Mitnick. Một người như thế có thể nhận điện thoại và nhờ bạn hoặc đồng nghiệp đưa ra các bí mật cho hệ thống nghĩ rằng đó là người quản lý hoặc đồng nghiệp hoặc kỹ sư phần cứng khác trong một bộ phận khác của công ty. Và an ninh của bạn được thổi. Bảo mật không phải là tất cả về việc quản lý công nghệ, chúng ta cũng phải quản lý con người.

Lấy ví dụ, thuật toán AES . Đó là một thuật toán rất, rất công khai và nó rất an toàn. Tại sao? Hai lý do: Nó đã được xem xét bởi nhiều người thông minh và phần "bí mật" không phải là chính thuật toán - phần bí mật là chìa khóa là một trong những yếu tố đầu vào của thuật toán. Đó là một cách tiếp cận tốt hơn nhiều để thiết kế giao thức của bạn với một "bí mật" được tạo ra bên ngoài mã của bạn, thay vì làm cho mã đó trở nên bí mật. Mã luôn có thể được giải thích bất kể bạn làm gì và (lý tưởng nhất) bí mật được tạo ra chỉ có thể bị nguy hiểm bởi cách tiếp cận vũ phu lớn hoặc thông qua trộm cắp.

Tôi nghĩ rằng một câu hỏi thú vị là " Tại sao bạn muốn làm xáo trộn mã của bạn?" Bạn muốn làm cho kẻ tấn công khó phá vỡ thuật toán của bạn? Để làm cho họ khó khăn hơn trong việc tìm lỗi có thể khai thác trong mã của bạn? Bạn sẽ không cần phải xáo trộn mã nếu mã không bị bẻ khóa ngay từ đầu. Nguyên nhân của vấn đề là phần mềm bẻ khóa. Khắc phục tận gốc vấn đề của bạn, đừng chỉ làm khó nó.

Ngoài ra, bạn càng khó hiểu về mã của mình, thì càng khó để BẠN tìm thấy các lỗi bảo mật. Vâng, nó sẽ là khó khăn cho tin tặc, nhưng bạn cũng cần phải tìm lỗi. Mã phải dễ duy trì trong nhiều năm kể từ bây giờ và thậm chí mã rõ ràng được viết tốt có thể khó duy trì. Đừng làm cho nó tồi tệ hơn.

Làm cho mã khó để thiết kế ngược được gọi là mã obfuscation.

Hầu hết các kỹ thuật bạn đề cập là khá dễ dàng để làm việc xung quanh. Họ tập trung vào việc thêm một số mã vô dụng. Nhưng mã vô dụng rất dễ phát hiện và loại bỏ, để lại cho bạn một chương trình sạch.

Để obfuscation hiệu quả, bạn cần làm cho hành vi của chương trình của bạn phụ thuộc vào các bit vô dụng được thực thi. Ví dụ, thay vì làm điều này:

a = useless_computation();
a = 42;

làm cái này:

a = complicated_computation_that_uses_many_inputs_but_always_returns_42();

Hoặc thay vì làm điều này:

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

Thực hiện việc này (nơi running_under_a_debuggerkhông thể dễ dàng xác định là một hàm kiểm tra xem mã có đang chạy theo trình gỡ lỗi hay không - nó sẽ trộn các tính toán hữu ích với phát hiện trình gỡ lỗi):

a = 42 - running_under_a_debugger();

Obfuscation hiệu quả không phải là thứ bạn có thể làm hoàn toàn ở giai đoạn biên dịch. Dù trình biên dịch có thể làm gì, một trình dịch ngược có thể làm. Chắc chắn, bạn có thể tăng gánh nặng cho các trình dịch ngược, nhưng nó sẽ không đi xa. Các kỹ thuật obfuscation hiệu quả, khi chúng tồn tại, liên quan đến việc viết nguồn obfuscated từ ngày 1. Làm cho mã của bạn tự sửa đổi. Xả mã của bạn với các bước nhảy được tính toán, xuất phát từ một số lượng lớn đầu vào. Ví dụ, thay vì một cuộc gọi đơn giản

some_function();

làm điều này, nơi bạn tình cờ biết cách bố trí chính xác dự kiến ​​của các bit trong some_data_structure:

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

Nếu bạn nghiêm túc về việc giấu giếm, hãy thêm vài tháng vào kế hoạch của bạn; obfuscation không đến giá rẻ. Và hãy xem xét rằng cho đến nay, cách tốt nhất để tránh mọi người thiết kế ngược mã của bạn là làm cho nó vô dụng để họ không làm phiền. Đó là một cân nhắc kinh tế đơn giản: họ sẽ thiết kế ngược lại nếu giá trị đối với họ lớn hơn chi phí; nhưng tăng chi phí của họ cũng làm tăng chi phí của bạn rất nhiều, vì vậy hãy thử giảm giá trị cho họ.

Bây giờ tôi đã nói với bạn rằng obfuscation là khó khăn và tốn kém, tôi sẽ nói với bạn rằng dù sao nó cũng không dành cho bạn . Bạn viết

giao thức hiện tại tôi đang làm việc không bao giờ được kiểm tra hoặc hiểu được, vì sự an toàn của nhiều người

Điều đó giương cờ đỏ. Đó là bảo mật bởi sự tối nghĩa , có một hồ sơ rất kém. Nếu bảo mật của giao thức phụ thuộc vào những người không biết giao thức, bạn đã mất .

Đề nghị đọc:

• Kinh thánh bảo mật: Kỹ thuật bảo mật của Ross Anderson
• Kinh thánh obfuscation: Phần mềm lén lút của Christian Collberg và Jasvir Nagra

Nhiều lần, nỗi sợ sản phẩm của bạn bị đảo ngược bị đặt sai chỗ. Vâng, nó có thể được thiết kế ngược; nhưng nó sẽ trở nên nổi tiếng trong một khoảng thời gian ngắn, tin tặc sẽ thấy nó có giá trị để đảo ngược engg. nó không (công việc này không phải là một hoạt động thời gian nhỏ, cho các dòng mã đáng kể).

Nếu nó thực sự trở thành một người kiếm tiền, thì bạn nên thu thập đủ tiền để bảo vệ nó bằng các cách hợp pháp như, bằng sáng chế và / hoặc bản quyền tác giả .

IMHO, thực hiện các biện pháp phòng ngừa cơ bản bạn sẽ thực hiện và phát hành nó. Nếu nó trở thành một điểm của kỹ thuật đảo ngược có nghĩa là bạn đã hoàn thành một công việc thực sự tốt, chính bạn sẽ tìm ra những cách tốt hơn để vượt qua nó. Chúc may mắn.

Hãy đọc http://en.wikipedia.org/wiki/Security_by_obscurity#Argument_against . Tôi chắc rằng những người khác cũng có thể cung cấp một nguồn tốt hơn về lý do tại sao bảo mật bằng cách che khuất là một điều xấu.

Hoàn toàn có thể, sử dụng các kỹ thuật mã hóa hiện đại, để hệ thống của bạn được mở (tôi không nói nó nên mở, chỉ là nó có thể), và vẫn có bảo mật hoàn toàn, miễn là thuật toán mật mã không có một lỗ hổng trong đó (không có khả năng nếu bạn chọn một cái tốt), khóa / mật khẩu riêng tư của bạn vẫn ở chế độ riêng tư và bạn không có lỗ hổng bảo mật trong mã của mình ( đây là điều bạn nên lo lắng).

Kể từ tháng 7 năm 2013, đã có sự quan tâm mới đối với việc mã hóa mạnh mẽ về mặt mật mã (dưới dạng Obfuscation không thể phân biệt ) dường như đã được thúc đẩy từ nghiên cứu ban đầu từ Amit Sahai .

• Sahai, Garg, Gentry, Halevi, Raykova, Waters, Ứng cử viên không thể phân biệt Obfuscation và Mã hóa chức năng cho tất cả các mạch (ngày 21 tháng 7 năm 2013).
• Sahai, Waters, Cách sử dụng Obfuscation không thể phân biệt: Mã hóa bị từ chối, và nhiều hơn nữa .
• Sahai, Barak, Garg, Kalai, Paneth, Bảo vệ Obfuscation chống lại các cuộc tấn công đại số (ngày 4 tháng 2 năm 2014).

Bạn có thể tìm thấy một số thông tin được chắt lọc trong bài viết của Tạp chí Quanta này và trong bài viết đó về Phổ Spectrum .

Hiện tại số lượng tài nguyên cần thiết để sử dụng kỹ thuật này làm cho nó không thực tế, nhưng AFAICT sự đồng thuận là khá lạc quan về tương lai.

Tôi nói điều này rất tình cờ, nhưng với tất cả mọi người, những người đã từng sử dụng công nghệ obfuscation theo bản năng - thì điều này lại khác. Nếu nó được chứng minh là thực sự hoạt động và thực tế, thì đây thực sự là vấn đề lớn, và không chỉ cho việc xáo trộn.

Để thông báo cho chính mình, hãy đọc các tài liệu học thuật về mã obfuscation . Christian Collberg của Đại học Arizona là một học giả có uy tín trong lĩnh vực này; Salil Vadhan của Đại học Harvard cũng đã thực hiện một số công việc tốt.

Tôi đứng sau tài liệu này, nhưng ý tưởng thiết yếu mà tôi biết là bạn không thể ngăn kẻ tấn công nhìn thấy mã mà bạn sẽ thực thi, nhưng bạn có thể bao quanh nó bằng mã không được thực thi và phải trả giá kẻ tấn công thời gian theo cấp số nhân (sử dụng các kỹ thuật được biết đến nhiều nhất) để khám phá đoạn nào trong mã của bạn được thực thi và đoạn nào không.

Có một bài báo gần đây được gọi là " Chương trình obfuscation và chương trình một lần ". Nếu bạn thực sự nghiêm túc trong việc bảo vệ ứng dụng của bạn. Bài viết nói chung đi xung quanh các kết quả không thể lý thuyết bằng cách sử dụng phần cứng đơn giản và phổ quát.

Nếu bạn không đủ khả năng yêu cầu thêm phần cứng, thì còn có một bài báo khác đưa ra cách giải mã tốt nhất về mặt lý thuyết " Về khả năng che giấu tốt nhất có thể ", trong số tất cả các chương trình có cùng chức năng và cùng kích cỡ. Tuy nhiên, bài báo cho thấy rằng lý thuyết thông tin tốt nhất có thể ngụ ý sự sụp đổ của hệ thống phân cấp đa thức.

Những bài báo đó ít nhất nên cung cấp cho bạn đầy đủ các dẫn thư mục để đi bộ trong các tài liệu liên quan nếu những kết quả này không phù hợp với nhu cầu của bạn.

Cập nhật: Một khái niệm mới về obfuscation, được gọi là obfuscation không thể phân biệt, có thể giảm thiểu kết quả không thể chấp nhận được (giấy)

Nếu ai đó muốn dành thời gian để đảo ngược nhị phân của bạn thì bạn hoàn toàn không thể làm gì để ngăn chặn họ. Bạn có thể thực hiện nếu khó khăn vừa phải nhưng đó là về nó. Nếu bạn thực sự muốn tìm hiểu về điều này thì hãy lấy một bản sao của http://www.hex-rays.com/idapro/ và tháo rời một vài nhị phân.

Thực tế là CPU cần thực thi mã là hoàn tác của bạn. CPU chỉ thực thi mã máy ... và lập trình viên có thể đọc mã máy.

Điều đó đang được nói ... bạn có thể có một vấn đề khác có thể được giải quyết theo cách khác. Bạn đang cố gắng bảo vệ cái gì? Tùy thuộc vào vấn đề của bạn, bạn có thể sử dụng mã hóa để bảo vệ sản phẩm của mình.

Để có thể chọn tùy chọn phù hợp, Bạn nên nghĩ đến các khía cạnh sau:

1. Có khả năng "người dùng mới" không muốn trả tiền nhưng sử dụng phần mềm của bạn?
2. Có khả năng khách hàng hiện tại cần nhiều giấy phép hơn họ có?
3. Người dùng tiềm năng sẵn sàng trả bao nhiêu?
4. Bạn có muốn cấp giấy phép cho mỗi người dùng / người dùng đồng thời / máy trạm / công ty không?
5. Phần mềm của bạn có cần đào tạo / tùy chỉnh để hữu ích không?

Nếu câu trả lời cho câu hỏi 5 là "có", thì đừng lo lắng về các bản sao bất hợp pháp. Chúng sẽ không hữu ích.

Nếu câu trả lời cho câu hỏi 1 là "có", thì trước tiên hãy nghĩ về giá cả (xem câu hỏi 3).

Nếu bạn trả lời câu hỏi 2 "có", thì mô hình "trả cho mỗi lần sử dụng" có thể phù hợp với Bạn.

Từ kinh nghiệm của tôi, trả tiền cho mỗi lần sử dụng + tùy chỉnh và đào tạo là sự bảo vệ tốt nhất cho phần mềm của bạn, bởi vì:

• Người dùng mới bị thu hút bởi mô hình định giá (ít sử dụng -> trả ít)
• Hầu như không có "người dùng ẩn danh", bởi vì họ cần được đào tạo và tùy biến.
• Không có hạn chế phần mềm khiến khách hàng tiềm năng sợ hãi.
• Có một dòng tiền liên tục từ các khách hàng hiện tại.
• Bạn nhận được phản hồi có giá trị để phát triển từ khách hàng của mình, vì mối quan hệ kinh doanh lâu dài.

Trước khi bạn nghĩ đến việc giới thiệu DRM hoặc obfuscation, Bạn có thể nghĩ về những điểm này và nếu chúng được áp dụng cho phần mềm của Bạn.

Mã được bảo vệ trong một máy ảo dường như không thể đảo ngược kỹ sư lúc đầu. Nhà đóng gói Themida

Nhưng nó không còn an toàn nữa .. Và cho dù bạn đóng gói mã của mình như thế nào, bạn luôn có thể thực hiện kết xuất bộ nhớ của bất kỳ tệp thực thi được tải nào và tháo rời nó với bất kỳ trình phân tách nào như IDA Pro.

IDA Pro cũng đi kèm với một mã lắp ráp tiện lợi cho biến áp mã nguồn C mặc dù mã được tạo sẽ trông giống như một con trỏ toán học / địa chỉ lộn xộn .. nếu bạn so sánh nó với bản gốc, bạn có thể sửa tất cả các lỗi và trích xuất mọi thứ.

Không có xúc xắc, bạn không thể bảo vệ mã của bạn khỏi tháo rời. Những gì bạn có thể làm là thiết lập máy chủ cho logic nghiệp vụ và sử dụng dịch vụ web để cung cấp nó cho ứng dụng của bạn. Tất nhiên, kịch bản này không phải lúc nào cũng có thể.

Để tránh kỹ thuật đảo ngược, bạn không được cung cấp mã cho người dùng. Điều đó nói rằng, tôi khuyên bạn nên sử dụng một ứng dụng trực tuyến ... tuy nhiên (vì bạn không có ngữ cảnh) có thể là vô nghĩa đối với bạn.

Có thể giải pháp thay thế tốt nhất của bạn vẫn là sử dụng ảo hóa, điều này đưa ra một mức độ gián tiếp / ẩn giấu khác cần thiết bằng cách bỏ qua, nhưng như SSpoke đã nói trong câu trả lời của mình , kỹ thuật này cũng không an toàn 100%.

Vấn đề là bạn sẽ không nhận được sự bảo vệ tối thượng, bởi vì không có điều đó, và nếu có, nó sẽ không tồn tại lâu, điều đó có nghĩa là nó không phải là sự bảo vệ cuối cùng ở nơi đầu tiên.

Bất cứ người đàn ông nào lắp ráp, có thể được tháo rời.

Thông thường, việc phân tách (đúng) thường là một nhiệm vụ khó hơn (một chút hoặc nhiều hơn), vì vậy đối thủ của bạn phải có nhiều kỹ năng hơn , nhưng bạn có thể cho rằng luôn có một người có chất lượng như vậy và đó là một vụ cá cược an toàn.

Nếu bạn muốn bảo vệ một cái gì đó chống lại RE, bạn phải biết ít nhất các kỹ thuật phổ biến được sử dụng bởi REs.

Như vậy từ

Internet không thực sự tiết kiệm để ngăn chặn kỹ thuật đảo ngược mà chỉ mô tả hàng tấn thông tin về cách thiết kế đảo ngược

thể hiện thái độ không tốt của bạn Tôi không nói rằng để sử dụng hoặc nhúng bảo vệ, bạn phải biết cách phá vỡ nó, nhưng để sử dụng nó một cách khôn ngoan, bạn nên biết điểm yếu và cạm bẫy của nó. Bạn nên hiểu nó.

(Có những ví dụ về phần mềm sử dụng bảo vệ sai cách, khiến việc bảo vệ đó thực tế không tồn tại. Để tránh nói mơ hồ, tôi sẽ cung cấp cho bạn một ví dụ được mô tả ngắn gọn trên internet: Oxford English Dictionary Second Edition trên CD-ROM v4. Bạn có thể đọc về việc sử dụng SecuROM không thành công ở trang sau: Từ điển tiếng Anh Oxford (OED) trên CD-ROM trong môi trường Windows 16-, 32- hoặc 64 bit: Cài đặt đĩa cứng, lỗi, macro xử lý văn bản, mạng, phông chữ và v.v. )

Mọi thứ đều cần có thời gian.

Nếu bạn chưa quen với chủ đề này và không có nhiều tháng hoặc đúng hơn là nhiều năm để tham gia vào công cụ RE, thì hãy đi với các giải pháp có sẵn do người khác thực hiện. Vấn đề ở đây là rõ ràng, chúng đã có sẵn, vì vậy bạn đã biết rằng chúng không an toàn 100%, nhưng việc bảo vệ mới của riêng bạn sẽ chỉ mang lại cho bạn cảm giác sai lầm khi được bảo vệ, trừ khi bạn biết rất rõ về nghệ thuật kỹ thuật đảo ngược và bảo vệ (nhưng bạn không, ít nhất là tại thời điểm này).

Quan điểm của bảo vệ phần mềm là khiến người mới sợ hãi, trì hoãn các RE thông thường và đặt một nụ cười trên khuôn mặt của RE dày dạn sau hành trình (hy vọng thú vị) của cô ấy đến trung tâm ứng dụng của bạn.

Trong cuộc nói chuyện kinh doanh, bạn có thể nói tất cả về việc trì hoãn cạnh tranh, càng nhiều càng tốt.

(Hãy xem bài thuyết trình hay về Cây kim bạc trong Skype của Philippe Biondi và Fabrice Desclaux được chiếu trên Black Hat 2006).

Bạn biết rằng có rất nhiều thứ về RE ngoài kia, vì vậy hãy bắt đầu đọc nó. :)

Tôi đã nói về ảo hóa, vì vậy tôi sẽ cung cấp cho bạn một liên kết đến một chủ đề mẫu mực từ EXETOOLS FORUM : Người bảo vệ phần mềm tốt nhất: Themida hoặc Người bảo vệ Enigma? . Nó có thể giúp bạn một chút trong các tìm kiếm thêm.

Tôi không nghĩ rằng bất kỳ mã nào là không thể thiếu nhưng phần thưởng cần phải tuyệt vời cho ai đó muốn thử nó.

Đã nói rằng có những điều bạn nên làm như:

• Sử dụng mức tối ưu hóa cao nhất có thể (kỹ thuật đảo ngược không chỉ là lấy chuỗi lắp ráp, mà còn là để hiểu mã và chuyển nó sang ngôn ngữ cấp cao hơn như C). Mã được tối ưu hóa cao có thể là một b --- h để làm theo.
• Làm cho cấu trúc dày đặc bằng cách không có các loại dữ liệu lớn hơn cần thiết. Sắp xếp lại các thành viên cấu trúc giữa các bản phát hành mã chính thức. Sắp xếp lại các trường bit trong cấu trúc cũng là một cái gì đó bạn có thể sử dụng.
• Bạn có thể kiểm tra sự hiện diện của các giá trị nhất định không nên thay đổi (thông điệp bản quyền là một ví dụ). Nếu một vectơ byte chứa "vwxyz", bạn có thể có một vectơ byte khác chứa "abcde" và so sánh sự khác biệt. Hàm thực hiện nó không nên được truyền con trỏ tới các vectơ mà sử dụng các con trỏ bên ngoài được xác định trong các mô-đun khác như (mã giả-C) "char * p1 = & string1 [539];" và "char p2 = & string2 [-11731];". Bằng cách đó, sẽ không có bất kỳ con trỏ trỏ chính xác vào hai chuỗi. Trong mã so sánh, sau đó bạn so sánh cho " (p1-539 + i) - * (p2 + 11731 + i) == một số giá trị". Người bẻ khóa sẽ nghĩ rằng việc thay đổi chuỗi1 là an toàn vì không ai xuất hiện để tham chiếu nó. Chôn bài kiểm tra ở một số nơi bất ngờ.

Hãy thử tự mình hack mã lắp ráp để xem cái gì dễ và cái gì khó. Các ý tưởng sẽ xuất hiện để bạn có thể thử nghiệm để làm cho mã khó khăn hơn để đảo ngược kỹ sư và làm cho việc gỡ lỗi trở nên khó khăn hơn.

Như nhiều người đã nói: Trên một CPU thông thường, bạn không thể ngăn họ làm, bạn chỉ có thể trì hoãn chúng. Như giáo viên mật mã cũ của tôi đã nói với tôi: Bạn không cần mã hóa hoàn hảo, việc phá mã phải đắt hơn mức tăng. Giữ cho obfuscation của bạn.

Nhưng 3 lưu ý bổ sung:

1. Có thể làm cho kỹ thuật đảo ngược không thể, NHƯNG (và đây là một thứ rất rất lớn nhưng), bạn không thể làm điều đó trên một cpu thông thường. Tôi cũng đã phát triển phần cứng nhiều và thường sử dụng FPGA. Ví dụ, Virtex 5 FX có CPU PowerPC trên chúng và bạn có thể sử dụng APU để thực hiện các opc CPU riêng trong phần cứng của mình. Bạn có thể sử dụng cơ sở này để thực sự giải mã các sự cố cho PowerPC, phần mềm bên ngoài hoặc phần mềm khác không thể truy cập được hoặc thậm chí thực thi lệnh trong phần cứng. Vì FPGA đã tích hợp mã hóa AES cho dòng bit cấu hình của nó, bạn không thể đảo ngược nó (ngoại trừ ai đó quản lý để phá AES, nhưng sau đó tôi đoán chúng ta có vấn đề khác ...). Cách này các nhà cung cấp IP phần cứng cũng bảo vệ công việc của họ.

2. Bạn nói từ giao thức. Bạn không nói nó là loại giao thức nào, nhưng khi nó là giao thức mạng, ít nhất bạn nên bảo vệ nó khỏi việc đánh hơi mạng. Điều này bạn thực sự có thể làm bằng mã hóa. Nhưng nếu bạn muốn bảo vệ en / giải mã từ một chủ sở hữu phần mềm, bạn sẽ quay trở lại với sự xáo trộn.

3. Đừng làm cho chương trình của bạn không thể tải được / không thể truy cập được. Cố gắng sử dụng một số loại phát hiện gỡ lỗi và áp dụng nó, ví dụ như trong một số công thức oder thêm nội dung đăng ký gỡ lỗi vào hằng số ma thuật. Sẽ khó hơn nhiều nếu chương trình của bạn trông ở chế độ gỡ lỗi nếu nó chạy bình thường, nhưng thực hiện một tính toán sai hoàn toàn, hoạt động hoặc một số khác. Ví dụ: Tôi biết một số trò chơi sinh thái, có tính năng chống sao chép thực sự khó chịu (Tôi biết bạn không muốn sao chép, nhưng nó cũng tương tự): Phiên bản bị đánh cắp đã thay đổi tài nguyên khai thác sau 30 phút chơi trò chơi và đột nhiên bạn chỉ nhận được một nguồn. Tên cướp biển đã bẻ khóa nó (tức là đảo ngược nó) - kiểm tra xem nó có chạy không, và volia đã thả nó ra. Thay đổi hành vi nhẹ như vậy là rất khó để phát hiện, đặc biệt. nếu chúng không xuất hiện ngay lập tức để phát hiện, mà chỉ bị trì hoãn.

Vì vậy, cuối cùng tôi sẽ đề xuất: Ước tính lợi ích của những người kỹ thuật đảo ngược phần mềm của bạn là gì, dịch phần mềm này vào một lúc nào đó (ví dụ bằng cách sử dụng mức lương ấn độ rẻ nhất) và làm cho kỹ thuật đảo ngược để chi phí thời gian lớn hơn.

Trái với những gì hầu hết mọi người nói, dựa trên trực giác và kinh nghiệm cá nhân của họ, tôi không nghĩ rằng việc che giấu chương trình an toàn bằng mật mã được chứng minh là không thể nói chung.

Đây là một ví dụ về một tuyên bố chương trình bị che giấu hoàn hảo để chứng minh quan điểm của tôi:

printf("1677741794\n");

Người ta không bao giờ có thể đoán rằng những gì nó thực sự làm là

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

Có một bài viết thú vị về chủ đề này, chứng minh một số kết quả không thể thực hiện được. Nó được gọi là "Về khả năng (Im) của các chương trình Obfuscating" .

Mặc dù bài báo đã chứng minh rằng việc obfuscation làm cho chương trình không thể phân biệt được với chức năng mà nó thực hiện là không thể, nhưng obfuscation được định nghĩa theo một cách yếu hơn vẫn có thể!

Bảo mật thông qua che khuất không hoạt động như đã được chứng minh bởi những người thông minh hơn nhiều so với cả hai chúng tôi. Nếu bạn phải bảo vệ giao thức liên lạc của khách hàng thì bạn có nghĩa vụ về mặt đạo đức phải sử dụng mã tốt nhất được mở và xem xét kỹ lưỡng bởi các chuyên gia.

Điều này là cho tình huống mà mọi người có thể kiểm tra mã. Nếu ứng dụng của bạn chạy trên bộ vi xử lý nhúng, bạn có thể chọn một bộ có cơ sở niêm phong, điều này khiến cho việc kiểm tra mã hoặc quan sát nhiều hơn các tham số tầm thường như sử dụng hiện tại trong khi chạy. (Đó là, ngoại trừ bằng các kỹ thuật xâm lấn phần cứng, trong đó bạn cẩn thận tháo dỡ chip và sử dụng thiết bị tiên tiến để kiểm tra dòng điện trên các bóng bán dẫn riêng lẻ.)

Tôi là tác giả của một trình biên dịch kỹ thuật đảo ngược cho x86. Nếu bạn đã sẵn sàng cho một bất ngờ lạnh lùng, hãy gửi cho tôi kết quả của những nỗ lực tốt nhất của bạn. (Liên hệ với tôi qua các trang web của tôi.) Vài điều tôi đã thấy trong các câu trả lời sẽ gây ra trở ngại đáng kể cho tôi. Nếu bạn muốn xem mã kỹ thuật đảo ngược hoạt động tinh vi như thế nào, bạn thực sự nên nghiên cứu các trang web với các thách thức kỹ thuật đảo ngược.

Câu hỏi của bạn có thể sử dụng một số làm rõ. Làm thế nào bạn có thể giữ bí mật giao thức nếu mã máy tính có thể sửa đổi kỹ thuật đảo ngược? Nếu giao thức của tôi là gửi một tin nhắn được mã hóa RSA (thậm chí là khóa chung), bạn sẽ đạt được gì khi giữ bí mật giao thức? Đối với tất cả các mục đích thực tế, một thanh tra viên sẽ phải đối mặt với một chuỗi các bit ngẫu nhiên.

Groetjes Albert

Các kỹ thuật kỹ thuật đảo ngược truyền thống phụ thuộc vào khả năng của một tác nhân thông minh sử dụng bộ dịch ngược để trả lời các câu hỏi về mã. Nếu bạn muốn sự an toàn mạnh mẽ, bạn phải làm những điều có thể ngăn chặn các tác nhân nhận được câu trả lời như vậy.

Bạn có thể làm điều đó bằng cách dựa vào Chương trình Dừng ("chương trình X có dừng lại không?") Mà nói chung không thể giải quyết được. Thêm các chương trình khó lý do về chương trình của bạn, làm cho chương trình của bạn khó lý do. Dễ dàng xây dựng các chương trình như vậy hơn là xé chúng ra. Bạn cũng có thể thêm mã vào chương trình có mức độ khó khác nhau để suy luận; một ứng cử viên tuyệt vời là chương trình lý luận về bí danh ("con trỏ").

Collberg và cộng sự có một bài báo ("Sản xuất các cấu trúc mờ đục giá rẻ, linh hoạt và tàng hình") thảo luận về các chủ đề này và định nghĩa một loạt các vị từ "mờ đục" có thể gây khó khăn cho việc suy luận về mã:

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

Tôi chưa thấy các phương pháp cụ thể của Collberg được áp dụng cho mã sản xuất, đặc biệt không phải là mã nguồn C hoặc C ++.

Bộ giải mã DashO Java dường như sử dụng các ý tưởng tương tự. http://www.cs.arizona.edu/~collberg/Teaching/620/2008/Assignments/tools/DashO/

Điều đầu tiên để nhớ lại về mã số của bạn: Không phải tất cả các mã của bạn cần phải được ẩn.

Mục tiêu cuối cùng : mục tiêu cuối cùng của tôi đối với hầu hết các chương trình phần mềm là khả năng để bán giấy phép khác nhau mà sẽ bật và tắt các tính năng cụ thể trong chương trình của tôi.

KỸ THUẬT TỐT NHẤT : Tôi thấy rằng xây dựng trong một hệ thống móc và bộ lọc như WordPress cung cấp, là phương pháp tuyệt đối tốt nhất khi cố gắng gây nhầm lẫn cho đối thủ của bạn. Điều này cho phép bạn mã hóa các hiệp hội kích hoạt nhất định mà không thực sự mã hóa mã.

Lý do bạn làm điều này là vì bạn sẽ muốn mã hóa số lượng mã ít nhất có thể.

BIẾT CRACKERS CỦA BẠN : Biết điều này: Lý do chính cho việc bẻ khóa mã không phải vì phân phối cấp phép độc hại, thực ra là vì CẦN thay đổi mã của bạn và họ thực sự KHÔNG CẦN phân phối các bản sao miễn phí.

BẮT ĐẦU BẮT ĐẦU : Đặt một lượng nhỏ mã mà bạn sẽ mã hóa, phần còn lại của mã nên thử và được nhồi nhét vào MỘT tệp để tăng độ phức tạp và hiểu biết.

CHUẨN BỊ CHO ENCRYPT : Bạn sẽ mã hóa theo lớp với hệ thống của tôi, đây cũng sẽ là một quy trình rất phức tạp để xây dựng một chương trình khác chịu trách nhiệm cho quá trình mã hóa.

BƯỚC MỘT : Obfuscate bằng cách sử dụng tên base64 cho mọi thứ. Sau khi thực hiện xong, hãy mã64 mã bị xáo trộn và lưu nó vào một tệp tạm thời mà sau này sẽ được sử dụng để giải mã và chạy mã này. Có lý?

Tôi sẽ lặp lại vì bạn sẽ làm điều này nhiều lần. Bạn sẽ tạo một chuỗi base64 và lưu nó vào một tệp khác dưới dạng một biến sẽ được giải mã và kết xuất.

BƯỚC HAI : Bạn sẽ đọc trong tệp tạm thời này dưới dạng một chuỗi và làm xáo trộn nó, sau đó cơ sở64 và lưu nó vào một tệp tạm thời thứ hai sẽ được sử dụng để giải mã và hiển thị nó cho người dùng cuối.

BƯỚC BA : Lặp lại bước hai lần như bạn muốn. Khi bạn đã làm việc này đúng cách mà không cần giải mã lỗi, thì bạn sẽ muốn bắt đầu xây dựng trong các mỏ đất cho đối thủ của mình.

ĐẤT M ONE MỘT : Bạn sẽ muốn giữ sự thật rằng bạn đang được thông báo một bí mật tuyệt đối. Vì vậy, xây dựng trong một cracker cố gắng hệ thống thư cảnh báo bảo mật cho lớp 2. Điều này sẽ được kích hoạt cho bạn biết chi tiết cụ thể về đối thủ của bạn nếu có bất cứ điều gì sai.

ĐẤT M TW HAI : Phụ thuộc. Bạn không muốn đối thủ của mình có thể chạy lớp một, mà không cần lớp 3 hoặc 4 hoặc 5, hoặc thậm chí là chương trình thực tế mà nó được thiết kế cho. Vì vậy, hãy chắc chắn rằng trong lớp một, bạn bao gồm một số loại lệnh script sẽ kích hoạt nếu chương trình không có mặt hoặc các lớp khác.

Tôi chắc rằng bạn có thể nghĩ ra những quả mìn của riêng mình, hãy vui vẻ với nó.

NHỮNG ĐIỀU CẦN LƯU Ý : Bạn thực sự có thể mã hóa mã của mình thay vì mã 64. Bằng cách đó, một cơ sở đơn giản 64 sẽ không giải mã được chương trình.

THƯỞNG : Hãy nhớ rằng đây thực sự có thể là mối quan hệ cộng sinh giữa bạn và đối thủ của bạn. Tôi luôn đặt một bình luận bên trong lớp một, bình luận chúc mừng người bẻ khóa và đưa cho họ một mã khuyến mãi để sử dụng để nhận phần thưởng tiền mặt từ bạn.

Làm cho phần thưởng tiền mặt có ý nghĩa mà không có thành kiến ​​liên quan. Tôi thường nói khoảng 500 đô la. Nếu anh chàng của bạn là người đầu tiên bẻ khóa mã, sau đó trả tiền cho anh ta và trở thành bạn của anh ta. Nếu anh ấy là bạn của bạn, anh ấy sẽ không phân phối phần mềm của bạn. Hỏi anh ấy làm thế nào và làm thế nào bạn có thể cải thiện!

CHÚC MAY MẮN!

Có ai đã thử CodeMorth: http://www.sourceformat.com/code-obfuscator.htmlm chưa? Hoặc Themida: http://www.oreans.com/themida_features.php ?

Sau này có vẻ hứa hẹn hơn.