Как на базе NW.js сделать exe-приложение в виде одного единственного exe-файла?

Question

[med1um]

Сейчас на выходе nw-builder получается каталог с кучей файлов и двумя exe-шниками:



Как сделать чтобы на выходе получалось одно exe-приложение?

Comments

[Сергей c0re]

самораспаковывающийся архив.
но запускаться дольше будет, один nw.dll на 120Мб

Answer 1

[xmoonlight]

1. Официальная wiki-документация по созданию дистрибутива.
2. Воспользуйтесь инсталятором.
Советую InnoSetup

Comments

[Inviz Custos]

Автор конечно не упоминал какое у него приложение, но в случае использования инсталятора - пользователям остаются доступными исходники, что вполне может быть критично для автора

[xmoonlight]

Inviz Custos, Увернись-ка вот от этого! ;)

[Inviz Custos]

xmoonlight, мы говорим конкретно об инсталяторе.
С bytenode я знаком. В нем есть некоторые баги, из-за которых он применим не ко всем версиям Node.js, из-за чего мне пришлось для своего тулкита (который я пилю специально для целей затруднения получения исходников) реализовывать все это заново, чтобы была поддержка версий с 6 и до 12.
Но не стоит забывать, что снапшоты - эте не панацея, а лишь неплохая дополнительная помеха, которая не даст быстро получить исходники. (злоумышленникам придется прибегнуть к инструментам типа IDA Pro и им подобным)
Enigma Virtual Box можно использоваться вместе с генерацией снапшотов. Это еще больше затруднит получение исходников.
Но именно сам инсталятор никаким образом не помогает защитить исходники.

[xmoonlight]

Inviz Custos, обычно исходники можно обфуцировать и потом в байт-код. Не думаю, что кто-то захочет настолько возиться, чтобы получить читаемый код. Иначе - нет смысла такое отдавать "на руки" - только на бэкенде хранить. Тут весы: сложность доступа или простота покупки/разработки.

[Inviz Custos]

xmoonlight, тут уже все зависит от того, насколько злоумышленникам надо то, что находится внутри ПО.
Если очень надо, то даже снимают такие протекторы, как Enigma Protector, Themida и им подобные. Снятие виртуальных машин, которые были сгенерированы этим протекторами, может занимать до 6 месяцев (при полном рабочем дне опытного реверс-инженера), но при целенаправленном взломе ПО это никого не останавливает.

[xmoonlight]

Inviz Custos, про то и речь. Поэтому абсолютно - не защититься. А рассчитывать трудозатраты и целесообразность на определённую степень защиты исходного кода - нужно уметь и этим пользоваться.

[Inviz Custos]

xmoonlight, байткод, который будет сгенерирован при помощи bytenode скорее всего не будет работать внутри NW.js , так как в NW.js используется пропатченая версия ноды. Там на самом деле очень много нюансов, из-за которых байткод не будет работать (это обнаружилось в процессе копания в исходниках V8, когда я пили себе аналог bytenode).
Поэтому Enigma Virtual Box, наверное, самый приемлемых вариант для автора, чтобы защитить исходники и сохранить 100% работоспособность.

P.S. из-за особенностей работы TurboFan генерация байткода может съесть примерно 30-40% производительности приложения.

[xmoonlight]

Inviz Custos,

байткод, который будет сгенерирован при помощи bytenode скорее всего не будет работать внутри NW.js , так как в NW.js используется пропатченая версия ноды.

Проверьте!

[Inviz Custos]

xmoonlight, проверял, поэтому и говорю)
Даже сам автор bytenode в примере для NW.js показывает, что генерацию снапшота надо вызывать из рантайма NW.js , а не просто из консоли.

Попробуйте создать снапшот из консоли, и получите вот это:
(скрин из DevTools NW.js)

[Inviz Custos]

xmoonlight, и это только одна из особенностей.
Вот пример второй особенности:
При генерации снапшота Node.js учитывает аппаратные возможности конкретно текущего железа, и снапшот генерируется с учетом этих особенностей. Поэтому, то, что будет работать у Вас, не будет работать у некоторых других пользователей.
Эта особенность чаще всего проявляется на винде.
Эмпирическим путем получилось собрать некоторую статистику - приложение не работало примерно у 30-40% пользователей. (Общее количество пользователей было чуть больше 1000).

Частично это проблему у себя я решил, но не до конца.
Для сбора дополнительной статистики я даже создавал тему на одном из форумов - www.cyberforum.ru/beta-testing/thread2488984.html

[Inviz Custos]

xmoonlight, не думайте, что я все это беру "с потолка".
Это те "грабли" (при том далеко не все), на которые пришлось "наступить" в ходе разработки тулкита для защиты исходников.

[xmoonlight]

Inviz Custos, не знаю, а что по поводу использования WebAssembly (некий ключ на С++ прогнать на emscripten) и с помощью него - грузить бинарные данные во время исполнения? Не пробовали?

[Inviz Custos]

xmoonlight, это только упростит задачу злоумышленнику. В таком коде будет меньше мусора и проще будет понять логику.
Основная моя идея состоит в том, чтобы иметь возможность хоть как-то затруднить получение исходников без кардинальных изменений самого проекта.
Если же заниматься модификацией проекта с целью его защиты, то (в случае, если приложение под Windows) достаточно эффективным способом является написание аддонов для Node.js , в которые переносится часть критически важного функционала. Затем эти аддоны сверху "накрываются" протекторами (например, я использую Enigma Protector). Такой подходи в большинстве случаев отбивает желание реверсить приложение у начинающих и относительно опытных реверс-инженеров, так как это потребует очень много времени.

На, как я упоминал выше, от целенаправленного влома это не спасет, а лишь оттянет его на пол года максимум.

[xmoonlight]

Inviz Custos,

это только упростит задачу злоумышленнику. В таком коде будет меньше мусора и проще будет понять логику.

ну я бы так не сказал, что все знают WebAsm!)
А данные (весь исходный js-код) - будут именно ЗАШИФРОВАНЫ функцией с ключом, который будет внутри кода WebAsm!

[Inviz Custos]

xmoonlight, без разницы что это, если в итоге это все превращается в машинные инструкции, которые как раз и декомпилят)
Попробуйте поюзать IDA Pro, Вам понравится)

[xmoonlight]

Inviz Custos, ну если так - то всё превращается в такие инструкции) Смысл вообще шифровать, да?)

[Inviz Custos]

xmoonlight, смысл в том, что у протекторов есть специальные механизмы, которые пару "чистых" машинных инструкций превращают в дикий ад. В итоге, оригинальный код теряется в миллионах "мусорных" инструкций.

[xmoonlight]

Inviz Custos, не знаю ничего круче, чем сделать это 2-3 мя функциями на С, скомпилированных в webasm, которые будут загружать зашифрованные JS-данные для дальнейшего исполнения.
Вот тут - нужно будет вскрыть всю формулу шифрования JS-кода из webasm и восстановить её для повтора. И это точно применимо даже для обычных сайтов! (вне ноды)

В итоге, оригинальный код теряется в миллионах "мусорных" инструкций.

Это хорошо только для исполняемых файлов (да и не так сильно теряются-то при отладке во время выполнения...).

[Inviz Custos]

не знаю ничего круче, чем сделать это 2-3 мя функциями на С, скомпилированных в webasm, которые будут загружать зашифрованные JS-данные для дальнейшего исполнения.

Кто мешает разреверсить ничем не защищенный механизм, который расшифровывает наш JS ?
Или же поставить в дебагаре хук, который будет перехватывать уже расшифрованный JS ?
Ну или просто достать байткод из рантайма после того, как все прогрузится.
Этот код никак не "сопротивляется" отладке.

Это хорошо только для исполняемых файлов (да и не так сильно теряются-то при отладке во время выполнения...)

Вы не поняли как работают протекторы.
Протектор генерирует виртуальную машину (как, например, JVM, CLR, V8 и т.д). Далее Ваш исполняемый код превращается в байткод для этой виртуальной машины. И ко всему этому этот байткод сильно разбавляется мусором.
То есть (если совсем "на пальцах") - для вашего исполняемого кода создается свой собственный "язык" и генерируется виртуальная машина для него.
Можно сделать так, чтобы для каждой функции в исполняемом файле генерировалась своя виртуальная машина.
Ну и ко всему этому такое приложение умеет "сопротивляться" отладке.
Даже если у вас выйдет пробраться через все антиотладочные механизмы, то на "вскрытие" виртуальной машины может уйти до 6 месяцев работы очень опытного реверсера.
Но у такого механизма есть единственный минус - сильные просадки производительности, поэтому защищаются только самые критические участки приложения.

[xmoonlight]

Inviz Custos,

Вы не поняли как работают протекторы.

Нет. Вы ошиблись.
Я говорю про то, что этот же функционал можно повторить указанным мной способом в любой среде исполнения. А то, что Вы хотите сказать, что виртуалка из exe-шника надёжнее виртуалки на основе webasm - это, скорее всего ВЫ не поняли, как работают протекторы/дебаггеры.

Я понял, что Вы увидели Энигму и "тащитесь" на волне эйфории и предвкушения того, как она будет надёжна, когда попробуют добраться до исходника вашего проекта!
Т.к. у Вас нет никакого другого опыта, особенно - собственного алгоритма/решения защиты.

Надеюсь, что Вы понимаете меня и то, что я пытаюсь донести...

[Inviz Custos]

Я говорю про то, что этот же функционал можно повторить указанным мной способом в любой среде исполнения

Не-а, не повторите. Результат компиляции в WebAssembly представляет собой AST для готовой виртуальной машины, которая никогда не меняется, и принцип работы которой у злоумышленника как на ладони - https://github.com/sunfishcode/wasm-reference-manu...
Или же готовая тулза для реверса webasm - https://www.pnfsoftware.com/jeb/demowasm
Также у него есть исходники V8, чтобы достать наш код из рантайма.
И ко всему этому этот код никаким образом не сопротивляется отладке.

Вы хотите сказать, что виртуалка из exe-шника надёжнее виртуалки на основе webasm - это, скорее всего ВЫ не поняли, как работают протекторы/дебаггеры.

Не поверите, очень даже представляю. А вот Вы, к сожалению, так и не поняли, что я пытался Вам донести.
Небольшой секрет - приложение, которое накрыто протектором, у Вас не выйдет легко и просто запустить под отладчиком. Если не верите, могу вам скинуть бинарник для тестов.

Я понял, что Вы увидели Энигму и "тащитесь" на волне эйфории и предвкушения того, как она будет надёжна, когда попробуют добраться до исходника вашего проекта!

Больше похоже на то, что у Вас заканчиваются аргументы, чем на какой-то конструктивный ответ.
Энигму (да и не только ее) я "увидел" еще лет 9 назад и прекрасно осведомлен о проблемах подобных подходов. Так что не переживайте, никакой эйфории нет.

Т.к. у Вас нет никакого другого опыта, особенно - собственного алгоритма/решения защиты.

Работая в сфере, где клиентскую часть твоего приложения пытается разреверсить чуть ли не каждый второй OOG'шник чтобы напакостить, другого опыта как раз и хватает.
Могу предположить, что у вас нет большого опыта в сферах, которые не связаны с WEB'ом, иначе я не могу объяснить фанатичную веру в WebAsm и веру в то, что если этот код скомпилирован, то никто не узнает что там внутри.

Но да ладно, все равно каждый останется при своем мнении.

[xmoonlight]

Inviz Custos,

Не-а, не повторите. Результат компиляции в WebAssembly представляет собой AST для готовой виртуальной машины, которая никогда не меняется, и принцип работы которой у злоумышленника как на ладони - https://github.com/sunfishcode/wasm-reference-manu...
Также у него есть исходники V8, чтобы достать наш код из рантайма.
И ко всему этому этот код никаким образом не сопротивляется отладке.

ОК!
Открою тоже секрет тогда: виртуальная машина - это то, что находится между webasm и js! (а не то, про что Вы подумали) Это тот же block-chain, который пронизывает всю логику вызовов.

Небольшой секрет - приложение, которое накрыто протектором, у Вас не выйдет легко и просто запустить под отладчиком.

Ну, вот, опять! Всё можно запустить и отладить с помощью kernel-hook-dbg (только вот спорить не нужно тут!)!

Могу предположить, что у вас нет большого опыта в сферах, которые не связаны с WEB'ом, иначе я не могу объяснить фанатичную веру в WebAsm и веру в то, что если этот код скомпилирован, то никто не узнает что там внутри.

(я не пишу с маленькой местоимение при обращении, но не суть!) Никто не думает, что никто не узнает. Сложность выявления того, что он делает там достаточно высока, чтобы этим пользоваться для затруднения восстановления логики работы всего исходного кода приложения.

Есть ещё множество способов, которыми можно защищать не хуже JIT.
Да та же асинхронность исполнения - уже действенное припятствие!

[Inviz Custos]

Ну, вот, опять! Всё можно запустить и отладить с помощью kernel-hook-dbg

К примеру Themida (на которую я планирую переходить с Энигмы) умеет сопротивляться даже этому по косвенным признакам, поэтому не выйдет решить эту проблему "в лоб", там придется поизвращаться.
Также под ней не выйдет просто взять и сдампить процесс даже из ring0 (kernel).
Проверить, что это работает, Вы можете просто - попробуйте найти "крякнутую" Themida версии 3 и выше на просторах интернета. Ее просто нету.

Открою тоже секрет тогда: виртуальная машина - это то, что находится между webasm и js! (а не то, про что Вы подумали) Это тот же block-chain, который пронизывает всю логику вызовов.

Вы не поняли что я имел в виду. Я говорил о том, что у виртуальной машины WebAsm есть открытая спецификация, где на блюдечке предоставлена вся информация, вплоть до опкодов инструкций. Даже готовые инструменты есть, которые WebAsm декомпильнут в удобный для нас вид.

Сложность выявления того, что он делает там достаточно высока, чтобы этим пользоваться для затруднения восстановления логики работы всего исходного кода приложения.

Если скомпилить wasm "как есть", то это никак не защитит от восстановления логики.

Есть ещё множество способов, которыми можно защищать не хуже JIT.

JIT, он же TurboFan (ну или CrankShaft в старых версиях) в случае V8, никак не защитит код, так как "сырой" байткод можно выцепить еще до его оптимизации. Или вообще можно выцепить исходное AST еще до попадания его Ignition.

Да та же асинхронность исполнения - уже действенное припятствие!

Наличие исходников в открытом доступе "умножает на ноль" весь профит.

[Inviz Custos]

xmoonlight, суть, которую я пытаюсь Вам донести - протекторы, которые Вы так не любите, каждый раз "придумывают" новый "язык программирования" со своей уникальной архитектурой, набором инструкций и т.д, и генерируют для него виртуальную машину. А затем исходное приложение переводится в инструкции для этой новой виртуальной машины.
Даже если одним и тем же протектором накрыть одно и то же приложение - они будут иметь разные виртуальные машины.
Основной профит от этого подхода - об этом новом "языке" и его виртуальной машине абсолютно никто ничего не знает.
Вы даже не сможете построить граф переходов, так как вам неизвестны опкоды инструкций.

Из этого и вытекает сложность в восстановлении логики исходного приложения.
Для того, чтобы во всем этом разобраться, у реверсеров уходят целые месяцы времени.
Но в этом одновременно и минус - потратив кучу времени на взлом виртуальной машины, есть возможность написать автоматизированный unpacker для этой версии протектора.
Но как правило, к этому моменту уже выходит новая версия протектора с измененным алгоритмом генерации виртуальной машины, и весь процесс взлома приходится повторять заново.
Поэтому Вы никогда не найдете unpacker для самых последних версий протекторов (разве что если протектор пару лет не обновлялся).

[xmoonlight]

Inviz Custos, суть - понятна: формула (это как раз "скелет") + "magic number" (для смешивания логики = "генерации лабиринта") = сгенерированная вирт.машина.
Тоже самое - можно сделать и с WebAsm+JS.

[Inviz Custos]

суть - понятна: формула (это как раз "скелет") + "magic number" (для смешивания логики = "генерации лабиринта") = сгенерированная вирт.машина.

Не-а, не угадали

[xmoonlight]

Inviz Custos, я не гадал. это так и есть.
Ладно, готов послушать как они там

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

в Вашем понимании.

[Inviz Custos]

xmoonlight, смотрите глубже. Представьте, что сгенерированная протектором виртуальная машина это своеобразный виртуальный процессор со своей собственно архитектурой. Не всеми нами любимые x86_64, ARM, etc, а какой-то совершенно новой, о которой никто не знает. Со своими регистрами (или вообще без них в случае стековой машины), своей организацией памяти, etc.
Это как если бы Вы были Embedded-разработчиком, а Вам дали новую неизвестную железку (без data sheet к ней), а также готовый бинарник прошивки. Как вы будете реверсить этот бинарник не зная архитектуру железки?

Здесь все ограничивается лишь фантазией разработчиков протектора.
Я что-то не уверен, что кто-то решится на самостоятельную разработку подобного решения под свой проект.

[xmoonlight]

Inviz Custos,
Ладно. Вижу, что Вы не знаете глубже. Поясню "на пальцах".
Вот у Вас есть программа и внутри она работает так: 5+5=10
Теперь, Вы создаёте из неё новую машину: (6-1)+(4+1)=10 (код другой, а результат - тот же)
И ещё: 5*2 = 10 (код другой, а результат - тот же)
Теперь, представим, что на каждый оператор/операцию в программе есть масса замен случайным выбором. И каждая такая замена - имеет свой порядковый номер.
Каждый такой путь замен - это путь по "дереву" замен, по которому создаётся "магическое число", привязанное ко всем ВЕРНЫМ заменам.
И чтобы при запуске всё отработало как было задумано, "магическое число" должно задать правильную "карту" через формулу замен для организации корректной (изначальной!) логики.
Т.е. это "магическое число" восстанавливает логику работы приложения, если оно верное.
(разумеется, логика - та же, но сложность уникальных блоков кода для замен - гораздо больше)
Таким нехитрым способом создаётся полиморфный "движок" вирт.машины.

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

Речь про сложность тут идёт, а не про желание. Если надо - проблем не будет, чтобы разработать.

[Inviz Custos]

Ладно. Вижу, что Вы не знаете глубже. Поясню "на пальцах".

К моему сожалению, это Вы так и не поняли мое объяснение "на пальцах" :(
Если то, что Вы описали, в вашем идеальном мире является реализацией виртуальной машины для защиты приложения, то пусть так и будет.
К счастью, это никак не относится к реальному миру.
Оставлю Вас наедине с Вашим мнение, лишь напоследок подкину пищи к размышлению на примере энигмы:

В настройках упоминается одна интересная аббревиатура, которая дает нам подсказку о том, какую архитектуру будет иметь наш "виртуальный процессор" (она же "виртуальная машина").
Если что, x86_64 - это CISC.
Подумайте над этим ;)
Засим откланяюсь, всего доброго ;)

[xmoonlight]

Inviz Custos, Вот то, про что я говорил.
А слово RISC - это к процессору не имеет вообще отношения. Это лишь указывает на метод, по которому будет работать виртуальная машина (с упрощёнными инструкциями, как раз что я привёл в ссылке на документацию).

Можете продолжать фанатеть от Энигмы, но понимать логику - Вы не хотите! :))
А про RSA на 512 бит - советую почитать побольше)