Electron: La source est-elle vraiment protégée avec la création d'applications avec Electron ?

Non, il est très facile d'obtenir votre code source même lorsque vous l'avez empaqueté dans asar archive

Donc, si vous voulez vraiment protéger votre code source, vous devez les écrire en C++ et créer un module Node natif.

Il existe certaines options, mais le niveau de protection qu'elles offrent est limité par les raisons mentionnées par @zcbenz :

• Vous pouvez implémenter vous-même une logique de décryptage, dans un module complémentaire de nœud C++, mais elle sera probablement toujours cassable (par exemple, déboguer le programme et copier la source après le décryptage mais avant l'évaluation).
• Il existe également EncloseJS , qui prétend compiler votre code pour node.js/io.js, il pourrait donc fonctionner avec Electron.
• nw.js , qui est un projet similaire, prend en charge les instantanés v8 qui offrent une sorte de protection (voir les détails ici ).

Notez que toutes ces méthodes entraîneront une baisse des performances.

@etiktin Je suis aussi
Est-il possible d'appliquer directement le code node.js dans l'addon C++ ?

@fritx , Node a un module appelé vm qui peut évaluer le code. Je suppose que vous pourriez trouver un moyen de l'appeler ou de souligner l'API C++ de votre module complémentaire et de l'utiliser pour charger votre code.
Gardez à l'esprit que l'utilisateur peut toujours réussir à ouvrir les outils de développement et voir le script chargé. Même si vous parvenez à bloquer cela à l'aide d'une version personnalisée d'Electron et du module complémentaire vérifiant que votre version d'Electron n'a pas été falsifiée, l'utilisateur peut toujours voir votre code sous forme de chaîne en mémoire.

Ça sonne bien, protégez la source ! :clé:

Ensuite, j'ai une question, comment les applications électroniques à code fermé telles que GitKraken, Whatsapp ou Slack peuvent cacher le code ?

@ alexis57 J'ai la même question; c'est peut-être juste que l'élément inspect est désactivé ou quelque chose du genre

Ou peut-être que le code principal provient d'une bibliothèque C/C++ et qu'ils utilisent ensuite des électrons uniquement pour l'interface graphique, je ne sais pas...

J'aimerais savoir comment WhatsApp et Slack protègent également leur code source

AFAIK c'est tout simplement non protégé. Vous pouvez extraire leur app.asar et accéder au code source. Pour les parties sensibles de l'application, vous écrivez généralement des modules complémentaires personnalisés dans un langage compilé tel que C/C++, comme suggéré ci-dessus.

Comment peut-on y compiler du code C++ ?

Voir : https://nodejs.org/api/addons.html

@boeserwolf merci ! :)

Abonné

C'est aussi possible avec node-ffi . Electron ne doit être utilisé que pour l'interface utilisateur.

Cela peut valoir la peine d'explorer l'écriture du code en C/C++, puis d'utiliser un outil comme emscripten pour le convertir en assemblage Web. Cela devrait fonctionner très bien avec Chromium

Tout peut être démonté/désobscurci avec suffisamment d'effort. Écrire votre code en JavaScript et l'inclure dans l'ASAR empêcherait la majorité des gens d'entrer. Y a-t-il une raison de protéger le code que le droit d'auteur/la licence ne couvre pas ?

Mes 2 cents ici, NW semblent résoudre le problème des instantanés v8
https://nwjs.io/blog/js-src-protect-perf/

Je suis tombé sur cet article de nwjs, "le code binaire compilé s'exécute désormais aussi vite que le code source JS sans surcharge de performances" qui était auparavant de 30%, et il sera activé par défaut dans la version ultérieure de NW.

Vraiment intéressé par cela, j'ai également relu l'article que

C'est trop inconfortable pour les développeurs. Abandonnez et passez au NW...

Je voudrais partager un autre projet node.js qui utilise la protection du code de manière très élégante : https://github.com/zeit/pkg

Peut-être y a-t-il un espoir de protection des sources dans Electron ?

En plus d'utiliser C++ pour certaines parties, vous pouvez également réduire et _obscurcir_ votre source JavaScript (par exemple en utilisant javascript-obfuscator ).

La minimisation et l'obscurcissement augmenteront _considérablement_ l'effort requis (et donc _le coût_) pour "voler" votre code, souvent au point que la rétro-ingénierie de l'ensemble de votre application à partir de zéro devient facilement beaucoup plus réalisable - et il n'y a techniquement rien que vous puissiez faire faire à propos de l'ingénierie inverse, même si vous devenez complètement natif (rien, à part chercher la loi).

Si vous ne craignez pas de cacher votre code source MAIS vous voulez cacher vos secrets tels que :

• Identifiants OAuth
• URL non destinées à être connues du public (c.-à-d. points de terminaison d'API backend privés)
• Identifiants de l'API REST
• Toutes les clés et secrets
• Mots de passe

J'ai créé un service GRATUIT pour résoudre ce problème. Je devais le faire parce que je créais une application électronique commerciale et que je craignais de me faire voler mes informations d'identification.

Cela fonctionne en créant une application d'assistance multiplateforme qui lance votre application électronique réelle IFF, votre application n'a pas été altérée. Une fois l'application lancée, elle transmettra vos informations d'identification via les variables d'environnement.

Plus d'information:

Introduction:
https://medium.com/@rocketlaunchr.cloud/introducing -electron-vault-d09ade2c2020

Documentation:
https://rocketlaunchr.github.io/electron-vault-docs/

@JohnWeisz

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

Comment le serveur du serveur distant sait-il vraiment que le client est en fait votre application Electron non modifiée ?
C'est le problème que j'essayais de résoudre.

Si vous utilisez OAuth avec le type de subvention Client Credentials , votre client_secret est toujours intégré à votre application et n'importe qui peut en théorie le lire. Avec le code source d'Electron 100 % ouvert et disponible, il est facile de rechercher des chaînes qui semblent « intéressantes ».

Il n'y a pas de moyen infaillible à 100% pour résoudre le problème, mais je pense que ma solution est une nette amélioration.

Je pense que cela est possible en créant vos applications JS avec un framework webpack ou SPA comme angular2/4/6 ou vuejs2. cela minimise votre code et c'est fastidieux même si l'on extrait le fichier asar, il peut être difficile pour eux de lire votre code

Je pense que le problème ne devrait pas se concentrer uniquement sur le cryptage réel. Mais sur le fait qu'aucune autre application/utilisateur n'a falsifié le code source du client.

Le fait d'avoir un archivé asar signé ou un binaire similaire à partir duquel le code source est chargé permettrait à electron de vérifier l'intégrité du fichier. Puisque le contrôle d'intégrité pourrait être intégré dans le binaire électronique lui-même, il n'y aurait pas de surcharge dans le code javascript. Fondamentalement, lors de la construction, l'électron pourrait obtenir un indicateur --include-integrity-check, sinon la manière normale de le faire est compilée.

@tulpn

Étant donné que le contrôle d'intégrité pourrait être intégré dans le binaire électronique lui-même, il n'y aurait pas de ...

-- alors il ne s'agit déjà que d'extraire le contrôle d'intégrité ou le cryptage/décryptage qu'Electron effectue, et vous avez le code source. Je suis convaincu que l'obscurcissement est la seule approche que vous pouvez adopter ici (que ce soit la minification, la minification + l'obscurcissement ou la compilation de code natif).

Cela, ou déplacer une partie du code de votre application vers un service distant (avec authentification si vous avez besoin de sécurité).

Vous pouvez chiffrer vos données et les déchiffrer lors de l'exécution et les charger directement dans des variables telles que des jetons ou tout type de données sensibles, mais si vous parlez de chiffrer des fichiers javascript entiers, les performances en seront affectées. Vous pouvez essayer les modules complémentaires Node C++

Comme le dit nodejs :

Les modules complémentaires Node.js sont des objets partagés liés dynamiquement, écrits en C++, qui peuvent être chargés dans Node.js à l'aide de la fonction require() et utilisés comme s'il s'agissait d'un module Node.js ordinaire. Ils sont principalement utilisés pour fournir une interface entre JavaScript exécuté dans Node.js et les bibliothèques C/C++.

Fondamentalement, il compile votre code en binaire et de cette façon, vous pouvez faire abstraction de votre code et les performances seront beaucoup plus rapides et vous pouvez masquer votre code dans une certaine mesure.

Non, il est très facile d'obtenir votre code source même lorsque vous l'avez empaqueté dans asar archive

Donc, si vous voulez vraiment protéger votre code source, vous devez les écrire en C++ et créer un module Node natif.

comment puis-je désactiver les devtools des addons c ++ et comment puis-je accéder à toutes les API d'électron à partir des addons c ++ et y a-t-il un plan pour empaqueter une application sans le devtool, cela peut être utile pour empêcher les piratages et avec moins de taille de l'application ( @ zcbenz )

Nous en avons tous marre que notre code source soit publié. Je déménage à nw

@ahmtcn123 Comment votre commentaire aide-t-il à résoudre ce problème ?

Vous voulez créer des applications avec des technologies Web qui, par essence, ont leur code source public, alors arrêtez avec cette attitude.

• Vous pouvez contribuer à Electron pour résoudre ce problème
• Écrire des modules C++
• Minifier / obscurcir / mutiler votre code (et n'oubliez pas de désactiver les sources map)
• Vous pouvez passer à une autre technologie similaire (comme nw.js), ou vous pouvez devenir natif
• Quelques autres solutions ont été partagées ici, vous pouvez échanger l'obscurcissement contre des performances (ce qui n'est pas un choix si évident à faire quand on connaît déjà les performances/consommation de ressources d'Electron)

Tchin Tchin!

_modifier : continuez à voter contre les gars_ 🍿

Pourquoi ne pas prendre en charge v8snapshot ?

Je comprends que nous ne pouvons pas protéger complètement le code source. mais une autre façon peut être de créer un service Web à l'aide d'une technologie compilée native (comme golang) pour protéger le code logique et appeler à partir de l'interface utilisateur électronique via localhost.

le dernier mot

NO

pourquoi ce problème a-t-il été clos ?

Parce que cacher le code source a toujours été un sujet controversé car il est considéré que la sécurité par l'obscurité est une très mauvaise méthode pour protéger votre code.

Si vous souhaitez une certaine protection, utilisez des méthodes plus standard, telles que l'authentification pour effectuer des actions critiques, le cryptage, etc.

Sincèrement, vous pouvez écrire votre application en C et distribuer des binaires, nous aurons quand même votre code source.

PD : vous pouvez accéder au code source des grands (whatsapp web, slack, teams, vscode) et aucun d'entre eux ne s'en soucie, peut-être que vous faites quelque chose de mal.

"""PD : vous pouvez accéder au code source des grands (whatsapp web, slack, teams, vscode) et aucun d'entre eux ne s'en soucie, peut-être que vous faites quelque chose de mal."""

On peut difficilement faire un argument plus stupide.

Vendre un logiciel sans vouloir qu'il soit rétro-conçu et utilisé d'une manière qui n'est pas censée n'est pas anormal, en fait, il existe des lois exactement pour cela, ce qui n'empêche pas les utilisateurs de continuer à le faire.

@kidandcat

Sincèrement, vous pouvez écrire votre application en C et distribuer des binaires, nous aurons quand même votre code source.

Continuez, obtenez la source de toutes les applications les plus vendues comme Microsoft Word, Photoshop ou même les jeux les plus vendus. Vous êtes milliardaire et je ne suis pas au courant ou quoi ?

Non lol, je ne suis pas milliardaire car avoir le code source de ces programmes ne sert à rien, qu'allez-vous en faire ?

Les gars s'il vous plaît, il y a beaucoup de gens dans ce fil qui sont notifiés pour chaque commentaire, s'il vous plaît, restez constructif.

Pour résumer peut-être pourquoi, à mon avis, devoir gérer les particularités du code source de JavaScript n'est pas une rupture dans de nombreux cas :

• De nombreux exemples d'applications/services répertoriés ici sont largement motivés par leur _traction_ ; Prenez Twitter par exemple, ce n'est pas exactement un mystère comment cela fonctionne en interne, mais même en le copiant entièrement et en le reproduisant dans son intégralité ne vous mènera nulle part sans le trafic, la publicité, la marque, l'infrastructure de soutien, etc.
• Un obscurcissement approprié rend extrêmement, _prohibitif_ difficile l'accès au code source de manière significative, au point où il devient beaucoup plus faisable d'observer simplement le comportement de l'application elle-même et de la désosser en fonction de cela, sans compter sur l'original code source -- un peu comme dans le cas de C++ par exemple
• Le vol d'idées et/ou de solutions dans une application protégée par le droit d'auteur est une question juridique et non technique, et à ce titre, la protection de la mise en œuvre est une affaire juridique, quel que soit le niveau de protection mis en œuvre ; une entreprise chinoise louche volera votre logo et votre application sans problème, qu'ils aient été écrits en JavaScript ou en assembleur
• De plus, vous pouvez inclure du code C++ dans votre application si vous n'êtes pas convaincu de l'obscurcissement, ou vous pouvez déplacer le code vers un service distant qui, contrairement à tout le reste (y compris C++), est parfaitement protégé de l'inspection directe (pas de la rétro-ingénierie bien que)

@JohnWeisz a dit beaucoup de choses vraiment sensées. J'ajouterai également que si cela ne vous suffit pas, vous pouvez utiliser WebAssembly dès aujourd'hui. En termes de protection du code source, cela devrait être assez bon.

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

@kidandcat Est-ce vrai ? "Sincèrement, vous pouvez écrire votre application en C et distribuer des binaires, nous obtiendrons quand même votre code source."

J'ai cherché sur google, il semble qu'il soit impossible d'obtenir le code source des binaires compilés à partir de C/C++. Tout au plus, nous pouvons obtenir des instructions d'assemblage.

Je développe un logiciel de bureau Windows commercial. La logique du code est une compétence clé. Cette logique doit fonctionner côté client mais je ne veux pas que mes concurrents l'obtiennent. Donc, la protection du code est un facteur décisif dans mon cas.

@z1988hf

semble qu'il soit impossible d'extraire le code source des binaires compilés à partir de C/C++. Tout au plus, nous pouvons obtenir des instructions d'assemblage

Ce que cela signifie vraiment, c'est que vous pouvez à peu près procéder à une ingénierie inverse du code source d'origine, ou quelque chose d'équivalent, mais c'est généralement extrêmement difficile et donc coûteux. La même chose peut être dite à propos du code obscurci.

@kidandcat Est-ce vrai ? "Sincèrement, vous pouvez écrire votre application en C et distribuer des binaires, nous obtiendrons quand même votre code source."

J'ai cherché sur google, il semble qu'il soit impossible d'obtenir le code source des binaires compilés à partir de C/C++. Tout au plus, nous pouvons obtenir des instructions d'assemblage.

Je développe un logiciel de bureau Windows commercial. La logique du code est une compétence clé. Cette logique doit fonctionner côté client mais je ne veux pas que mes concurrents l'obtiennent. Donc, la protection du code est un facteur décisif dans mon cas.

L'assemblage est également code mate, votre logique sera là. Vous devrez faire plus de choses pour protéger votre code que simplement le compiler. (mais comme l' a dit

Pour ceux qui font référence à des applications comme Slack comme ne se souciant pas de la protection du code source, ce n'est pas la meilleure comparaison pour toutes les applications. Slack est un service en ligne et leur application électronique n'est qu'un shell pour afficher leur application Web. La majorité de la sauce secrète des applications comme Slack vit sur des serveurs Web.

Pour ceux qui font référence à des applications comme Slack comme ne se souciant pas de la protection du code source, ce n'est pas la meilleure comparaison pour toutes les applications. Slack est un service en ligne et leur application électronique n'est qu'un shell pour afficher leur application Web. La majorité de la sauce secrète des applications comme Slack vit sur des serveurs Web.

@votre favori
que diriez-vous de spotify !!!, nous savons ce que vous voulez dire, mais qu'en est-il des applications hors ligne ??

La sauce secrète de @annymosse Spotify n'est pas leur appli. Si quelqu'un volait la source de l'application Spotify, cela n'aurait pas vraiment d'importance. L'application est assez bonne. La vraie raison pour laquelle les gens utilisent et paient Spotify est l'offre de contenu et la commodité de la musique en streaming. Certains détails UX sont probablement préférés aux alternatives par de nombreux clients de Spotify, mais les concurrents n'ont pas vraiment besoin du code source pour le copier. De plus, je n'ai pas essayé de regarder le code source de Spotify, mais j'imagine qu'ils ont une sorte de protection intégrée quelque part dans l'application. Probablement un obscurcissement solide ainsi que des addons C natifs. Je pense que ce serait une exigence pour eux en raison de DRM.

@yourfavorite il suffit de jeter un œil à leur source, mettez dans votre esprit parfois nous ne cachons pas notre source pour les applications commerciales, nous le faisons pour empêcher nos services loin que les pirates informatiques qu'ils obtiennent des lignes faibles, de toute façon nous avons juste besoin de cette fonctionnalité si il y a une possibilité de le faire, au moins une méthode pour passer le asar files et le package.json et *.js

Je ne m'oppose pas à la protection du code source, mais plutôt au fait que Slack et Spotify ne sont probablement pas les meilleures comparaisons pour ce que la plupart des gens font avec l'électron. De plus, si la protection du code source est essentielle pour votre produit, l'électron n'est peut-être pas la meilleure solution pour le moment.

Et pour être clair, je suis en faveur de la protection du code source d'une sorte d'électron.

J'ai besoin d'une protection du code source. Permettez-moi de fournir un cas d'utilisation ici :

J'essaie de créer une base de logiciels de traduction sur l'API Google Translate

L'utilisateur fait glisser un fichier de sous-titres .srt/.ass dans le logiciel, et le logiciel utilisera l'API Google Translate pour traduire chaque ligne.

Exemple

L'utilisateur a téléchargé 1 vidéo et le 1 sous-titre anglais.
Maintenant, ils peuvent utiliser ce logiciel pour traduire ce sous-titre anglais
vers le chinois ou toute autre langue.
Ainsi, ils peuvent comprendre le contenu.

Problème

Si le code source est facile à obtenir.
apparemment, l'attaquant pourrait obtenir ma clé API et mon secret. et en abuser.
et je recevrais une facture massive de Google (500 $ ? 1 000 $ ? plus ?)

Mise à jour rapide (2020-mars-29)

J'utilise Vue.js + Webpack avec Electron.js
donc tout le code deviendrait minimisé, donc ce n'est plus un problème

@1c7

Eh bien, vous devriez peut-être utiliser une protection externe pour y parvenir. Je pourrais facilement récupérer votre clé API à partir d'un logiciel C++, pas de problème. Ce n'est donc pas vraiment un problème spécifique aux électrons.

@lvkins oh je vois. Je ne savais pas que les logiciels C++ avaient aussi ce problème. Je ne connais pas cette langue.
Merci pour les conseils!

Fondamentalement, chaque langage de programmation peut être rétro-conçu. Cela a toujours été une grande préoccupation. Vrai que n'importe quelle protection vaut mieux que pas de protection, mais quand même ; nous devons faire des efforts supplémentaires pour protéger les données sensibles, quel que soit le langage de programmation. Dans votre cas, vous devriez probablement opter pour une bibliothèque C++, y mettre du sel supplémentaire et la lier à votre node.js, cela devrait le faire.

@lvkins Vous me
Merci pour la suggestion. J'enquêterais là-dessus.

Je souhaite utiliser Electron.js car je souhaite que ce logiciel de traduction puisse fonctionner à la fois sur Mac et Windows.

On dirait qu'Electron.js + un peu de C++ pourraient protéger ma clé API et mon secret

Merci @lvkins

@1c7 En effet

Commencez ici : https://nodejs.org/api/addons.html

Si le manque total de sécurité d'électron vous préoccupe, vous pouvez également essayer NW.js.

Bonne chance!

@1c7 et pourquoi pas Linux ?!! je pense que c'est la même base de code pour toutes les plateformes, non ??!

@annymosse J'ai juste oublié de mentionner Linux, rien contre Linux.

POUR VOTRE INFORMATION:

• J'utilise un Macbook Pro 2017 15 pouces (Mac)
• La plupart de mes utilisateurs utilisent Windows (Windows)
• Je n'ai vu aucun de mes utilisateurs de logiciels l'utiliser sous Linux (Linux)

Je pensais tourner https://github.com/1c7/Translate-Subtitle-File
ce projet en un projet sérieux (facturer de l'argent et avoir une meilleure qualité (passer plus de temps dessus))
donc je fais mes recherches maintenant

Cet outil ciblerait principalement le marché chinois pour le moment. (tout le bouton et le texte seraient en chinois)
i18n est sur la carte mais ne le sera pas bientôt

J'avais l'intention de créer une API de traduction i18n et Yandex, mais à cause du même problème, j'ai annulé le projet, puis sur Linux, la plupart des nouveaux utilisateurs n'ont pas confiance dans les programmes qui, selon eux, n'existent pas sous Linux ou il n'y a pas d'alternative Donc, si vous créez ce projet et que vos utilisateurs cibles ne traduisent que les médias, ils peuvent utiliser n'importe quelle disto Linux ou ma distribution préférée en profondeur (distro Linux chinoise), j'espère le meilleur pour vous et tous les utilisateurs de Linux.

Vos clés API et votre secret ne doivent jamais se trouver dans une application publiée. A la place
les sur vos API/backend, et protégez-les avec un certain type de
authentification/étranglement. Ensuite, faites en sorte que votre application consomme vos API.

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

@annymosse https://github.com/annymosse j'ai juste oublié de mentionner Linux,
rien contre Linux

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/electron/electron/issues/2570?email_source=notifications&email_token=ADCOXMFCSHRX3PZTE7GHKDTQPRLQRA5CNFSM4BODX2F2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63BYLNMVXHJZ97TDN5WW2F2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63BYLNMVXHJZ97TDNPWS5
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/ADCOXMCKPUOMQPM3JKZP5J3QPRLQRANCNFSM4BODX2FQ
.

Il existe une bibliothèque appelée bytenode qui vous permet de convertir vos fichiers Javascript en fichiers binaires afin que personne ne puisse les lire.

Installez d'abord bytenode sur votre serveur et dans votre dossier :

>npm i -g bytenode
>npm i bytenode

Créez un fichier nodeJS normal contenant le code suivant. Imaginons que nous nommons le code suivant : ok.js

>console.log('bytenode works!);
Ensuite, compilez votre code javascript. La commande créera un fichier .JSC avec le même nom que votre fichier.

user<strong i="15">@machine</strong>:~$ bytenode -c ok.js
Ensuite, dans un fichier JS d'électron principal, vous appellerez votre binaire, appelons-le test.js :

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

Sauvegarde le.

Ensuite, vous appellerez test.js : node test.js pour le tester. Faites un "cat ok.jsc" pour voir qu'il s'agit bien d'un binaire et que personne ne peut voir votre code. Vous pouvez déplacer votre fichier js de test brut d'origine vers un autre emplacement.
Je ne l'ai pas testé à partir d'électrons mais je suppose que cela fonctionnerait, n'est-ce pas?