Melindungi yang dapat dieksekusi dari rekayasa terbalik?

Saya telah merenungkan bagaimana melindungi kode C / C ++ saya dari pembongkaran dan rekayasa terbalik. Biasanya saya tidak akan memaafkan perilaku ini sendiri dalam kode saya; namun protokol saat ini yang sedang saya kerjakan tidak boleh diinspeksi atau dimengerti, untuk keamanan berbagai orang.

Sekarang ini adalah subjek baru bagi saya, dan internet tidak terlalu banyak akal untuk pencegahan terhadap rekayasa terbalik, melainkan menggambarkan banyak informasi tentang cara membalikkan rekayasa

Beberapa hal yang saya pikirkan sejauh ini adalah:

• Injeksi kode (memanggil fungsi dummy sebelum dan sesudah panggilan fungsi aktual)
• Code obfustication (mengacaukan pembongkaran biner)

• Tulis rutin startup saya sendiri (lebih sulit diikat oleh debugger)

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

• Periksa runtime untuk debugger (dan paksa keluar jika terdeteksi)

• Fungsi trampolin

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

• Alokasi dan deokasi tanpa tujuan (tumpukan banyak berubah)

• Panggilan tiruan dan trampolin sia-sia (ton lompatan dalam output pembongkaran)
• Banyak casting (untuk pembongkaran yang dikaburkan)

Maksud saya ini adalah beberapa hal yang saya pikirkan tetapi semuanya dapat dikerjakan dan atau dipecahkan oleh analis kode dengan kerangka waktu yang tepat. Apakah ada alternatif lain yang saya miliki?

Apa yang dikatakan Amber benar. Anda dapat membuat rekayasa balik lebih sulit, tetapi Anda tidak pernah bisa mencegahnya. Anda tidak boleh mempercayai "keamanan" yang bergantung pada pencegahan reverse engineering .

Yang mengatakan, teknik anti-reverse-engineering terbaik yang saya lihat berfokus bukan pada mengaburkan kode, tetapi pada melanggar alat yang biasanya digunakan orang untuk memahami cara kerja kode. Menemukan cara-cara kreatif untuk memecahkan pembongkaran, debuggers, dll keduanya cenderung lebih efektif dan juga lebih memuaskan secara intelektual daripada hanya menghasilkan rim kode spaghetti yang mengerikan. Ini tidak melakukan apa pun untuk memblokir penyerang yang gigih, tetapi hal itu meningkatkan kemungkinan J Random Cracker akan berkeliaran dan mengerjakan sesuatu yang lebih mudah.

tetapi semuanya dapat dikerjakan dan atau dipecahkan oleh analis kode yang diberi kerangka waktu yang tepat.

Jika Anda memberi orang sebuah program yang dapat mereka jalankan, maka mereka juga akan dapat merekayasa baliknya dengan waktu yang cukup. Itulah sifat dari program. Segera setelah biner tersedia untuk seseorang yang ingin menguraikannya, Anda tidak dapat mencegah rekayasa balik yang akhirnya. Bagaimanapun, komputer harus dapat menguraikannya untuk menjalankannya, dan manusia hanyalah komputer yang lebih lambat.

Sentinel Bersih Aman (sebelumnya Aladdin). Peringatan - API mereka menyebalkan, dokumentasi menyebalkan, dan keduanya bagus dibandingkan dengan alat SDK mereka.

Saya telah menggunakan metode perlindungan perangkat keras mereka ( Sentinel HASP HL ) selama bertahun-tahun. Ini memerlukan fob kunci USB milik yang bertindak sebagai 'lisensi' untuk perangkat lunak. SDK mereka mengenkripsi dan mengaburkan executable & libraries Anda, dan memungkinkan Anda untuk mengikat berbagai fitur dalam aplikasi Anda dengan fitur yang dibakar ke dalam kunci. Tanpa kunci USB yang disediakan dan diaktifkan oleh pemberi lisensi, perangkat lunak tidak dapat mendekripsi dan karenanya tidak akan berjalan. Kunci bahkan menggunakan protokol komunikasi USB yang disesuaikan (di luar bidang pengetahuan saya, saya bukan seorang pengemudi perangkat) untuk membuatnya sulit untuk membangun kunci virtual, atau mengutak-atik komunikasi antara pembungkus runtime dan kunci. SDK mereka tidak terlalu ramah pengembang, dan cukup menyakitkan untuk mengintegrasikan menambahkan perlindungan dengan proses pembuatan otomatis (tapi mungkin).

Sebelum kami menerapkan perlindungan HASP HL, ada 7 perompak yang diketahui telah melepaskan 'perlindungan' dotfuscator dari produk. Kami menambahkan perlindungan HASP pada saat yang sama sebagai pembaruan utama untuk perangkat lunak, yang melakukan beberapa perhitungan berat pada video secara real time. Yang terbaik yang saya tahu dari profil dan benchmarking, perlindungan HASP HL ​​hanya memperlambat perhitungan intensif sekitar 3%. Sejak perangkat lunak itu dirilis sekitar 5 tahun yang lalu, tidak ada satu pun bajak laut baru dari produk tersebut yang ditemukan. Perangkat lunak yang ia lindungi sangat diminati di segmen pasarnya, dan klien menyadari beberapa pesaing yang secara aktif berusaha untuk merekayasa balik (tanpa hasil sejauh ini). Kami tahu mereka telah mencoba meminta bantuan dari beberapa kelompok di Rusia yang mengiklankan layanan untuk memutus perlindungan perangkat lunak,

Baru-baru ini kami mencoba solusi lisensi perangkat lunak mereka (HASP SL) pada proyek yang lebih kecil, yang cukup mudah untuk bekerja jika Anda sudah terbiasa dengan produk HL. Tampaknya bekerja; belum ada insiden pembajakan yang dilaporkan, tetapi permintaan produk ini jauh lebih rendah.

Tentu saja, tidak ada perlindungan yang sempurna. Jika seseorang cukup termotivasi dan memiliki banyak uang untuk dibakar, saya yakin perlindungan yang diberikan oleh HASP dapat dielakkan.

Trik anti disassembler terbaik, khususnya pada set instruksi panjang kata variabel adalah assembler / kode mesin, bukan C. Misalnya

CLC
BCC over
.byte 0x09
over:

Disassembler harus menyelesaikan masalah bahwa tujuan cabang adalah byte kedua dalam instruksi multi byte. Simulator set instruksi tidak akan memiliki masalah. Bercabang ke alamat yang dihitung, yang dapat Anda sebabkan dari C, juga membuat pembongkaran sulit menjadi mustahil. Simulator set instruksi tidak akan bermasalah dengan itu. Menggunakan simulator untuk memilah tujuan cabang agar Anda dapat membantu proses pembongkaran. Kode yang dikompilasi relatif bersih dan mudah untuk disassembler. Jadi saya pikir beberapa perakitan diperlukan.

Saya pikir itu mendekati awal Zen Bahasa Perakitan Michael Abrash di mana ia menunjukkan trik anti disassembler dan anti-debugger sederhana. The 8088/6 memiliki antrian prefetch apa yang Anda lakukan adalah memiliki instruksi yang mengubah instruksi berikutnya atau pasangan di depan. Jika langkah tunggal maka Anda menjalankan instruksi yang dimodifikasi, jika simulator set instruksi Anda tidak mensimulasikan perangkat keras sepenuhnya, Anda menjalankan instruksi yang dimodifikasi. Pada perangkat keras nyata yang berjalan secara normal instruksi sebenarnya sudah ada dalam antrian dan lokasi memori yang dimodifikasi tidak akan menyebabkan kerusakan selama Anda tidak menjalankan rangkaian instruksi itu lagi. Anda mungkin masih bisa menggunakan trik seperti ini hari ini karena prosesor yang disalurkan melalui pipa mengambil instruksi selanjutnya. Atau jika Anda tahu bahwa perangkat keras memiliki instruksi dan cache data yang terpisah, Anda dapat memodifikasi sejumlah byte ke depan jika Anda menyelaraskan kode ini di baris cache dengan benar, byte yang dimodifikasi tidak akan ditulis melalui cache instruksi tetapi cache data, dan simulator kumpulan instruksi yang tidak memiliki simulator cache yang tepat akan gagal dijalankan dengan benar. Saya pikir solusi hanya perangkat lunak tidak akan membuat Anda jauh.

Di atas sudah tua dan terkenal, saya tidak cukup tahu tentang alat saat ini untuk mengetahui apakah mereka sudah mengatasi hal-hal seperti itu. Kode modifikasi diri dapat / akan menjebak debugger, tetapi manusia dapat / akan mempersempit masalah dan kemudian melihat kode modifikasi diri dan mengatasinya.

Dulu para peretas membutuhkan waktu sekitar 18 bulan untuk menyelesaikan sesuatu, misalnya DVD. Sekarang mereka rata-rata sekitar 2 hari hingga 2 minggu (jika termotivasi) (sinar biru, iPhone, dll). Itu berarti bagi saya jika saya menghabiskan lebih dari beberapa hari untuk keamanan, saya cenderung membuang-buang waktu. Satu-satunya keamanan nyata yang akan Anda dapatkan adalah melalui perangkat keras (misalnya instruksi Anda dienkripsi dan hanya inti prosesor yang berada di dalam chip yang didekripsi tepat sebelum eksekusi, dengan cara yang tidak dapat mengekspos instruksi yang didekripsi). Itu mungkin membeli Anda berbulan-bulan, bukan berhari-hari.

Juga, baca buku Kevin Mitnick The Art of Deception. Orang seperti itu dapat mengangkat telepon dan meminta Anda atau rekan kerja membagikan rahasia sistem dengan berpikir bahwa itu adalah manajer atau rekan kerja atau insinyur perangkat keras lain di bagian lain perusahaan. Dan keamanan Anda hancur. Keamanan tidak semua tentang mengelola teknologi, harus mengelola manusia juga.

Ambil contoh, algoritma AES . Ini adalah algoritma yang sangat, sangat umum, dan SANGAT aman. Mengapa? Dua alasan: Ini telah ditinjau oleh banyak orang pintar, dan bagian "rahasia" bukan algoritma itu sendiri - bagian rahasia adalah kunci yang merupakan salah satu input ke algoritma. Ini adalah pendekatan yang jauh lebih baik untuk merancang protokol Anda dengan "rahasia" yang dihasilkan yang berada di luar kode Anda, daripada membuat kode itu sendiri rahasia. Kode selalu dapat ditafsirkan apa pun yang Anda lakukan, dan (idealnya) rahasia yang dihasilkan hanya dapat terancam oleh pendekatan kekuatan besar-besaran atau melalui pencurian.

Saya pikir pertanyaan yang menarik adalah " Mengapa Anda ingin mengaburkan kode Anda?" Anda ingin mempersulit penyerang untuk memecahkan algoritma Anda? Untuk mempersulit mereka menemukan bug yang dapat dieksploitasi dalam kode Anda? Anda tidak perlu mengaburkan kode jika kode tersebut tidak dapat dipecahkan sejak awal. Akar masalahnya adalah perangkat lunak yang dapat dipecahkan. Perbaiki akar masalah Anda, jangan hanya mengaburkannya.

Juga, semakin membingungkan Anda membuat kode, semakin sulit bagi Anda untuk menemukan bug keamanan. Ya, ini akan sulit bagi peretas, tetapi Anda juga harus menemukan bug. Kode harus mudah dipertahankan bertahun-tahun dari sekarang, dan bahkan kode yang jelas dan ditulis dengan baik pun bisa sulit dipertahankan. Jangan membuatnya lebih buruk.

Membuat kode sulit untuk direkayasa ulang disebut kode kebingungan.

Sebagian besar teknik yang Anda sebutkan cukup mudah untuk diselesaikan. Mereka berpusat pada menambahkan beberapa kode yang tidak berguna. Tetapi kode yang tidak berguna mudah dideteksi dan dihapus, meninggalkan Anda dengan program yang bersih.

Untuk kebingungan yang efektif, Anda perlu membuat perilaku program Anda bergantung pada bit yang tidak berguna yang dieksekusi. Misalnya, daripada melakukan ini:

a = useless_computation();
a = 42;

melakukan hal ini:

a = complicated_computation_that_uses_many_inputs_but_always_returns_42();

Atau alih-alih melakukan ini:

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

Lakukan ini (di mana running_under_a_debuggerseharusnya tidak mudah diidentifikasi sebagai fungsi yang menguji apakah kode berjalan di bawah debugger - itu harus mencampur perhitungan yang berguna dengan deteksi debugger):

a = 42 - running_under_a_debugger();

Kebingungan yang efektif bukanlah sesuatu yang dapat Anda lakukan murni pada tahap kompilasi. Apa pun yang dapat dilakukan oleh kompiler, dekompiler dapat melakukannya. Tentu, Anda dapat menambah beban pada dekompiler, tetapi itu tidak akan jauh. Teknik pengaburan yang efektif, sejauh yang ada, melibatkan penulisan sumber yang dikaburkan sejak hari pertama. Jadikan kode Anda modifikasi sendiri. Sampah kode Anda dengan lompatan terkomputasi, yang berasal dari sejumlah besar input. Misalnya, alih-alih panggilan sederhana

some_function();

lakukan ini, ketika Anda mengetahui tata letak bit yang diharapkan dalam some_data_structure:

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

Jika Anda serius tentang kebingungan, tambahkan beberapa bulan ke perencanaan Anda; kebingungan tidak datang murah. Dan pertimbangkan bahwa sejauh ini cara terbaik untuk menghindari orang melakukan rekayasa ulang terhadap kode Anda adalah membuatnya tidak berguna sehingga mereka tidak repot. Ini adalah pertimbangan ekonomi yang sederhana: mereka akan melakukan rekayasa balik jika nilainya bagi mereka lebih besar daripada biayanya; tetapi menaikkan biaya juga meningkatkan biaya Anda, jadi coba turunkan nilainya.

Sekarang saya sudah mengatakan kepada Anda bahwa kebingungan itu sulit dan mahal, saya akan memberitahu Anda bahwa itu bukan untuk Anda . Anda menulis

Protokol saat ini yang telah saya kerjakan tidak boleh diinspeksi atau dimengerti, untuk keamanan berbagai orang

Itu menimbulkan bendera merah. Ini keamanan oleh ketidakjelasan , yang memiliki catatan yang sangat buruk. Jika keamanan protokol tergantung pada orang yang tidak mengetahui protokol, Anda sudah kalah .

Bacaan yang disarankan:

• Alkitab keamanan: Teknik Keamanan oleh Ross Anderson
• Alkitab kebingungan: perangkat lunak yang diserap oleh Christian Collberg dan Jasvir Nagra

Banyak kali, takut produk Anda mendapatkan rekayasa terbalik salah tempat. Ya, itu bisa direkayasa balik; tetapi apakah itu akan menjadi begitu terkenal dalam waktu singkat, bahwa peretas akan merasa layak untuk membalikkan engg. Itu ? (pekerjaan ini bukan kegiatan waktu kecil, untuk garis kode yang substansial).

Jika benar-benar menjadi penghasil uang, maka Anda harus mengumpulkan cukup uang untuk melindunginya menggunakan cara hukum seperti, paten dan / atau hak cipta .

IMHO, ambil tindakan pencegahan dasar yang akan Anda ambil dan lepaskan. Jika itu menjadi titik rekayasa balik yang berarti Anda telah melakukan pekerjaan yang sangat baik, Anda sendiri akan menemukan cara yang lebih baik untuk mengatasinya. Semoga berhasil.

Bacalah http://en.wikipedia.org/wiki/Security_by_obscurity#Arguments_against . Saya yakin orang lain mungkin juga bisa memberikan sumber yang lebih baik mengapa keamanan oleh ketidakjelasan adalah hal yang buruk.

Seharusnya sepenuhnya dimungkinkan, menggunakan teknik kriptografi modern, untuk membuat sistem Anda terbuka (saya tidak mengatakan itu harus terbuka, hanya saja bisa), dan masih memiliki keamanan total, asalkan algoritma kriptografi tidak ada lubang di dalamnya (tidak mungkin jika Anda memilih yang bagus), kunci pribadi / kata sandi Anda tetap pribadi, dan Anda tidak memiliki lubang keamanan dalam kode Anda ( ini yang harus Anda khawatirkan).

Sejak Juli 2013, ada minat baru dalam kebingungan kriptografi kuat (dalam bentuk Kebingungan Kebingungan ) yang tampaknya telah dipacu dari penelitian asli dari Amit Sahai .

• Sahai, Garg, Gentry, Halevi, Raykova, Waters, Kandidat Indistinguishability Obfuscation, dan Enkripsi Fungsional untuk semua sirkuit (21 Juli 2013).
• Sahai, Perairan, Cara Menggunakan Kebingungan Tak Tertentu: Enkripsi yang Dapat Ditolak, dan Banyak Lagi .
• Sahai, Barak, Garg, Kalai, Paneth, Melindungi Kebingungan Terhadap Serangan Aljabar (4 Februari 2014).

Anda dapat menemukan beberapa informasi yang disaring dalam hal ini artikel Majalah Quanta ini dan di artikel IEEE Spectrum .

Saat ini jumlah sumber daya yang diperlukan untuk menggunakan teknik ini membuatnya tidak praktis, tetapi AFAICT konsensus agak optimis tentang masa depan.

Saya mengatakan ini dengan sangat santai, tetapi untuk semua orang yang terbiasa secara naluriah mengabaikan teknologi kebingungan - ini berbeda. Jika terbukti benar-benar berfungsi dan dibuat praktis, ini memang utama, dan bukan hanya untuk kebingungan.

Untuk memberi tahu diri Anda sendiri, bacalah literatur akademis tentang kebingungan kode . Christian Collberg dari University of Arizona adalah seorang sarjana terkemuka di bidang ini; Salil Vadhan dari Universitas Harvard juga telah melakukan pekerjaan yang baik.

Saya ketinggalan dalam literatur ini, tetapi ide penting yang saya sadari adalah bahwa Anda tidak dapat mencegah penyerang melihat kode yang akan Anda jalankan, tetapi Anda bisa mengelilinginya dengan kode yang tidak dieksekusi, dan biayanya waktu eksponensial penyerang (menggunakan teknik yang paling dikenal) untuk menemukan fragmen kode Anda dieksekusi dan mana yang tidak.

Ada makalah terbaru yang disebut " Program kebingungan dan program satu kali ". Jika Anda benar-benar serius melindungi aplikasi Anda. Makalah ini secara umum membahas hasil ketidakmungkinan teoretis dengan menggunakan perangkat keras sederhana dan universal.

Jika Anda tidak mampu memerlukan perangkat keras tambahan, maka ada juga kertas lain yang memberikan kebingungan secara teori sebaik mungkin " Tentang kebingungan sebaik mungkin ", di antara semua program dengan fungsi yang sama dan ukuran yang sama. Namun makalah ini menunjukkan bahwa informasi-teoretis sebaik mungkin menyiratkan runtuhnya hierarki polinomial.

Makalah-makalah tersebut setidaknya harus memberi Anda petunjuk bibliografi yang cukup untuk berjalan dalam literatur terkait jika hasil ini tidak sesuai dengan kebutuhan Anda.

Pembaruan: Gagasan baru kebingungan, yang disebut kebingungan tak dapat dibedakan, dapat mengurangi hasil ketidakmungkinan (kertas)

Jika seseorang ingin menghabiskan waktu untuk membalikkan biner Anda maka sama sekali tidak ada yang dapat Anda lakukan untuk menghentikannya. Anda dapat membuat jika cukup sulit tetapi itu saja. Jika Anda benar-benar ingin mempelajari hal ini maka dapatkan salinan http://www.hex-rays.com/idapro/ dan bongkar beberapa binari.

Fakta bahwa CPU perlu mengeksekusi kode adalah kehancuran Anda. CPU hanya mengeksekusi kode mesin ... dan programmer dapat membaca kode mesin.

Yang sedang berkata ... Anda mungkin memiliki masalah yang berbeda yang dapat diselesaikan dengan cara lain. Apa yang kamu coba lindungi? Tergantung pada masalah Anda, Anda mungkin dapat menggunakan enkripsi untuk melindungi produk Anda.

Untuk dapat memilih opsi yang tepat, Anda harus memikirkan aspek-aspek berikut:

1. Apakah mungkin "pengguna baru" tidak mau membayar tetapi menggunakan perangkat lunak Anda?
2. Apakah mungkin pelanggan yang sudah ada membutuhkan lebih banyak lisensi daripada yang mereka miliki?
3. Berapa banyak pengguna potensial bersedia membayar?
4. Apakah Anda ingin memberikan lisensi per pengguna / pengguna bersamaan / workstation / perusahaan?
5. Apakah perangkat lunak Anda memerlukan pelatihan / penyesuaian untuk berguna?

Jika jawaban untuk pertanyaan 5 adalah "ya", maka jangan khawatir tentang salinan ilegal. Mereka tidak akan berguna.

Jika jawaban untuk pertanyaan 1 adalah "ya", maka pikirkan dulu tentang harga (lihat pertanyaan 3).

Jika Anda menjawab pertanyaan 2 "ya", maka model "bayar per penggunaan" mungkin cocok untuk Anda.

Dari pengalaman saya, bayar per penggunaan + kustomisasi dan pelatihan adalah perlindungan terbaik untuk perangkat lunak Anda, karena:

• Pengguna baru tertarik dengan model penetapan harga (sedikit penggunaan -> sedikit pembayaran)
• Hampir tidak ada "pengguna anonim", karena mereka membutuhkan pelatihan dan penyesuaian.
• Tidak ada batasan perangkat lunak yang membuat takut calon pelanggan.
• Ada aliran uang terus menerus dari pelanggan yang sudah ada.
• Anda mendapatkan umpan balik yang berharga untuk pengembangan dari pelanggan Anda, karena hubungan bisnis jangka panjang.

Sebelum Anda berpikir untuk memperkenalkan DRM atau kebingungan, Anda mungkin memikirkan poin-poin ini dan jika itu berlaku untuk perangkat lunak Anda.

Kode yang dilindungi dalam mesin virtual pada awalnya tampak tidak mungkin untuk dibalik. Themida Packer

Tapi itu tidak aman lagi .. Dan tidak peduli bagaimana Anda mengemas kode Anda, Anda selalu dapat melakukan dump memori dari setiap executable yang dimuat dan membongkar dengan disassembler seperti IDA Pro.

IDA Pro juga dilengkapi dengan kode assembly yang bagus untuk transformator kode sumber C meskipun kode yang dihasilkan akan lebih mirip dengan pointer / alamat kekacauan matematika .. jika Anda membandingkannya dengan aslinya Anda dapat memperbaiki semua kesalahan dan merobek apa pun.

Tanpa dadu, Anda tidak dapat melindungi kode dari pembongkaran. Yang dapat Anda lakukan adalah mengatur server untuk logika bisnis dan menggunakan layanan web untuk menyediakannya bagi aplikasi Anda. Tentu saja, skenario ini tidak selalu memungkinkan.

Untuk menghindari rekayasa terbalik, Anda tidak boleh memberikan kode kepada pengguna. Yang mengatakan, saya sarankan menggunakan aplikasi online ... namun (karena Anda tidak memberikan konteks) yang mungkin tidak ada gunanya pada Anda.

Mungkin alternatif terbaik Anda masih menggunakan virtualisasi, yang memperkenalkan tingkat penipuan / kebingungan lainnya yang perlu dilewati, tetapi seperti kata SSpoke dalam jawabannya , teknik ini juga tidak 100% aman.

Intinya adalah Anda tidak akan mendapatkan perlindungan pamungkas, karena tidak ada hal seperti itu, dan jika memang ada, itu tidak akan bertahan lama, yang berarti itu bukan perlindungan pamungkas di tempat pertama.

Apa pun yang dirakit manusia, dapat dibongkar.

Biasanya benar bahwa pembongkaran (yang tepat) seringkali merupakan (sedikit atau lebih) tugas yang lebih sulit, jadi lawan Anda harus lebih terampil , tetapi Anda dapat mengasumsikan bahwa selalu ada seseorang dengan kualitas seperti itu, dan ini merupakan taruhan yang aman.

Jika Anda ingin melindungi sesuatu dari RE, Anda harus tahu setidaknya teknik umum yang digunakan oleh RE.

Demikian kata-kata

internet sebenarnya tidak banyak akal untuk pencegahan terhadap rekayasa terbalik, melainkan menggambarkan banyak informasi tentang cara membalikkan rekayasa

tunjukkan sikap burukmu. Saya tidak mengatakan bahwa untuk menggunakan atau menanamkan perlindungan, Anda harus tahu cara melanggarnya, tetapi untuk menggunakannya dengan bijak, Anda harus tahu kelemahan dan perangkapnya. Anda harus memahaminya .

(Ada beberapa contoh perangkat lunak yang menggunakan perlindungan dengan cara yang salah, membuat perlindungan seperti itu praktis tidak ada. Untuk menghindari berbicara secara samar-samar, saya akan memberikan Anda sebuah contoh yang dijelaskan secara singkat di internet: Oxford English Dictionary Edisi Kedua pada CD-ROM v4. Anda dapat membaca tentang kegagalan penggunaan SecuROM di halaman berikut: Oxford English Dictionary (OED) pada CD-ROM di lingkungan Windows 16-, 32-, atau 64-bit: Instalasi hard-disk, bug, makro pengolah kata, jaringan, font, dan sebagainya )

Semuanya butuh waktu.

Jika Anda baru mengenal subjek ini dan tidak memiliki waktu berbulan-bulan atau lebih untuk dapat dengan benar melakukan hal-hal RE, maka pergilah dengan solusi yang tersedia yang dibuat oleh orang lain. Masalahnya di sini sudah jelas, mereka sudah ada di sana, jadi Anda sudah tahu mereka tidak 100% aman, tetapi membuat perlindungan baru Anda sendiri hanya akan memberi Anda rasa salah terlindungi, kecuali jika Anda benar-benar mengetahui dengan baik teknologi terkini di membalikkan rekayasa dan perlindungan (tetapi Anda tidak melakukannya, setidaknya pada saat ini).

Tujuan perlindungan perangkat lunak adalah untuk menakut-nakuti pemula, menghentikan RE yang umum, dan memberi senyum pada RE yang berpengalaman setelah perjalanannya (semoga menarik) ke pusat aplikasi Anda.

Dalam pembicaraan bisnis, Anda bisa mengatakan itu semua tentang menunda persaingan, sebanyak mungkin.

(Lihat presentasi Silver Needle di Skype oleh Philippe Biondi dan Fabrice Desclaux di Black Hat 2006).

Anda sadar bahwa ada banyak hal tentang RE di luar sana, jadi mulailah membacanya. :)

Saya katakan tentang virtualisasi, jadi saya akan memberi Anda tautan ke satu utas teladan dari EXETOOLS FORUM : Pelindung perangkat lunak terbaik: Themida atau Enigma Protector? . Ini mungkin sedikit membantu Anda dalam pencarian lebih lanjut.

Saya tidak berpikir bahwa kode apa pun tidak dapat dibatalkan tetapi hasilnya harus bagus untuk seseorang yang ingin mencobanya.

Setelah mengatakan bahwa ada hal-hal yang harus Anda lakukan seperti:

• Gunakan tingkat optimisasi tertinggi yang dimungkinkan (reverse engineering tidak hanya tentang mendapatkan urutan perakitan, tetapi juga tentang memahami kode dan memindahkannya ke bahasa tingkat yang lebih tinggi seperti C). Kode yang sangat optimal dapat menjadi b --- h untuk diikuti.
• Buat struktur padat dengan tidak memiliki tipe data yang lebih besar dari yang diperlukan. Susun ulang anggota struktur di antara rilis kode resmi. Menata ulang bidang bit dalam struktur juga sesuatu yang dapat Anda gunakan.
• Anda dapat memeriksa keberadaan nilai-nilai tertentu yang tidak boleh diubah (pesan hak cipta adalah contoh). Jika vektor byte berisi "vwxyz" Anda dapat memiliki vektor byte lain yang berisi "abcde" dan membandingkan perbedaannya. Fungsi yang melakukannya tidak boleh meneruskan pointer ke vektor tetapi menggunakan pointer eksternal yang didefinisikan dalam modul lain sebagai (kode pseudo-C) "char * p1 = & string1 [539];" dan "char p2 = & string2 [-11731];". Dengan begitu tidak akan ada petunjuk yang menunjuk tepat pada dua string. Dalam kode perbandingan Anda kemudian membandingkan untuk " (p1-539 + i) - * (p2 + 11731 + i) == beberapa nilai". Cracker akan berpikir bahwa aman untuk mengganti string1 karena tidak ada yang muncul untuk merujuknya. Mengubur tes di tempat yang tak terduga.

Cobalah meretas kode rakitan sendiri untuk melihat apa yang mudah dan apa yang sulit dilakukan. Gagasan harus muncul yang dapat Anda coba untuk membuat kode lebih sulit untuk merekayasa balik dan membuat debugging lebih sulit.

Seperti yang sudah dikatakan banyak orang: Pada CPU biasa Anda tidak dapat menghentikannya, Anda dapat menunda saja. Seperti yang dikatakan guru crypto lama saya: Anda tidak perlu enkripsi yang sempurna, memecahkan kode harus lebih mahal daripada keuntungan. Hal yang sama berlaku untuk kebingungan Anda.

Tetapi 3 catatan tambahan:

1. Dimungkinkan untuk membuat reverse engineering tidak mungkin, TETAPI (dan ini adalah sangat sangat besar tapi), Anda tidak dapat melakukannya pada cpu konvensional. Saya juga banyak melakukan pengembangan perangkat keras, dan sering kali FPGA digunakan. Misalnya Virtex 5 FX memiliki PowerPC CPU di atasnya, dan Anda dapat menggunakan APU untuk mengimplementasikan opcode CPU sendiri di perangkat keras Anda. Anda dapat menggunakan fasilitas ini untuk benar-benar mendekripsi pemasangan untuk PowerPC, yang tidak dapat diakses oleh luar atau perangkat lunak lain, atau bahkan menjalankan perintah dalam perangkat keras. Karena FPGA telah membangun enkripsi AES untuk bitstream konfigurasinya, Anda tidak dapat merekayasa baliknya (kecuali seseorang berhasil memecahkan AES, tetapi kemudian saya kira kami memiliki masalah lain ...). Dengan cara ini vendor IP perangkat keras juga melindungi pekerjaan mereka.

2. Anda berbicara dari protokol. Anda tidak mengatakan protokol seperti apa itu, tetapi ketika itu adalah protokol jaringan, Anda setidaknya harus melindunginya dari mengendus jaringan. Ini memang bisa Anda lakukan dengan enkripsi. Tetapi jika Anda ingin melindungi en / dekripsi dari pemilik perangkat lunak, Anda kembali ke kebingungan.

3. Jangan buat program Anda tidak dapat di-debuggable / unrunnable. Cobalah untuk menggunakan semacam deteksi debugging dan menerapkannya misalnya dalam beberapa formula menambahkan konten register debug ke konstanta ajaib. Jauh lebih sulit jika program Anda terlihat dalam mode debug jika itu berjalan normal, tetapi membuat perhitungan yang salah, operasi, atau lainnya. Misalnya, saya tahu beberapa permainan ramah lingkungan, yang memiliki perlindungan salinan yang sangat jahat (saya tahu Anda tidak ingin copyprotection, tetapi serupa): Versi yang dicuri mengubah sumber daya yang ditambang setelah 30 menit permainan, dan tiba-tiba Anda mendapat satu saja sumber. Perompak baru saja memecahkannya (yaitu merekayasa baliknya) - memeriksa apakah itu berjalan, dan volia melepaskannya. Perubahan perilaku ringan seperti itu sangat sulit dideteksi, khususnya. jika mereka tidak muncul langsung ke deteksi, tetapi hanya tertunda.

Jadi akhirnya saya akan menyarankan: Perkirakan apa keuntungan orang-orang membalikkan rekayasa perangkat lunak Anda, menerjemahkannya dalam beberapa waktu (misalnya dengan menggunakan gaji India termurah) dan membuat rekayasa balik sehingga biaya waktu sehingga lebih besar.

Berlawanan dengan apa yang dikatakan kebanyakan orang, berdasarkan pada intuisi dan pengalaman pribadi mereka, saya tidak berpikir program yang aman secara kriptografis terbukti tidak mungkin secara umum.

Ini adalah salah satu contoh pernyataan program yang sangat tidak jelas untuk menunjukkan poin saya:

printf("1677741794\n");

Orang tidak pernah dapat menebak bahwa apa yang sebenarnya dilakukannya adalah

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

Ada makalah yang menarik tentang hal ini, yang membuktikan beberapa hasil ketidakmungkinan. Ini disebut "On (Im) kemungkinan Program Mengaburkan" .

Walaupun makalah ini membuktikan bahwa kebingungan membuat program tidak dapat dibedakan dari fungsi yang dijalankannya tidak mungkin, kebingungan yang didefinisikan dalam beberapa cara yang lebih lemah masih mungkin!

Keamanan melalui ketidakjelasan tidak berfungsi seperti yang telah ditunjukkan oleh orang-orang yang jauh lebih pintar daripada kita berdua. Jika Anda harus melindungi protokol komunikasi pelanggan Anda maka Anda secara moral berkewajiban untuk menggunakan kode terbaik yang ada di tempat terbuka dan sepenuhnya diteliti oleh para ahli.

Ini untuk situasi di mana orang dapat memeriksa kode. Jika aplikasi Anda dijalankan pada mikroprosesor tertanam, Anda dapat memilih yang memiliki fasilitas penyegelan, yang membuatnya tidak mungkin untuk memeriksa kode atau mengamati lebih dari parameter sepele seperti penggunaan saat ini saat berjalan. (Yaitu, kecuali dengan teknik penyerangan perangkat keras, di mana Anda dengan hati-hati membongkar chip dan menggunakan peralatan canggih untuk memeriksa arus pada masing-masing transistor.)

Saya penulis assembler reverse engineering untuk x86. Jika Anda siap untuk kejutan dingin, kirimkan saya hasil upaya terbaik Anda. (Hubungi saya melalui situs web saya.) Beberapa jawaban yang saya lihat akan memberikan rintangan besar bagi saya. Jika Anda ingin melihat seberapa canggih kode reverse engineering bekerja, Anda harus benar-benar mempelajari situs web dengan tantangan reverse engineering.

Pertanyaan Anda dapat menggunakan beberapa klarifikasi. Bagaimana Anda berharap untuk menjaga rahasia protokol jika kode komputer dapat dibalik untuk rekayasa balik? Jika protokol saya adalah mengirim pesan terenkripsi RSA (bahkan kunci publik) apa yang Anda peroleh dengan merahasiakan protokol? Untuk semua tujuan praktis seorang inspektur akan dihadapkan dengan urutan bit acak.

Groetjes Albert

Teknik reverse engineering tradisional bergantung pada kemampuan agen cerdas menggunakan disassembler untuk menjawab pertanyaan tentang kode. Jika Anda menginginkan keamanan yang kuat, Anda harus melakukan hal-hal yang terbukti mencegah agen mendapatkan jawaban seperti itu.

Anda dapat melakukannya dengan mengandalkan Program Berhenti ("apakah program X berhenti?") Yang secara umum tidak dapat diselesaikan. Menambahkan program yang sulit dipikirkan untuk program Anda, membuat program Anda sulit untuk dipikirkan. Lebih mudah untuk membangun program semacam itu daripada memisahkannya. Anda juga dapat menambahkan kode ke program yang memiliki berbagai tingkat kesulitan untuk alasan; kandidat yang hebat adalah program penalaran tentang alias ("petunjuk").

Collberg dkk memiliki sebuah makalah ("Pembuatan Konstruksi Buram yang Murah, Tangguh, dan Siluman") yang membahas topik-topik ini dan mendefinisikan berbagai predikat "buram" yang dapat membuatnya sangat sulit untuk dipikirkan tentang kode:

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

Saya belum melihat metode spesifik Collberg yang diterapkan pada kode produksi, terutama bukan kode sumber C atau C ++.

Dashf Java obfuscator tampaknya menggunakan ide-ide serupa. http://www.cs.arizona.edu/~collberg/Teaching/620/2008/Assignments/tools/DashO/

HAL PERTAMA UNTUK DIINGAT TENTANG Menyembunyikan Kode ANDA : Tidak semua kode Anda perlu disembunyikan.

TUJUAN AKHIR : Tujuan akhir saya untuk sebagian besar program perangkat lunak adalah kemampuan untuk menjual lisensi yang berbeda yang akan menghidupkan dan mematikan fitur tertentu dalam program saya.

TEKNIK TERBAIK : Saya menemukan bahwa membangun sistem kait dan filter seperti penawaran WordPress, adalah metode terbaik mutlak ketika mencoba membingungkan lawan Anda. Ini memungkinkan Anda untuk mengenkripsi asosiasi pemicu tertentu tanpa benar-benar mengenkripsi kode.

Alasan Anda melakukan ini, adalah karena Anda ingin mengenkripsi jumlah kode seminimal mungkin.

KETAHUI CRACKER ANDA : Ketahui hal ini: Alasan utama untuk memecahkan kode bukan karena distribusi lisensi yang berbahaya, itu sebenarnya karena PERLU untuk mengubah kode Anda dan mereka tidak benar-benar PERLU untuk mendistribusikan salinan gratis.

MEMULAI : Sisihkan sejumlah kecil kode yang akan Anda enkripsi, sisa kode harus mencoba dan dijejalkan ke dalam SATU file untuk meningkatkan kompleksitas dan pemahaman.

MEMPERSIAPKAN ENKRIPSI : Anda akan mengenkripsi berlapis-lapis dengan sistem saya, itu juga akan menjadi prosedur yang sangat kompleks, jadi buatlah program lain yang akan bertanggung jawab untuk proses enkripsi.

LANGKAH SATU : Mengaburkan menggunakan nama base64 untuk semuanya. Setelah selesai, base64 kode yang dikaburkan dan simpan ke dalam file sementara yang nantinya akan digunakan untuk mendekripsi dan menjalankan kode ini. Masuk akal?

Saya akan ulangi karena Anda akan melakukan ini lagi dan lagi. Anda akan membuat string base64 dan menyimpannya ke file lain sebagai variabel yang akan didekripsi dan dirender.

LANGKAH KEDUA : Anda akan membaca dalam file sementara ini sebagai string dan mengaburkannya, lalu base64 dan simpan ke dalam file temp kedua yang akan digunakan untuk mendekripsi dan merendernya untuk pengguna akhir.

LANGKAH KETIGA : Ulangi langkah dua sebanyak yang Anda inginkan. Setelah ini berfungsi dengan baik tanpa kesalahan dekripsi, maka Anda akan ingin mulai membangun ranjau darat untuk lawan Anda.

LAND MINE ONE : Anda akan ingin menjaga fakta bahwa Anda diberitahu rahasia mutlak. Jadi, buat sistem keamanan peringatan mail cracker untuk layer 2. Ini akan diaktifkan untuk memberi tahu Anda secara spesifik tentang lawan Anda jika ada masalah.

TAMBANG DUA : Ketergantungan. Anda tidak ingin lawan Anda dapat menjalankan layer satu, tanpa layer 3 atau 4 atau 5, atau bahkan program yang sebenarnya dirancang untuknya. Jadi pastikan bahwa di dalam lapisan satu Anda menyertakan semacam skrip kill yang akan diaktifkan jika program tidak ada, atau lapisan lainnya.

Saya yakin Anda bisa membuat ranjau sendiri, bersenang-senang dengannya.

HAL YANG INGAT DIINGAT : Anda sebenarnya dapat mengenkripsi kode Anda alih-alih base64'ing itu. Dengan cara itu base64 sederhana tidak akan mendekripsi program.

HADIAH : Perlu diingat bahwa ini sebenarnya bisa menjadi hubungan simbiosis antara Anda dan lawan Anda. Saya selalu menempatkan komentar di dalam layer satu, komentar tersebut memberi selamat kepada cracker dan memberi mereka kode promo untuk digunakan agar menerima hadiah uang tunai dari Anda.

Jadikan hadiah uang tunai penting tanpa melibatkan prasangka. Saya biasanya mengatakan sesuatu seperti $ 500. Jika laki-laki Anda adalah orang pertama yang memecahkan kode, maka bayarlah uangnya dan menjadi temannya. Jika dia teman Anda, dia tidak akan mendistribusikan perangkat lunak Anda. Tanyakan kepadanya bagaimana dia melakukannya dan bagaimana Anda dapat meningkatkan!

SEMOGA BERHASIL!

Adakah yang pernah mencoba CodeMorth: http://www.sourceformat.com/code-obfuscator.htm ? Atau Themida: http://www.oreans.com/themida_features.php ?

Nanti orang terlihat lebih menjanjikan.