Десктопний застосунок постачає свій JavaScript на власний диск користувача, разом із перевіркою ліцензії, де його можна спокійно читати й редагувати.
app.asar розпаковується, а перевірка ліцензії змінюється одним рядком
Встановлюючи ваш застосунок, користувач встановлює ваш вихідний код. app.asar розпаковується однією командою, і після цього main, preload і renderer стають звичайними читабельними файлами на диску. Суто локальна перевірка ліцензії зазвичай є одним порівнянням або одним раннім поверненням, і щоб її обернути, досить змінити один рядок.
Така зміна не залишається приватною. Пропатчений файл або невеликий скрипт, що вносить ту саму зміну, поширюється як кряк і працює на кожній копії цього релізу.
Один сід для main, preload і renderer
@afterpack/electron обфускує всі три програми одним викликом і використовує для них спільний seed, тож main, preload і renderer виходять узгодженими між собою. Саме ця узгодженість гарантує, що обидва боки IPC-каналу використовують однакову назву каналу.
Кожна збірка отримує новий сід, тож кожен реліз виходить іншої форми. Патч або скрипт, написаний під один реліз, не застосовується до наступного, який ви випустите, і його автору доводиться знову шукати перевірку в збірці, яка вже не схожа на ту, з якою він працював.
Підключіть це до релізної збірки
Сторінка Electron описує встановлення плагіна та підключення кожної частини. Для релізної збірки підвищте рівень захисту всього застосунку в одному місці:
// electron.vite.config.ts
withAfterpack(config, { preset: "hard" });Коли кожна частина збирається окремою командою, а не через один виклик плагіна, закріпіть AFTERPACK_seed для всіх цих команд, щоб частини все одно мали спільну форму. Розділ Один сід, три способи пояснює, яким інструментам це потрібно.
Не пускайте Protection Map, резервні копії та source map у запакований застосунок: .afterpack/, *.backup.* і *.map мають бути в glob-шаблонах виключень вашого пакувальника, бо .map усередині app.asar віддає ваш оригінальний вихідний код так само прямо, як розпакований JavaScript. На сторінці Electron перелічено, що саме плагін відмовляється збирати.
Перевірте, що кожна частина захищена
Кожна частина записує власну Protection Map у .afterpack/<leg>/, тож ви можете відкрити main, preload і renderer окремо й переконатися, що файл із перевіркою ліцензії захищено. Запустіть afterpack verify на зібраному результаті перед пакуванням, як ворота, що перехоплюють збірку, до якої захист не застосувався.
Де закінчуються можливості офлайн-перевірки
Нова форма на кожному релізі — реальна ціна для того, хто хоче обійти перевірку: роботу доводиться виконувати з нуля щоразу, коли ви випускаєте реліз, і кожне опубліковане оновлення робить кряк для попереднього релізу застарілим.
Офлайн-перевірка однаково має правильно виконуватися на машині користувача, тож за достатнього часу на одному релізі її можна знайти й пропатчити. Для всього, від чого залежить дохід, підкріплюйте клієнтську перевірку викликом до власного сервера.
Далі
- Electron: встановлення, підключення, матриця підтримки і що плагін відмовляється збирати.
- Директиви: як позначити одну ділянку, наприклад перевірку ліцензії, для сильнішого захисту, ніж решта програми (Pro).
- Модель загроз: до чого може дістатися той, хто запускає ваш код.