Seberapa mudah untuk memecahkan perlindungan salinan berikut ini? [Tutup]

Saya mencoba menyalin-melindungi beberapa pekerjaan, yang merupakan kartu SD yang dapat di-boot mem-boot kernel Linux pada perangkat ARM (Raspberry Pi). Saya menggunakan pendekatan ini:

1. Pendekatan ini menggunakan initrd untuk me-mount sistem file root terenkripsi.
2. Initrd menghasilkan kata sandi sistem file sesuai dengan CID kartu SD. (fungsi hash digunakan, belum memutuskan md5 atau sha1). Initrd akan mencoba me-mount sistem file menggunakan kata sandi yang dihasilkan.
3. Sekarang di sini adalah bagian yang paling menarik / dicurigai: Initrd itu sendiri dienkripsi menggunakan fungsi C kustom, pada dasarnya setiap byte XOR'ed menggunakan generator acak semu yang dibuat khusus. Kernel dimodifikasi untuk memiliki fungsi enkripsi yang sama, yang berfungsi sebagai dekripsi.
4. Sistem itu sendiri dilucuti sehingga tidak ada cara untuk menggunakan keyboard atau penyimpanan eksternal. Satu aplikasi menjalankan layar penuh.

Jadi setelah bootloader memuat kernel dan initrd, kernel mendekripsi initrd dan mengeksekusi skrip initnya, yang akan menghasilkan kata sandi dan me-mount sistem file root.

Pertanyaan saya adalah: Betapa mudahnya untuk mematahkan pengaturan ini (untuk mendekripsi sistem file root dan membuatnya boot dari kartu SD apa pun)? Apa bagian yang paling lemah? Seberapa mudah mendekompilasi kernel dan menemukan fungsi-fungsi mengenkripsi kustom?

EDIT: Berikut adalah beberapa koreksi agar Anda tidak membuang waktu dengan hal-hal yang sudah jelas:

1. Perangkat root akan dienkripsi dengan LUKS (aes256) dan kunci akan dihasilkan oleh beberapa fungsi HMAC menggunakan CID kartu SD dan garam.
2. Algoritma pseudo acak untuk enkripsi initramfs sebenarnya adalah RC4, hanya kunci yang akan dihasilkan menggunakan beberapa fungsi kustom, karena jika saya hanya menyimpan kunci dalam array byte itu membuatnya sangat mudah untuk mengambilnya (ya ini adalah keamanan melalui ketidakjelasan tapi sepertinya tidak ada cara lain).
3. Saya mengerti bahwa jika menggunakan emulator kartu SD seseorang dapat membuat salinan dari sistem ini mulai tetapi ini tidak masalah bagi saya, karena itu cukup sulit dan tidak ada yang bisa melakukan ini. (Juga tidak ada yang mau berurusan dengan emulator)

Betapa mudahnya untuk mematahkan pengaturan ini (untuk mendekripsi sistem file root dan membuatnya boot dari kartu sd apa pun)?

Seberapa sulit untuk "memecah" pengaturan Anda tergantung pada jumlah bit entropi dalam metode apa pun yang Anda gunakan untuk menandatangani / mengenkripsi sistem file itu sendiri (karena ini menentukan jumlah total kombinasi unik yang dapat digunakan untuk brute-force kata sandi).

Apa bagian yang paling lemah?

Tanpa ragu, menggunakan CID yang telah ditentukan sebelumnya sebagai kata sandi, serta menggunakan fungsi pembuatan nomor pseudo-acak khusus.

CID kartu SD hanya dianggap sebagai baca-saja, tetapi tidak jarang menemukan perangkat memori flash yang tidak kompatibel di zaman sekarang ini. Beberapa orang bahkan telah menunjukkan kemampuan untuk menimpa CID dengan kartu SD tertentu. Ini akan membuatnya lebih mudah untuk memaksa kata sandi, terutama jika seseorang hanya meniru kartu SD setelah mengkloning kartu Anda (yang merupakan hal lain yang mungkin ingin Anda pertimbangkan).

Akhirnya, menggunakan segala jenis generator angka pseudo-acak sudah memiliki beberapa kelemahan intrinsik, tepatnya karena itu tidak acak - ada alasannya disebut pseudo-acak . Mungkin lebih baik menggunakan bootloader terenkripsi yang dibuat sebelumnya (seperti TrueCrypt atau LUKS, yang keduanya bekerja pada Raspberry Pi) dan menghindari keharusan membuat modifikasi kernel manual.

Seberapa mudah mendekompilasi kernel dan menemukan fungsi-fungsi mengenkripsi kustom?

Sangat sulit untuk mendekompilasi apapun. Sebaliknya, de-assembly dari aplikasi yang dikompilasi seringkali sepele, dan ada banyak alat yang dapat digunakan untuk membantu dengan perakitan rekayasa balik kembali ke bahasa tingkat yang lebih tinggi. Jika penyerang memiliki akses bahkan ke kernel yang dikompilasi, menganalisis sesuatu seperti generator nomor pseudo-acak mungkin sepele kecuali jika kode dikaburkan dengan sengaja.

TL, DR : Jangan menemukan kembali roda ketika datang ke enkripsi dan keamanan, tetap dengan yang dicoba dan benar. Ada beberapa opsi enkripsi disk lengkap yang sudah tersedia dan telah terbukti berfungsi dengan baik di Raspberry Pi. Saya akan menghindari penggunaan CID kartu SD sebagai semacam "kata sandi" - bahkan jika itu tidak dapat diubah, ada cara untuk menipu nilai ini.

Perlindungan salinan sudah termasuk dalam spesifikasi kartu SD sebagai CPRM .

Seseorang yang terampil tidak akan kesulitan memecahkan ini. Akan relatif mudah untuk mem-boot kartu SD di bawah emulator, dan kemudian hanya membaca kunci keluar dari RAM. Kemudian mereka memposting versi tanpa perlindungan salinan ke Pirate Bay (dll.), Dan hanya itu.

Sebagai alternatif, gunakan emulator untuk menyuntikkan shellcode ke dalam sistem emulasi yang sedang berjalan. Kemudian gunakan sistem yang sedang berjalan untuk menyalin rootf yang didekripsi (atau membaca kunci menggunakan dmsetup table --showkeys, dll.)

Pencarian cepat menemukan keberadaan emulator Raspberry Pi , jadi sebagian dari pekerjaan sudah dilakukan.

Anda punya masalah lain, khususnya ini:

Kernel dimodifikasi untuk memiliki fungsi enkripsi yang sama, yang berfungsi sebagai dekripsi.

Siapa pun yang Anda bagikan ini berhak mendapatkan kode sumber kernel, di bawah ketentuan GPL. Jadi Anda tidak perlu membongkar itu, Anda bisa menggunakannya diffuntuk menemukan fungsi ekstra.

(Bukan berarti menemukan melalui pembongkaran akan sulit, seperti yang Anda dapat misalnya, periksa vs kernel saham)

Saya tidak sepenuhnya akrab dengan kode boot Raspberry Pi, tetapi jika Anda dapat mem-reflash bootloader dengan kunci kripto yang tertanam (yang kemudian diteruskan ke kernel), itu setidaknya tidak ada pada kartu SD, jadi itu ' d menggagalkan upaya untuk membuatnya untuk boot di emulator.