On 2/23/07, Yenny <[EMAIL PROTECTED]> wrote: > iya...kepikirannya sih maen di coding aja... or di satu file tertentu (.INI > file) trus di umpetin di folder tertentu, tp pasti akan tetep ke detect klo > usernya jago. Ada ga yah cara lainnya?
Cara-cara lain banyak. Namun sebelumnya, perlu dipahami keadaan/kenyataan tentang software copy protection. SEMUA software copy protection bisa dijebol sehingga program bisa dikopi ke mesin lain dan dijalankan. Satu-satunya cara supaya tidak bisa dijebol adalah dengan membuat dua buah instance yang berbeda: full version dan partial version (physically crippled/incomplete). Tapi ini sebenarnya hanya metode distribusi, bukan murni termasuk mekanisme copy protection. Jika keberadaan instance yang full version sudah didapatkan, maka copy protection yang membuat software virtually crippled/incomplete/non-functional akan bisa dijebol. Copy protection secara umum ada 2 jenis: 1. Semua informasi untuk mem-verifikasi kelegalan copy/instalasi dimiliki oleh copy/instalasi tersebut (tidak butuh akses ke hal-hal yang eksternal misalnya hardware dongle, customized/protected disc, validasi dari server external via Internet/dial-up). Penjebolan untuk jenis proteksi ini bisa cukup 'memalukan', yaitu program penjebol bisa menghasilkan/generate informasi yang seharusnya hanya bisa dihasilkan oleh produser aslinya. Contoh klasiknya adalah WinZip yang penjebolnya bisa menghasilkan pasangan user dan key yang dibutuhkan -- istilah populernya: keygen (key generator). 2. Instalasi/copy butuh hal-hal eksternal. Proteksi ini bisa dijebol dengan 2 cara: a) Mengubah file program sehingga eksekusi untuk melakukan verifikasi akan selalu menghasilkan valid/benar. Ini biasanya disebut dengan: crack atau patch. b) Membuat simulasi/emulasi hal-hal yang eksternal tersebut. Misalnya untuk protected disc, dilakukan pencegatan terhadap system call yang mengakses disc/drive dan melakukan emulasi untuk memberikan hasil yang diharapkan oleh program. Untuk hardware dongle dan external server feedback, jika response yang diharapkan adalah sekedar 'VALID' atau 'INVALID', maka bisa dilakukan pencegatan juga. Namun jika yang diharapkan adalah kode-kode hasil enkripsi, akan sangat sulit untuk mengemulasinya atau melakukan cryptanalysis, terutama untuk external server feedback. Ada satu lagi jenis proteksi yaitu hardware lock-in: copy/instalasi dibuat/kustomisasi secara khusus hanya bisa berjalan di konfigurasi komputer tersebut. Caranya: user mengirimkan konfigurasi komputernya (melalui program tertentu yang disediakan oleh produser) lalu produser melakukan kustomisasi khusus untuk user ini. Proteksi ini pada dasarnya adalah tipe yang kedua (bergantung hal eksternal) dan cara penjebolannya akan analogis dengan hardware dongle. Para penjebol/cracker biasanya memiliki target yang level 'kebanggaannya' sebanding dengan kompleksitas penjebolan: 1) Time spoofing. Ini biasanya untuk instance yang full version namun dibatasi hanya bisa digunakan selama beberapa waktu (trial period). Penggunaan VMWare yang dipost rekan lain termasuk kategori ini walaupun bukan murni upaya penjebolan. Beberapa program yang kurang hati-hati bahkan bisa ditipu hanya dengan mengubah jam sistem secara sementara (pada awal loading saja, lalu dikembalikan ke jam sebenarnya). Penjebolan jenis ini pada umumnya tidak memiliki kompleksitas yang tinggi. Contoh yang aktual adalah penjebolan pada proteksi Windows Vista. Secara default, jika pada instalasi tidak dimasukkan key apapun, copy/instalasi akan masuk ke dalam evaluation/trial mode yang berlaku selama 30 hari. Periode 30 hari inipun sebenarnya bisa diperpanjang 3x lagi (total jadi 120 hari) menggunakan program yang disediakan Vista sendiri tanpa hack apapun. Penjebolan terakhir berhasil membuat Vista tertipu untuk selalu mengira baru digunakan 1 hari atau kurang. 2) Patching. Penjebolan biasanya hanya memerlukan pengubahan file pada sedikit tempat, yaitu pada saat verifikasi dilakukan. Untuk ini, penjebol hanya perlu mengamati tempat-tempat/waktu-waktu tertentu yang menjadi kandidat berlakunya verifikasi. Ini biasanya dilakukan dengan debugging tools tanpa harus melakukan reverse engineering yang terlalu banyak. Namun karena ada file yang diubah, para konsumen (pemakai hasil penjebolan) biasanya lebih memilih untuk memasukkan sendiri informasi/key yang dibutuhkan. Ini masuk kepada penjebolan berikutnya: key generator. 3) Key generator dan external factor emulation. Penjebolan ini kompleksitasnya paling tinggi. Supaya bisa menghasilkan informasi yang bisa diverifikasi secara normal (tanpa hack) oleh program, maka penjebol perlu melakukan reverse engineering untuk mengetahui bagaimana/algoritma program tersebut dalam melakukan verifikasi. Dari paparan di atas, kesimpulannya adalah: semua proteksi bisa dijebol. Namun begitu, bukan berarti software tidak perlu diproteksi (pembahasan ini ruang lingkupnya adalah software komersial, bukan open source). Yang perlu dipikirkan dan diputuskan adalah: akan diproteksi sampai tahap mana dan terhadap siapa. Basis usernya sedikit atau banyak, fungsinya spesifik atau umum, kustomisasi bergantung pada keterlibatan produser atau minimal, ada trade secret atau tidak (copy protection berguna untuk deter/menurunkan niat untuk dikopi ke banyak orang sehingga kemungkinan jatuh ke tangan reverse engineer handal lebih kecil), dsb. Jika ini adalah tugas kantor (software produksi perusahaan tempat kita bekerja), biasanya saya mulai dengan menjelaskan fakta bahwa tidak ada proteksi yang 100% aman dari penjebolan. Berikutnya, dianalisa penggunaan software tersebut sendiri dan dirembukkan sampai tahap apa kompleksitas proteksi yang dibutuhkan. Setelah diputuskan kemudian dibuat implementasi paling sederhana sebagai proof of concept (POC) pada tahap yang disetujui. Pengalaman saya, bersama dengan software protection, juga dibutuhkan verifikasi penggunaan jumlah user yang dilisensi (biasanya pada software yang server based) dan user registration (informasi nama, alamat, kontak, dll). POC bisa dilakukan secara sendiri-sendiri maupun terintegrasi. Pengalaman lagi, karena biasanya deadline mepet, POC sering naik statusnya jadi production code. Karena itu, dalam POC juga tidak bisa terlalu 'culun' proteksinya. Sori jadi kepanjangan nulisnya. Mungkin bisa mulai dulu dari software yang akan diproteksi ini bagaimana akan digunakannya. Pelan-pelan dari situ bisa dianalisa kebutuhan proteksinya. Regards, G. Tanuel
