Melindungi yang dapat dieksekusi dari rekayasa terbalik?


210

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?


172
"Namun protokol saat ini yang sedang saya kerjakan tidak boleh diinspeksi atau dimengerti, demi keamanan berbagai orang." -- semoga beruntung dengan itu.
Amber

62
Anda dapat membuat aplikasi Anda sulit untuk direkayasa ulang. Anda tidak dapat membuatnya menjadi mustahil, asalkan orang lain memegang sebagian besar bagian Anda di tangan mereka. Hati-hati dalam menjamin keamanan penuh, terutama jika nyawa dipertaruhkan - Anda tidak dapat memberikan.
Michael Petrotta

127
Jika komputer Anda dapat memahami kode tersebut, begitu juga seseorang.
Lightness Races in Orbit

78
Buat kode Open Source, dan tidak ada yang akan merekayasa baliknya.
pengguna tidak diketahui

28
"Keamanan karena ketidakjelasan tidak pernah berhasil."
bot47

Jawaban:


151

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.


14
Saya mengerti ini, dan saya telah membaca beberapa makalah tentang keamanan Skype menjelaskan dan saya telah merenungkan ide yang sama Skype telah mencoba sebagai metode untuk tidak mencegah tetapi melindungi protokol saya. Sesuatu yang telah terbukti cukup layak mengingat keadaan yang jelas untuk Skype.
graphitemaster

8
Skype sebenarnya adalah contoh pertama yang muncul di benak saya, jadi saya senang Anda sudah melihat cara meniru metode mereka.
Ricket

176

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.


113
+1. Baca tentang masa kejayaan perlindungan salinan pada Apple II, perang yang terus meningkat antara obfuscator dan cracker, trik-trik gila dengan motor step floppy disk dan instruksi 6502 yang tidak terdokumentasi dan seterusnya ... Dan kemudian menangis sendiri untuk tidur, karena Anda tidak akan mengimplementasikan sesuatu yang hampir begitu rumit dan mereka semua akhirnya retak.
Nemo

2
lebih mudah untuk menggunakan simulator dan mendapatkan visibilitas yang lebih baik daripada mencoba untuk merekayasa balik secara visual atau dengan disassembler. Jika keamanan tidak dibangun ke dalam perangkat keras yang Anda gunakan, saya pikir dunia rata-rata sekitar dua hari hingga dua minggu untuk merekayasa balik dan mengalahkan hampir semua yang keluar. Jika Anda membutuhkan lebih dari dua hari untuk membuat dan menerapkan ini, Anda telah menghabiskan terlalu banyak waktu.
old_timer

5
Satu-satunya DRM yang berfungsi hari ini adalah kombinasi kunci dan server internet yang memverifikasi bahwa hanya satu instance kunci yang aktif pada satu timem.
Thorbjørn Ravn Andersen

2
@Rotsor: Komputer tidak dapat memahaminya karena kami belum dapat mengurangi jenis kecerdasan ini menjadi sebuah algoritma (belum), bukan karena ada semacam hambatan fisik atau teknologi di tempat. Manusia dapat memahaminya karena dia dapat melakukan apa saja yang dapat dilakukan komputer (walaupun lebih lambat) dan juga alasannya .
Adam Robinson

3
Pada titik mana seseorang akan mencoba merekayasa ulang komputer, kecuali jika itu hanya tersedia di lingkungan yang Anda kontrol.
Amber

41

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.


19
Moderator Catatan: Komentar di bawah jawaban ini telah dihapus karena menyimpang ke kebisingan antagonis.
Tim Post

2
Memberi +1 untuk pengalaman, tetapi saya ingin menggaungkan bahwa itu tidak sempurna. Maya (suite 3D) menggunakan dongle perangkat keras (tidak yakin apakah itu HASP), yang tidak menghalangi bajak laut terlalu lama. Ketika ada kemauan, di situ ada jalan.
Robert Fraser

1
AutoCAD menggunakan sistem serupa, yang telah di-crack berkali-kali. Pengait dan orang lain seperti itu akan membuat orang jujur ​​jujur, dan mencegah pembajakan kasual. Jika Anda membangun produk desain bernilai miliaran dolar berikutnya, Anda akan selalu memiliki kerupuk untuk bersaing. Ini semua tentang pengembalian yang berkurang - berapa jam usaha yang diperlukan untuk memecahkan perlindungan perangkat lunak Anda vs hanya membayar untuk itu.
RyanR

6
Saya juga ingin berpadu dari perspektif seseorang yang telah menggunakan perangkat lunak yang diamankan HASP. Pengait adalah masalah besar bagi pengguna akhir . Saya sudah berurusan dengan Dallas iButton dan HASP Aladdin, dan keduanya benar - benar buggy, dan menyebabkan perangkat lunak berhenti bekerja secara acak, membutuhkan pemutusan dan menghubungkan kembali pengait.
Nama Palsu

4
Juga, perlu dicatat bahwa langkah-langkah keamanan HASP belum tentu lebih aman daripada kebingungan kode - tentu saja mereka memerlukan metodologi berbeda untuk merekayasa balik, tetapi sangat mungkin untuk membalikkannya - Lihat: flylogic.net/blog/?p=14 flylogic.net/blog/?p=16 flylogic.net/blog/?p=11
Nama Palsu

22

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.


1
Juga, Anda tidak harus memiliki akses ke kode sumber (atau bahkan kode sumber yang dibongkar) untuk menemukan celah keamanan. Bisa jadi secara tidak sengaja, atau dengan menggunakan fakta bahwa sebagian besar lubang berasal dari masalah yang sama dalam kode (seperti buffer overflows).
penanggung jawab

2
Ada masalah besar dengan kode modifikasi diri. Sebagian besar OS / perangkat keras modern tidak akan membiarkan Anda melakukannya tanpa hak istimewa yang sangat tinggi, mungkin ada masalah cache dan kode tidak aman.
Martin James

1
Dengan prosesor x86 modern, trik seperti ini seringkali buruk untuk kinerja. Menggunakan lokasi memori yang sama sebagai bagian dari lebih dari satu instruksi kemungkinan memiliki efek yang mirip dengan cabang yang salah prediksi. Kode modifikasi sendiri menyebabkan prosesor membuang garis cache untuk menjaga koherensi antara instruksi dan cache data (jika Anda mengeksekusi kode yang dimodifikasi lebih sering daripada Anda memodifikasinya, itu mungkin masih menang).
jilles

2
Saya mengalami ini 20 tahun yang lalu. Kami butuh hampir setengah jam untuk mencari tahu apa yang terjadi. Tidak terlalu bagus jika Anda membutuhkan perlindungan lebih lama.
Bo Persson

1
"instruksi sebenarnya sudah ada dalam antrian dan lokasi memori yang dimodifikasi tidak akan menyebabkan kerusakan" Sampai terjadi interupsi di antara, membilas pipa instruksi, dan menyebabkan kode baru menjadi terlihat. Sekarang kebingungan Anda telah menyebabkan bug bagi pengguna sah Anda.
Ben Voigt

21

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.


3
Memberi +1 pada akal sehat: mengapa mempersulit diri sendiri saat Anda bisa mendesain sistem yang lebih baik.
Necrolis

1
Seperti yang selalu saya katakan, jika Anda menyimpan semua sisi server, ini lebih aman
liamzebedee

20

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:


1
@Gilles, itu pernyataan Anda, yang sangat kuat, jadi beban pembuktian ada pada Anda. Namun, saya akan memberikan contoh sederhana: 2+2dapat disederhanakan oleh compiler 4, tetapi decompiler tidak dapat mengembalikannya 2+2(bagaimana jika itu sebenarnya 1+3?).
Rotsor

7
@Rotsor 4dan 2+2setara secara observasi, sehingga mereka sama untuk tujuan ini, yaitu untuk mengetahui apa yang sedang dilakukan program. Ya, tentu saja, decompiler tidak dapat merekonstruksi kode sumber, tetapi itu tidak relevan. T&J ini tentang merekonstruksi perilaku (yaitu algoritma, dan lebih tepatnya protokol).
Gilles 'SANGAT berhenti menjadi jahat'

1
Anda tidak perlu melakukan apa pun untuk merekonstruksi perilaku. Anda sudah memiliki programnya! Apa yang biasanya Anda butuhkan adalah memahami protokol dan mengubah sesuatu di dalamnya (seperti mengganti 2 in 2+2dengan 3, atau mengganti +dengan a *).
Rotsor

1
Jika Anda menganggap semua program yang setara dengan perilaku sama, maka ya, kompiler tidak dapat melakukan apa-apa karena hanya melakukan transformasi indentitas. Dekompiler juga tidak berguna, karena merupakan transformasi identitas lagi. Namun, jika Anda tidak melakukannya, maka 2+2-> 4adalah contoh valid dari transformasi yang tidak dapat dikembalikan yang dilakukan oleh kompiler. Apakah itu membuat pemahaman lebih mudah atau lebih sulit adalah argumen terpisah.
Rotsor

2
@Gilles Saya tidak bisa memperluas analogi Anda dengan apel karena saya tidak bisa membayangkan apel yang berbeda secara struktural, tetapi secara perilaku sama. :)
Rotsor

13

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.


1
Maksud saya, ini adalah jawaban yang layak dan dapat diterapkan, tetapi garis yang Anda ambil antara perlindungan dan mendapatkan penghasilan beberapa juta untuk membuat orang lain melindungi produk Anda bagi Anda adalah garis yang sangat panjang.
graphitemaster

12

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).


2
Saya setuju dengan ini. Saya pikir Anda mungkin memiliki masalah konseptual atau desain. Apakah ada analog dengan solusi pasangan kunci privat-publik? Anda tidak pernah membocorkan kunci pribadi, itu tetap dengan pemilik yang klien amannya memprosesnya. Bisakah Anda menjaga kode aman dari komputer mereka dan hanya memberikan hasil kembali kepada pengguna?
Dizzley

8

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

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.


7

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.


7

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)


6

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.


6

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.


Saran yang sangat bagus (dan saya membatalkannya), tetapi itu tidak benar-benar menjawab pertanyaan khusus ini
Mawg mengatakan mengembalikan Monica

5

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.


5

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.


8
kata baik, satu-satunya cara untuk menghindari orang membongkar kode Anda adalah untuk tidak pernah membiarkan mereka memiliki akses fisik sama sekali yang berarti menawarkan aplikasi Anda secara eksklusif sebagai SAAS, menerima permintaan dari klien jarak jauh dan mengembalikan data yang diproses. Tempatkan server di ruang terkunci di bunker bawah tanah yang dikelilingi oleh parit buaya dan kawat cukur setinggi 5m yang Anda gunakan untuk membuang kunci sebelum menutupinya dengan 10m beton bertulang, dan kemudian harap Anda tidak lupa untuk menginstal ton sistem perangkat lunak untuk mencegah intrusi melalui jaringan.
jwenting

6
Saya harap saya tidak pernah mendapatkan kontrak untuk memelihara server Anda
Colin Pickard

5

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.


ini adalah solusi nyata ... yaitu menempatkan perhiasan mahkota Anda ke server Anda sendiri di mesin VPS Anda sendiri dan hanya memaparkan panggilan API ke server ini dari klien (browser atau api klien)
Scott Stensland

5

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.


4

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.


2
poin pertama Anda tidak masuk akal, kode yang dioptimalkan memotong cruft, ini membuatnya lebih mudah untuk dibalik (saya berbicara dari pengalaman). titik ketiga Anda juga membuang-buang waktu, dan insinyur reverse layak garam tahu bagaimana melakukan breakpointing akses memori. Inilah sebabnya mengapa mungkin yang terbaik untuk tidak merancang sistem sendiri tetapi perpustakaan pihak ke-3 kami yang belum 'retak', karena itu kemungkinan akan bertahan sedikit lebih lama daripada apa pun yang bisa diciptakan oleh 'pemula' ...
Necrolis

Karena tampaknya saya tidak tahu apa-apa tentang masalah ini, mungkin saya harus beralih ke profesional seperti Anda untuk kebutuhan pengembangan perangkat lunak alih-alih menulis sendiri kode apa pun.
Olof Forshell

4

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.


3

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!


7
1. Contoh Anda tidak relevan di sini; dua program yang Anda tampilkan setara dengan perilaku, dan pertanyaan ini adalah tentang mencari tahu perilaku suatu program, bukan merekonstruksi kode sumbernya (yang, jelas, tidak mungkin). 2. Makalah ini adalah makalah teoretis; tidak mungkin untuk menulis obfuscator sempurna, tetapi juga tidak mungkin untuk menulis dekompiler sempurna (untuk banyak alasan yang sama bahwa tidak mungkin untuk menulis penganalisa program yang sempurna). Dalam praktiknya, ini adalah perlombaan senjata: siapa yang bisa menulis obfuscator yang lebih baik.
Gilles 'SANGAT berhenti menjadi jahat'

1
@Gilles, hasil dari deobfuscation (benar) akan selalu setara dengan perilaku dengan kode yang dikaburkan. Saya tidak melihat bagaimana hal itu meremehkan pentingnya masalah.
Rotsor

Juga, tentang perlombaan senjata: ini bukan tentang siapa yang berinvestasi lebih banyak ke dalam penelitian, tetapi tentang siapa yang benar. Bukti matematika yang benar tidak salah hanya karena seseorang menginginkannya dengan sangat buruk.
Rotsor

1
Oke, mungkin Anda benar tentang perlombaan senjata dalam latihan. Saya pikir saya salah paham yang ini. :) Saya harap beberapa jenis kebingungan-cryptographically-aman adalah mungkin.
Rotsor

Untuk kasus kebingungan yang menarik, coba kartu pintar, yang masalahnya adalah penyerang memiliki akses fisik (kebingungan kotak putih). Bagian dari respons adalah membatasi akses dengan cara fisik (penyerang tidak dapat membaca kunci rahasia secara langsung); tetapi kebingungan perangkat lunak juga berperan, terutama untuk membuat serangan seperti DPA tidak memberikan hasil yang bermanfaat. Saya tidak memiliki referensi yang baik untuk ditawarkan, maaf. Contoh-contoh dalam jawaban saya samar-samar terinspirasi dari teknik yang digunakan dalam domain itu.
Gilles 'SANGAT berhenti menjadi jahat'

3

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


3

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/


2

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!


4
Apakah Anda bahkan membaca pertanyaannya? Saya tidak pernah meminta metode tentang cara melindungi dari pembajakan. Aplikasi ini akan gratis, itu adalah protokol yang digunakan yang perlu dilindungi karena sifat keamanannya.
graphitemaster

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.