Electron: Действительно ли источник защищен созданием приложений с помощью Electron?

Нет, очень легко получить исходный код, даже если вы упаковали его в архив asar , механизм JavaScript V8 никогда не предназначен для сокрытия исходного кода. NW.js действительно удается полностью скрыть один файл исходного кода, но ценой значительного снижения производительности.

Поэтому, если вы действительно хотите защитить свой исходный код, вам нужно написать его на C ++ и создать собственный модуль Node.

Есть несколько вариантов, но уровень защиты, который они обеспечивают, ограничен причинами, упомянутыми @zcbenz :

• Вы можете реализовать некоторую логику дешифрования самостоятельно в надстройке узла C ++, но она, вероятно, все равно будет взламываемой (например, отлаживать программу и копировать исходный код после дешифрования, но до eval).
• Также существует EncloseJS , который утверждает, что скомпилировал ваш код для node.js / io.js, поэтому он может работать с Electron.
• nw.js , который представляет собой аналогичный проект, поддерживает снимки состояния v8, которые обеспечивают некоторую защиту (подробности см. здесь ).

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

@etiktin Я тоже с этим сталкиваюсь.
Можно ли просто применить код node.js в аддоне C ++ напрямую?

@fritx , в Node есть модуль vm, который может оценивать код. Я думаю, вы могли бы найти способ вызвать его или подчеркнуть C ++ API из вашего аддона и использовать его для загрузки вашего кода.
Имейте в виду, что пользователю по-прежнему удастся открыть инструменты разработчика и увидеть загруженный скрипт. Даже если вам удастся заблокировать это с помощью настраиваемой сборки Electron и проверки надстройки, чтобы убедиться, что ваша сборка Electron не была изменена, пользователь все равно может увидеть ваш код в виде строки в памяти.

Звучит хорошо, защитите источник! :ключ:

Тогда у меня вопрос, как приложения с закрытым кодом, такие как GitKraken, Whatsapp или Slack, могут скрыть код?

@ alexis57 У меня такой же вопрос; может быть, просто отключен элемент проверки или что-то в этом роде

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

Хотелось бы узнать, как WhatsApp и Slack также защищают свой исходный код

AFAIK это просто незащищено. Вы можете извлечь их app.asar и получить доступ к исходному коду. Для чувствительных частей приложения вы обычно пишете собственные надстройки на компилируемом языке, таком как C / C ++, как было предложено выше.

Как мы можем скомпилировать в нем код c ++?

См. Https://nodejs.org/api/addons.html

@boeserwolf, спасибо! :)

Подписан

Также возможно с node-ffi . Electron следует использовать только для пользовательского интерфейса.

Возможно, стоит изучить написание кода на C / C ++, а затем использовать такой инструмент, как emscripten, для преобразования его в веб-сборку. Это должно отлично работать с Chromium

Все что угодно можно разобрать / распутать, приложив достаточно усилий. Написание кода на JavaScript и включение его в ASAR отпугнет большинство людей. Есть ли причина для защиты кода, на который не распространяется авторское право / лицензирование?

Мои 2 цента здесь, NW, похоже, решают проблему снимков v8
https://nwjs.io/blog/js-src-protect-perf/

Я наткнулся на эту статью от nwjs: «Скомпилированный двоичный код теперь работает так же быстро, как исходный код JS, без накладных расходов на производительность», который ранее составлял 30%, и он будет включен по умолчанию в более позднем выпуске NW.

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

Разработчикам это слишком неудобно. Сдаваться и переходить на NW ...

Я хотел бы поделиться другим проектом node.js, который очень элегантно использует защиту кода: https://github.com/zeit/pkg

Может есть надежда на защиту источников в Электроне?

Помимо использования C ++ для некоторых частей, вы также можете минимизировать и _obfuscate_ ваш исходный код JavaScript (например, используя javascript-obfuscator ).

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

Если вы не беспокоитесь о сокрытии исходного кода, НО вы хотите скрыть свои секреты, такие как:

• Учетные данные OAuth
• URL-адреса, не предназначенные для публичного использования (например, конечные точки частных серверных API)
• Учетные данные REST API
• Любые ключи и секреты
• Пароли

Я создал БЕСПЛАТНУЮ службу для решения этой проблемы. Мне пришлось это сделать, потому что я делал коммерческое электронное приложение и беспокоился о том, что мои учетные данные украдут.

Он работает, создавая кроссплатформенное вспомогательное приложение, которое запускает ваше реальное электронное приложение. IFF ваше приложение не было изменено. После запуска приложения ваши учетные данные будут переданы через переменные среды.

Больше информации:

Вступление:
https://medium.com/@rocketlaunchr.cloud/introduction -electron-vault-d09ade2c2020

Документация:
https://rocketlaunchr.github.io/electron-vault-docs/

@JohnWeisz

If the data is indeed sensitive, I think it should be handled by a remote server.

Как удаленный сервер-сервер действительно знает, что клиент на самом деле является вашим неизменным приложением Electron?
Это проблема, которую я пытался решить.

Если вы используете OAuth с типом гранта Client Credentials , тогда ваш client_secret по-прежнему встроен в ваше приложение, и теоретически любой может его прочитать. Исходный код Electron на 100% открыт и доступен, поэтому легко искать строки, которые кажутся "интересными".

Не существует 100% надежного способа решить проблему, но я считаю, что мое решение - определенное улучшение.

Я считаю, что это возможно, создавая свои JS-приложения с помощью webpack или SPA, например angular2 / 4/6 или vuejs2. это минимизирует ваш код и его кропотливость, даже если вы извлекаете файл asar, им может быть трудно прочитать ваш код

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

Наличие в архиве подписанного asar или аналогичного двоичного файла, из которого загружается исходный код, позволило бы электрону проверить целостность файла. Поскольку проверка целостности может быть интегрирована в сам электронный двоичный файл, в коде javascript не будет перегрузки. В основном при сборке электрон может получить флаг --include-целостность-проверка, в противном случае это компилируется обычным способом.

@tulpn

Поскольку проверка целостности может быть интегрирована в саму электронную двоичную систему, не будет ...

- тогда это уже только вопрос извлечения того, что проверяет целостность или шифрование / дешифрование, которое делает Electron, и у вас есть исходный код. Я убежден, что обфускация - единственный подход, который вы можете здесь использовать (будь то минификация, минификация + обфускация или компиляция собственного кода).

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

Вы можете зашифровать свои данные и расшифровать их во время выполнения и загрузить их непосредственно в переменные, такие как токены или любые конфиденциальные данные, но если вы говорите о шифровании целых файлов javascript, это отрицательно скажется на производительности. Вы можете попробовать надстройки Node C ++

Как говорит nodejs:

Аддоны Node.js - это динамически связанные общие объекты, написанные на C ++, которые можно загрузить в Node.js с помощью функции require () и использовать так же, как если бы они были обычным модулем Node.js. Они используются в основном для обеспечения интерфейса между JavaScript, работающим в Node.js, и библиотеками C / C ++.

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

Нет, очень легко получить исходный код, даже если вы упаковали его в архив asar , механизм JavaScript V8 никогда не предназначен для сокрытия исходного кода. NW.js действительно удается полностью скрыть один файл исходного кода, но ценой значительного снижения производительности.

Поэтому, если вы действительно хотите защитить свой исходный код, вам нужно написать его на C ++ и создать собственный модуль Node.

как я могу отключить инструменты разработки из надстроек С ++ и как я могу получить доступ ко всему API-интерфейсу электронов из надстроек С ++, и есть ли какой-либо план по упаковке приложения без инструмента разработки, это может помочь предотвратить взломы и с меньшим размером приложения ( @ zcbenz )

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

@ ahmtcn123 Как ваш комментарий помогает в решении этой проблемы?

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

• Вы можете внести свой вклад в Electron, чтобы решить эту проблему.
• Написать модули C ++
• Сократите / запутайте / измените свой код (и не забудьте отключить исходные карты)
• Вы можете перейти на другую похожую технологию (например, nw.js), или вы можете перейти на нативную
• Здесь были представлены несколько других решений, вы можете обменять обфускацию на производительность (что не столь очевидный выбор, когда мы уже знаем производительность / потребление ресурсов Electron)

ваше здоровье!

_edit: продолжайте отрицать, ребята_ 🍿

Почему бы не поддерживать v8snapshot?

Я понимаю, что мы не можем полностью защитить исходный код. но другим способом может быть создание веб-службы с использованием собственной скомпилированной технологии (например, golang) для защиты логического кода и вызова из электронного пользовательского интерфейса через localhost.

последнее слово

NW

почему этот вопрос был закрыт?

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

Если вам нужна некоторая защита, используйте более стандартные методы, такие как аутентификация для выполнения критических действий, шифрование и т. Д.

С уважением, вы можете писать свое приложение на C и распространять двоичные файлы, мы все равно получим ваш исходный код.

PD: вы можете получить доступ к исходному коду больших мальчиков (whatsapp web, slack, team, vscode), и никого из них это не волнует, возможно, вы что-то делаете не так.

"" "PD: вы можете получить доступ к исходному коду больших мальчиков (whatsapp web, slack, team, vscode), и никого из них это не волнует, возможно, вы делаете что-то не так." ""

Вряд ли можно привести более глупый аргумент.

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

@kidandcat

С уважением, вы можете писать свое приложение на C и распространять двоичные файлы, мы все равно получим ваш исходный код.

Продолжайте, получите исходный код всех самых продаваемых приложений, таких как Microsoft word, Photoshop, или даже самых продаваемых игр. Вы миллиардер, а я не в курсе что ли?

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

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

Чтобы, возможно, подытожить, почему, на мой взгляд, необходимость иметь дело с особенностями исходного кода JavaScript во многих случаях не мешает:

• Множество примеров приложений / сервисов, перечисленных здесь, в значительной степени обусловлены их притяжением; Возьмем, к примеру, Twitter, не совсем секрет, как он работает внутри компании, но даже если полностью скопировать и воспроизвести его целиком, вы никуда не денетесь без трафика, рекламы, бренда, вспомогательной инфраструктуры и т. д. и т.п.
• Правильная обфускация делает чрезвычайно, _предельно_ трудным доступ к исходному коду любым значимым образом, до такой степени, что становится гораздо более возможным просто наблюдать за поведением самого приложения и реконструировать его на основе этого, не полагаясь на оригинал. исходный код - как в случае, например, C ++
• Кража идей и / или решений из приложения, защищенного законом об авторском праве, является юридическим вопросом, а не техническим, и поэтому защита реализации является юридическим делом, независимо от уровня реализованной защиты; подозрительная китайская фирма без проблем украдет ваш логотип и приложение, независимо от того, написано ли оно на JavaScript или на ассемблере.
• Кроме того, вы можете включить код C ++ в свое приложение, если вы не уверены в обфускации, или вы можете переместить код в удаленную службу, которая, в отличие от всего остального (включая C ++), полностью защищена от прямой проверки (а не от обратного проектирования). хотя)

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

https://developer.mozilla.org/en-US/docs/WebAssembly

@kidandcat Это правда? «С уважением, вы можете писать свое приложение на C и распространять двоичные файлы, мы все равно получим ваш исходный код».

Я искал в google, кажется, невозможно получить исходный код из двоичных файлов, скомпилированных с C / C ++. В лучшем случае мы можем получить операторы сборки.

Я разрабатываю коммерческое программное обеспечение для настольных компьютеров Windows. Кодовая логика - ключевая компетенция. Эта логика должна работать на стороне клиента, но я не хочу, чтобы мои конкуренты ее поняли. Так что защита кода в моем случае нарушает правила.

@ z1988hf

кажется, невозможно получить исходный код из двоичных файлов, скомпилированных из C / C ++. Максимум, мы можем получить операторы сборки

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

@kidandcat Это правда? «С уважением, вы можете писать свое приложение на C и распространять двоичные файлы, мы все равно получим ваш исходный код».

Я искал в google, кажется, невозможно получить исходный код из двоичных файлов, скомпилированных с C / C ++. В лучшем случае мы можем получить операторы сборки.

Я разрабатываю коммерческое программное обеспечение для настольных компьютеров Windows. Кодовая логика - ключевая компетенция. Эта логика должна работать на стороне клиента, но я не хочу, чтобы мои конкуренты ее поняли. Так что защита кода в моем случае нарушает правила.

Также сборка - это код, ваша логика будет там. Вам нужно будет сделать больше для защиты вашего кода, чем просто его компиляция. (но, как сказал @JohnWeisz , программное обеспечение для обратного проектирования очень дорогое, поэтому вам не нужно беспокоиться, если ваши конкуренты не заинтересованы в том, чтобы тратить несколько тысяч долларов только на то, чтобы попробовать его)

Для тех, кто ссылается на такие приложения, как Slack, не заботясь о защите исходного кода, это не лучшее сравнение для всех приложений. Slack - это онлайн-сервис, а их электронное приложение - всего лишь оболочка для отображения их веб-приложения. Большая часть секретного соуса таких приложений, как Slack, живет на веб-серверах.

Для тех, кто ссылается на такие приложения, как Slack, не заботясь о защите исходного кода, это не лучшее сравнение для всех приложений. Slack - это онлайн-сервис, а их электронное приложение - всего лишь оболочка для отображения их веб-приложения. Большая часть секретного соуса таких приложений, как Slack, живет на веб-серверах.

@Ваш любимый
как насчет Spotify !!!, мы знаем, что вы имеете в виду, но как насчет автономных приложений ??

Секретный соус @annymosse Spotify - не их приложение. Если кто-то украл исходный код приложения Spotify, это не имело бы значения. Приложение достаточно хорошее. Настоящая причина, по которой люди используют и платят за Spotify, - это предложение контента и удобство потоковой передачи музыки. Есть некоторые детали UX, которые, вероятно, предпочитают альтернативы многим клиентам Spotify, но конкурентам действительно не нужен исходный код для их копирования. Кроме того, я не пытался просматривать исходный код Spotify, но я предполагаю, что у них есть какая-то защита, встроенная где-то в приложение. Вероятно, какая-то надежная обфускация, а также собственные надстройки C. Я думаю, что это было бы требованием для них из-за DRM.

@yourfavorite просто взгляните на их источник, помните, что иногда мы не скрываем наш источник для коммерческих приложений, мы делаем это, чтобы наши сервисы были далеко от хакеров, у которых есть слабые стороны, в любом случае нам просто нужна эта функция, если есть возможность сделать это, по крайней мере, какой-то метод для передачи asar files и package.json и *.js

Я не возражаю против защиты исходного кода, скорее, Slack и Spotify, вероятно, не лучшие сравнения того, что большинство людей делают с электроном. Вдобавок, если защита исходного кода критически важна для вашего продукта, то, возможно, электрон не подходит в настоящее время.

И чтобы внести ясность, я за то, чтобы в электронике была какая-то защита исходного кода.

Мне нужна защита исходного кода. Позвольте мне представить здесь пример использования:

Я пытаюсь создать базу программного обеспечения для перевода на Google Translate API

Пользователь перетаскивает файл субтитров .srt / .ass в программу, и программа будет использовать Google Translate API для перевода каждой отдельной строки.

Пример

Пользователь загрузил 1 видео и 1 субтитр на английском языке.
Теперь они могут использовать это программное обеспечение для перевода английских субтитров.
на китайский или любой другой язык.
Чтобы они могли понять содержание.

Проблема

Если исходный код достать несложно.
очевидно, злоумышленник мог получить мой ключ и секрет API. и злоупотребляют этим.
и я получу крупный счет от Google (500 долларов? 1000 долларов? больше?)

Быстрое обновление (29 марта 2020 г.)

Я использую Vue.js + Webpack с Electron.js
так что весь код будет минимизирован, так что это больше не проблема

@ 1c7

Что ж, возможно, для этого вам следует использовать некоторую внешнюю защиту. Я мог бы легко получить ваш ключ API из программного обеспечения на C ++, без проблем. Так что на самом деле это не проблема, связанная с электронами.

@lvkins, понятно. Я не знал, что у программного обеспечения C ++ тоже есть эта проблема. Я не знаком с этим языком.
Спасибо за советы!

Практически любой язык программирования можно реконструировать. Это всегда было большой проблемой. Верно, что любая защита лучше, чем ее отсутствие, но все же; нам нужно приложить дополнительные усилия для защиты конфиденциальных данных, независимо от того, на каком языке программирования. В вашем случае вам, вероятно, следует обратиться к библиотеке C ++, добавить в нее немного соли и связать ее с вашим node.js, это должно сработать.

@lvkins Ты мне
Спасибо за предложение. Я бы расследовал это.

Я хочу использовать Electron.js, потому что хочу, чтобы это программное обеспечение для перевода могло работать как на Mac, так и на Windows.

Похоже, что Electron.js + немного C ++ может защитить мой ключ и секрет API

Спасибо @lvkins

@ 1c7 Действительно 😃

Начните здесь: https://nodejs.org/api/addons.html

Если вас беспокоит полное отсутствие безопасности у Electron, вы также можете попробовать NW.js.

Удачи!

@ 1c7 а почему не линукс? !! Я думаю, что это одна и та же кодовая база для всех платформ, верно ??!

@annymosse Я просто забыл упомянуть Linux, ничего против Linux.

К вашему сведению:

• Я использую Macbook Pro 2017 15 дюймов (Mac)
• Большинство моих пользователей используют Windows (Windows)
• Я не видел, чтобы кто-либо из пользователей моего программного обеспечения использовал его в Linux (Linux)

Подумал включить https://github.com/1c7/Translate-Subtitle-File
этот проект в серьезный проект (берите деньги и имейте более высокое качество (потратьте на это больше времени))
так что я сейчас провожу свое исследование

На данный момент этот инструмент будет в основном нацелен на рынок Китая. (все кнопки и текст будут на китайском)
i18n есть на карте, но скоро появится

У меня был план создать API переводчика i18n и Яндекс, но из-за той же проблемы я отменил проект, тогда в Linux большинство новых пользователей не доверяют программам, которые, по их мнению, не существуют в Linux или нет альтернативы поэтому, если вы создаете этот проект, и ваши пользователи нацелены только на перевод носителей, они могут использовать любой дистрибутив Linux или мой любимый дистрибутив Deepin (китайский дистрибутив Linux), надеемся на лучшее для вас и всех пользователей Linux.

Ваши ключи и секрет API никогда не должны находиться в опубликованном приложении. Вместо этого имейте
их в ваших API / бэкэнде, и защищайте их каким-либо типом
аутентификация / дросселирование. Затем пусть ваше приложение использует ваши API.

Em dom, 20 de out de 2019 10:22, Cheng Zheng [email protected]
escreveu:

@annymosse https://github.com/annymosse Я просто забыл упомянуть Linux,
ничего против Linux

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/electron/electron/issues/2570?email_source=notifications&email_token=ADCOXMFCSHRX3PZTE7GHKDTQPRLQRA5CNFSM4BODX2F2YY3PNVWWK3TUL52-5DFVREXG43V2HS4DFVREXG43VWWK3TUL52-5DFVREXG43VLS4DFVREXG43VB
или отказаться от подписки
https://github.com/notifications/unsubscribe-auth/ADCOXMCKPUOMQPM3JKZP5J3QPRLQRANCNFSM4BODX2FQ
.

Существует библиотека под названием bytenode, которая позволяет конвертировать ваши файлы Javascript в двоичные файлы, чтобы никто не мог их прочитать.

Сначала установите байтенод на свой сервер и в свою папку:

>npm i -g bytenode
>npm i bytenode

Создайте обычный файл nodeJS со следующим кодом. Представим, что мы назовем следующий код: ok.js

>console.log('bytenode works!);
Затем скомпилируйте свой код javascript. Команда создаст файл. JSC с тем же именем, что и ваш файл.

user<strong i="15">@machine</strong>:~$ bytenode -c ok.js
Затем в основном электронном JS-файле вы назовете свой двоичный файл, назовем его test.js:

const bytenode = require('bytenode'); 
const myFile=require('./ok.jsc'); 
myFile;

Сохрани это.

Затем вы вызовете test.js: node test.js, чтобы проверить его. Выполните «cat ok.jsc», чтобы убедиться, что это действительно двоичный файл и никто не может увидеть ваш код. Вы можете переместить исходный простой тестовый js-файл в другое место.
Я не тестировал его с помощью электрона, но думаю, он сработает, не так ли?