Що ви використовуєте для згуртування / шифрування даних?

Все більше і більше ігор проходить маршрут, керований даними, що означає, що навколо простого маніпулювання повинен бути рівень безпеки. Я бачив, коли ігри повністю накопичують свої активи (аудіо, мистецтво, дані), і мені цікаво, як їм це керувати? Чи існують програми / бібліотеки, які допоможуть вам керувати активами? Якщо ні, чи є якісь хороші ресурси, які ви б вказували на упаковку / розпакування / шифрування?

Це конкретне запитання обертається навколо C ++, але я би відкритий, щоб почути, як це керується і в C # / XNA.

Щоб було зрозуміло - я не збираюся розробляти рішення, щоб запобігти злому. На фундаментальному рівні ми всі маніпулюємо 0 і 1. Але ми хочемо, щоб 99% людей, які грають у гру, просто не змінювали XML-файли, які використовуються для створення ігрового світу. Я бачив безліч ігор, які збирають усі свої ресурси разом. Мені просто цікаво про методи, які вони використовують.

Хороша стратегія - зробити власний формат архіву з нуля і зробити його індексованим із таблицею, що вказує на фрагменти даних, а не зберігати цілі послідовні файли у вашому архіві, а потім зашифрувати свою таблицю індексів і стиснути кожен фрагмент окремо за допомогою LZMA / Bzip2.

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

Але я знаходжу такі методи, як правило, перешкоджають продуктивності та витрачанню часу на розробку, весь час не пропонуючи кінцевому користувачеві нічого, окрім потенційних проблем та непотрібних помилок.

Тим не менш, нічого не є 100% безпечним.

Не надсилайте конфіденційні дані.

Немає способу надсилати зашифровані дані, щоб лише гра могла отримати доступ до них. Ви можете дуже постаратися, але швидко ввійдете в проблеми DRM.

Якщо ви хочете утримувати свої ігрові активи далеко від сторонніх очей.

1. застебніть його
2. xor файл
3. змінити розширення на щось нудне (тобто не my_level.zip.xorвикористовувати my_level.map).

Це зупинить 95% недоброзичливих користувачів. Інші 5% збираються отримати це незалежно від того, що ви робите.
Вам не потрібно насправді блискавки та xor. Ви можете замість цього lzma і використовувати AES з відомим ключем. Сенс у тому, щоб не витрачати на це багато часу.

Витрачати на це будь-яку велику кількість часу, мабуть, нерозумно. Існують інструменти для збору даних про текстуру та модель безпосередньо з графічного процесора, і звуки легко вказувати на віртуальний пристрій зворотного зв'язку. Все, що має бути справді безпечним, потрібно жити на сервері та працювати лише через виклик / відповідь. Проведення перевірки даних клієнтів - це вже інша історія, щось на кшталт Valve -verify_all. Це все ще важко, оскільки ви не можете довіряти місцевому виконуваному файлу для його виконання (або, принаймні, ви не можете довіряти йому більше, ніж ви довіряєте своїй кінцевій точці системи проти обману, що також є дурною ідеєю).

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

Добре запитання, але це питання далеко не просто.
З мого досвіду безпеки даних ви повинні думати про наступне:

1) Що ви захищаєте, від кого і який вплив, якщо ці дані є незахищеними - безпека набагато більше стосується оцінки ризиків, ніж систематичних технічних рішень
2) Я вважаю, що ваша платформа є настільною (наприклад, Windows / OSX) у тому випадку, якщо у вас є інший проблемний простір, ніж власницьке обладнання, таке як PS3 / Xenon, у яких є власні спроби забезпечення рівня ядра (чи це правильне рішення, відкрите для обговорення)
3) Шифрування! = безпека. Шифрування гарантує лише те, що ваші дані не можуть бути прочитані , але це не гарантує, що ваші дані не можуть бути записані або відтворені / проксі.

Якщо ваші вимоги полягають у захисті ваших даних, тоді вам потрібно подумати про хешування ваших даних (бажано з SHA-256 або SHA-512). Однак для повторної ітерації подумайте, чому це важливо і що ви отримуєте, додаючи безпеку вашим система.
Варто також знати, що додавання технологій шифрування до вашого продукту може мати юридичні наслідки через обмеження експорту (технологія шифрування класифікується як обмежена технологія зброї, вірите чи ні), тому використання бібліотек, які подолали ці юридичні проблеми, доцільно.
Нарешті - ніколи, ніколи не кочуйте власну технологію шифрування - використовуйте відомі, задокументовані, досліджені алгоритми, такі як AES, Blowfish, RSA тощо

ps Публічний / приватний ключ не підходить і не практичний для шифрування великої кількості даних, отже DRM / PGP тощо використовуйте гібридну RSA + симетричну систему, тобто закріпіть симетричний ключ за допомогою RSA, а потім виконайте стандартне симетричне шифрування за допомогою цього ключа

Це дуже велика складна тема, і я точно не зробив це справедливістю

Сподіваюся, що це допомагає

Якщо ви хочете, щоб приклад формату, який був розроблений і побудований (можливо, переобладнаний) для того, щоб бути малим (стисливим), смішно безпечним та гнучким, слід звернути увагу на формат MPQ Blizzard.

http://wiki.devklog.net/index.php?title=The_MoPaQ_Archive_Format

Загальний макет архіву такий:

Дані файлу в заголовку архіву - Спеціальні файли Таблиця блоків таблиць Розширена таблиця блоків Сильний цифровий підпис

Цей формат має ВСЕ. Блокований блок, розширений блокблок, розбиття даних на сектори (для зручного потокового передачі), підтримка 7 (!) Алгоритмів стиснення (якщо рахувати стиснення звуку), які можна комбінувати довільно, слабкий цифровий підпис, сильний цифровий підпис тощо.

Якби ви купували API у Blizzard, який займається архітектурою файлів, ви отримали б все, що вам знадобилося, і багато іншого.

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

Я думав, що кину ще одну атаку в розмові, на щось, на що я потрапив лише минулого року, оскільки я не схильний надсилати багато на ПК. Cheat Engine - це дуже охайна маленька програма, яка майже автоматизує створення власних хак (це означає, що кожен може ним користуватися). Він досить просунутий у тому, що він може зробити, багато хак / читів, які я бачив, як люди продають, зроблені цим або чимось дуже схожим на те, що я бачив (усі на масовому ринку). Завдяки певній роботі ви зможете захиститись від подібних речей, я думаю, все залежить від того, наскільки популярна гра та чи хтось піклується про те, щоб турбувати.

Опс, забув згадати гарну лібку для шифрування (в C ++) - це LibTomCrypt .