Наскільки легко зламати такий захист від копіювання? [зачинено]

Я намагаюся захистити від копіювання певну роботу, яка є завантажувальною SD-картою, яка завантажує ядро ​​Linux на пристрої ARM (Raspberry Pi). Я використовую такий підхід:

1. Підхід використовує initrd для монтажу зашифрованої кореневої файлової системи.
2. Інітдр генерує пароль файлової системи відповідно до CID картки SD. (використовується хеш-функція, ще не визначившись над md5 або sha1). Initrd спробує змонтувати файлову систему за допомогою створеного пароля.
3. Тепер ось найцікавіша / підозріла частина: Сам initrd шифрується за допомогою користувацької функції C, в основному кожен байт XOR'ed, використовуючи створений на замовлення псевдо випадковий генератор. Ядро модифіковане так, щоб мати ту саму функцію шифрування, яка працює як дешиптор.
4. Сама система знімається, тому немає можливості використовувати клавіатуру або зовнішнє сховище. Одне додаток працює на весь екран.

Отже, після завантаження завантажувача ядра та initrd, ядро ​​розшифровує initrd та виконує його скрипт init, який створить пароль та змонтує кореневу файлову систему.

Моє питання: Наскільки легко було б порушити цю установку (розшифрувати кореневу файлову систему та зробити її завантаженням із будь-якої SD-карти)? Які найслабкіші частини? Наскільки легко декомпілювати ядро ​​та знайти ці власні функції шифрування?

EDIT: Ось деякі виправлення, щоб ви не витрачали час на очевидні речі:

1. Кореневий пристрій буде зашифровано LUKS (aes256), і ключ буде згенерований деякою функцією HMAC, використовуючи CID SD-карти та трохи солі.
2. Псевдослучайний алгоритм шифрування initramfs буде насправді RC4, просто ключ буде генерований за допомогою якоїсь спеціальної функції, тому що якщо я просто зберігаю ключ у масиві байтів, це робить його мертвим простим його отримання (так, це безпека через неясність але іншого способу, здається, немає).
3. Я розумію, що за допомогою емулятора SD-карти хтось може зробити копію цієї системи, але це зі мною все в порядку, оскільки це досить складно, і ніхто не може це зробити (також ніхто не захоче мати справу з емуляторами)

Наскільки легко було б порушити цю установку (розшифрувати кореневу файлову систему та зробити її завантаженням з будь-якої SD-карти)?

Наскільки важко "зламати" налаштування, залежить від кількості біт ентропії в будь-якому методі, який ви використовуєте для підписання / шифрування самої файлової системи (оскільки це визначає загальну кількість унікальних комбінацій, які можна використовувати для грубої сили пароль).

Які найслабкіші частини?

Без сумніву, використання заздалегідь заданого CID в якості пароля, а також використання спеціальної функції генерації псевдовипадкових чисел.

Ідентифікатор CID SD-картки повинен бути лише для читання, але не рідкість у цей день та вік знайти невідповідні пристрої флеш-пам’яті. Деякі люди навіть продемонстрували можливість замінити CID певними картами SD. Це полегшило б жорстоке введення пароля, особливо якщо ви просто емулюєте SD-карту після клонування вашого (це щось інше, що ви можете розглянути).

Нарешті, використання будь-якого генератора псевдовипадкових чисел вже має деякі внутрішні вади, саме тому, що це не випадково - є причина, яку називають псевдовипадковою . Можливо, краще використовувати заздалегідь зашифрований завантажувач (наприклад, TrueCrypt або LUKS, які обидва працюють на Raspberry Pi) і уникати необхідності вносити будь-які модифікації ядра вручну.

Наскільки легко декомпілювати ядро ​​та знайти ці власні функції шифрування?

Декомпілювати щось дуже важко. І навпаки, де-збірка складеної програми часто буває тривіальною, і існує безліч інструментів, які можуть бути використані для надання допомоги зі зворотної інженерної збірки назад на іншу мову вищого рівня. Якщо зловмисник має доступ навіть до складеного ядра, аналіз чогось подібного генератора псевдовипадкових чисел, ймовірно, є тривіальним, якщо код не замислюється навмисно.

TL, DR : Не вигадуйте колесо, коли йдеться про шифрування та безпеку, дотримуйтесь випробуваного та справжнього. Існує кілька варіантів шифрування повного диска, які вже доступні, і було продемонстровано, що вони добре працюють на Raspberry Pi. Я б уникнув використання CID SD-карти як свого роду "пароля" - навіть якщо його неможливо змінити, є способи підробляти це значення.

Захист від копіювання вже включений у специфікацію SD-карти як CPRM .

У когось кваліфікованого не виникне особливих проблем з цим виправленням. Завантажити SD-карту під емулятором було б досить просто, а потім просто прочитати ключі з оперативної пам'яті. Потім вони розміщують версію без захисту від копіювання в Pirate Bay (тощо), і це все.

Крім того, використовуйте емулятор для введення коду оболонки в працюючу емульовану систему. Потім скористайтеся запущеною системою, щоб скопіювати розшифровані корені (або прочитати ключі за допомогою dmsetup table --showkeysтощо)

Швидкий пошук виявляє існування емуляторів Raspberry Pi , тому частина роботи вже зроблена.

У вас є ще одна проблема, зокрема ця:

Ядро модифіковане так, щоб мати ту саму функцію шифрування, яка працює як дешиптор.

Кожен, кому ви поширюєте це, має право на вихідний код ядра згідно з умовами GPL. Тож вам не потрібно було би його розбирати, ви можете просто скористатися diffдля пошуку додаткової функції.

(Не те, щоб знайти його за допомогою демонтажу було б настільки важко, як ви можете, наприклад, перевірити порівняно з запасом ядра)

Я не повністю знайомий з завантажувальним кодом Raspberry Pi, але якщо ви можете переробити завантажувач за допомогою вбудованого криптовалюти (який потім передається в ядро), це, принаймні, не буде на SD-картці, так що ' d сфолікуйте спробу змусити його завантажитися в емулятор.