Справа про обфускування коду?

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

=========

Фон:

Це спроба цілеспрямовано оскаржити мої припущення з цієї теми.

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

Коли відкритий код є шалено популярним, видається, що "поділитися кодом чи зберегти його власником?" Що стосується комерційного коду, я можу зрозуміти, чому ви не можете поділитися всім, і у вас є закон у вашій боротьбі з крадіжкою.

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

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

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

Це форма стеганографії , натхненна і змінена криптографічними схемами "відстеження зрадників" . Я не маю уявлення, чи є це загальним ¹ або навіть якщо це гарна ідея, але я бачив, що він застосовується на практиці за такими параметрами:

• Високо конкурентоспроможний загальнодержавний ринок з двома постачальниками,
• Близько 50 розгортань охопили ринок,
• Середній час розробки для обох додатків склав пару років (більше чи менше),
• Середній час обфускування для нашої програми склав пару годин,
• Очікували, що тривалість обох застосувань складе близько десяти років.

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

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

Іншим дійсним випадком використання придушення може бути те, коли ви якось юридично зобов’язані подати свій код третій стороні :

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

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

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

Тепер, оскільки Javascript є канонічним прикладом придушення, є один побічний ефект, який зазвичай не розглядається, і який приховує шкідливий код у затуманеному Javascript. Хоча в мінімізації ^3-х JavaScript є певні переваги , я не бачу жодного сенсу у фактичному затуманенні, і я радий, що Дуглас Крокфорд погоджується зі мною :

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

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

На закінчення, затуманення є типовим прикладом безпеки через неясність, лише очевидна заслуга - це стримуючий ефект і нічого більше. Можуть бути випадки творчого використання ^{4, яких} я не знаю, але загалом переваги мінімальні, у кращому випадку.

_{¹ Написавши це, я з’ясував цю відповідь, яка в основному описує ту саму схему, тож, можливо, буде більш поширеним, що я думав.
² Хоча стеганографія все ще є безпекою через неясність.
³ Мінімізація ~ видалення пробілів та скорочення жетонів, а не навмисне затемнення.
⁴ Чи враховується Міжнародний конкурс з прихованих кодів С ?}

Справа в обфускуванні коду полягає в тому, що він піднімає планку для третьої сторони, щоб визначити, що / як працює код.

Однак це НЕ означає, що розробник повинен коли-небудь писати прихований код.

Дивіться, це трохи, на мою думку, відсутнє у вашому запитанні: обфускування коду (як і мінімізація JavaScript) розробник не повинен - ​​і не повинен - ​​робити вручну. Крім того, це також не слід зберігати як основні файли вихідного файлу в контролі версій.

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

Наприклад: Dotfuscator

В IEEE є документ про ефективність обфузації коду

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

Наголос мій.

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

Звичайно, перед тим, як доставити клієнта у великий великий світ там, ми переконалися, що його притупити. Ми вважаємо, що обфузація мала такі наслідки:

1. Це стримувало неекспертних хакерів навіть не намагатися.
2. Це затримало експертів-хакерів у досягненні будь-яких хак.
3. Це зменшило кількість хакерів, досягнутих експертними хакерами.
4. Це обмежило ефективність хакерів.
5. Найголовніше: це змусило хакерів виконувати більше тестових пробігів зі своїми зламаними клієнтами проти наших серверів, перш ніж досягти робочого хака, що збільшило шанси нас виявити їх, шукаючи нерегулярну активність у журналах сервера.

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

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

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

Читання та розуміння (і, очевидно, написання) прихованого коду може бути цікавим розумовим завданням. Це, мабуть, виходить за рамки того, що ви просили, але такі приклади, як IOCCC, можуть бути джерелом розваг, а також жаху.