Electron: ¿La fuente está realmente protegida con la creación de aplicaciones con Electron?

No, es muy fácil obtener su código fuente incluso cuando lo empaquetó en el archivo asar , el motor JavaScript V8 nunca está diseñado para ocultar el código fuente. NW.js logra ocultar un archivo del código fuente por completo, pero con el precio de una reducción significativa del rendimiento.

Entonces, si realmente desea proteger su código fuente, debe escribirlo en C ++ y crear un módulo Node nativo.

Hay algunas opciones, pero el nivel de protección que brindan está limitado por las razones que mencionó @zcbenz :

• Podría implementar alguna lógica de descifrado por su cuenta, en un complemento de nodo de C ++, pero probablemente aún será rompible (por ejemplo, depure el programa y copie la fuente después del descifrado pero antes de la evaluación).
• También está EncloseJS , que pretende compilar su código para node.js / io.js, por lo que podría funcionar con Electron.
• nw.js , que es un proyecto similar, tiene soporte para instantáneas v8 que brindan algún tipo de protección (ver detalles aquí ).

Tenga en cuenta que todos estos métodos incurrirán en una penalización de rendimiento.

@etiktin Me estoy encontrando con esto también.
¿Es posible simplemente aplicar el código node.js en el complemento C ++ directamente?

@fritx , Node tiene un módulo llamado vm que puede evaluar el código. Supongo que podría encontrar una manera de llamarlo o está subrayando la API de C ++ de su complemento y usarlo para cargar su código.
Tenga en cuenta que el usuario aún podría lograr abrir las herramientas de desarrollador y ver el script cargado. Incluso si logra bloquear eso usando una compilación de Electron personalizada y el complemento que verifica que su compilación de Electron no haya sido alterada, el usuario aún podría ver su código como una cadena en la memoria.

¡Suena bien proteger la fuente! :llave:

Entonces tengo una pregunta, ¿cómo las aplicaciones electrónicas de código cerrado como GitKraken, Whatsapp o Slack pueden ocultar el código?

@ alexis57 tengo la misma pregunta; tal vez sea solo que el elemento de inspección está deshabilitado o algo así

O tal vez el código principal proviene de una biblioteca C / C ++ y luego usan electron solo para la GUI, no sé ...

Me gustaría saber cómo WhatsApp y Slack también protegen su código fuente.

AFAIK, simplemente está desprotegido. Puede extraer su app.asar y acceder al código fuente. Para las partes sensibles de la aplicación, generalmente escribe complementos personalizados en un lenguaje compilado como C / C ++, como se sugirió anteriormente.

¿Cómo podemos compilar código C ++ en él?

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

@boeserwolf ¡gracias! :)

Suscrito

También es posible con node-ffi . Electron debe usarse solo para la interfaz de usuario.

Podría valer la pena explorar la escritura del código en C / C ++ y luego usar una herramienta como emscripten para convertirlo en ensamblador web. Esto debería funcionar muy bien con Chromium

Cualquier cosa se puede desmontar / despejar con suficiente esfuerzo. Escribir su código en JavaScript y tenerlo incluido en el ASAR mantendría fuera a la mayoría de las personas. ¿Existe alguna razón para proteger el código que los derechos de autor / licencias no cubren?

Mis 2 centavos aquí, NW parecen resolver el problema de las instantáneas v8
https://nwjs.io/blog/js-src-protect-perf/

Me encontré con este artículo de nwjs, "el código binario compilado ahora se ejecuta tan rápido como el código fuente JS sin sobrecarga de rendimiento", que anteriormente era del 30%, y se activará de forma predeterminada en la versión posterior de NW.

Realmente interesado en esto, también rojo el artículo que nos dijo @craftpip y parece ser bastante interesante. Si electron tuviera protección de código (incluso si era más lento al final del usuario), esto hará que muchos desarrolladores se sientan seguros y confiados al escribir sus aplicaciones. Dale una oportunidad al equipo de electrones;)

Es demasiado incómodo para los desarrolladores. Ríndete y cambia a NW ...

Me gustaría compartir otro proyecto node.js que usa protección de código de una manera muy elegante: https://github.com/zeit/pkg

¿Quizás hay esperanza para la protección de la fuente en Electron?

Además de usar C ++ para algunas partes, también puede minimizar y _ofuscar_ su fuente de JavaScript (por ejemplo, usando javascript-ofuscator ).

La minificación y la ofuscación juntas aumentarán _drásticamente_ el esfuerzo requerido (y por lo tanto el _cost_) para "robar" su código, a menudo hasta el punto de que la ingeniería inversa de toda su aplicación desde cero se vuelve fácilmente mucho más factible, y técnicamente no hay nada que pueda hacer con la ingeniería inversa, incluso si se hace completamente nativo (nada, además de buscar la ley).

Si no está preocupado por ocultar su código fuente PERO desea ocultar sus secretos como:

• Credenciales de OAuth
• URL que no están destinadas a ser conocidas por el público (es decir, puntos finales de API de backend privados)
• Credenciales de la API REST
• Cualquier clave y secreto
• Contraseñas

Creé un servicio GRATUITO para abordar este problema. Tuve que hacerlo porque estaba creando una aplicación electrónica comercial y me preocupaba que me robaran mis credenciales.

Funciona mediante la creación de una aplicación auxiliar multiplataforma que inicia su aplicación electrónica real IFF que su aplicación no ha sido manipulada. Una vez que inicie la aplicación, pasará sus credenciales a través de las variables de entorno.

Más información:

Introducción:
https://medium.com/@rocketlaunchr.cloud/introducing -electron-vault-d09ade2c2020

Documentación:
https://rocketlaunchr.github.io/electron-vault-docs/

@JohnWeisz

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

¿Cómo sabe realmente el servidor del servidor remoto que el cliente es en realidad su aplicación Electron inalterada?
Ese es el problema que estaba tratando de resolver.

Si usa OAuth con el tipo de concesión Client Credentials , entonces su client_secret todavía está integrado en su aplicación y, en teoría, cualquiera puede leerlo. Con el código fuente de Electron 100% abierto y disponible, es fácil buscar cadenas que parezcan "interesantes".

No existe una forma 100% infalible de resolver el problema, pero creo que mi solución es una mejora definitiva.

Creo que esto es posible construyendo sus aplicaciones JS con un paquete web o un marco SPA como angular2 / 4/6 o vuejs2. esto minimiza su código y es meticuloso, aunque uno extrae el archivo asar, puede ser difícil para ellos leer su código

Creo que el problema no debería centrarse solo en el cifrado real. Pero sobre el hecho de que ninguna otra aplicación / usuario ha manipulado el código fuente del cliente.

Al tener un archivo asar firmado o un binario similar desde el que se carga el código fuente, electron comprobaría la integridad del archivo. Dado que la verificación de integridad podría integrarse en el propio binario de electrones, no habría una sobrecarga en el código javascript. Básicamente, en la construcción, el electrón podría obtener una bandera: incluir verificación de integridad, de lo contrario, se compila la forma normal de hacerlo.

@tulpn

Dado que la verificación de integridad podría integrarse en el propio binario de electrones, no habría un ...

- entonces ya es solo una cuestión de extraer cualquier verificación de integridad o cifrado / descifrado que haga Electron, y ya tiene el código fuente. Estoy convencido de que la ofuscación es el único enfoque que puede adoptar aquí (ya sea minificación, minificación + ofuscación o compilación de código nativo).

Eso, o mover parte del código de su aplicación a un servicio remoto (con autenticación si necesita seguridad).

Puede cifrar sus datos y descifrarlos en tiempo de ejecución y cargarlos directamente en variables como tokens o cualquier tipo de datos confidenciales, pero si está hablando de cifrar archivos javascript completos, afectará el rendimiento. Puedes darle una oportunidad a los complementos de Node C ++

Como lo dice nodejs:

Los complementos de Node.js son objetos compartidos vinculados dinámicamente, escritos en C ++, que pueden cargarse en Node.js usando la función require () y usarse como si fueran un módulo de Node.js ordinario. Se utilizan principalmente para proporcionar una interfaz entre JavaScript que se ejecuta en bibliotecas Node.js y C / C ++.

Básicamente, compila su código en binario y de esa manera puede abstraer su código y el rendimiento será mucho más rápido y podrá ocultar su código hasta cierto punto.

No, es muy fácil obtener su código fuente incluso cuando lo empaquetó en el archivo asar , el motor JavaScript V8 nunca está diseñado para ocultar el código fuente. NW.js logra ocultar un archivo del código fuente por completo, pero con el precio de una reducción significativa del rendimiento.

Entonces, si realmente desea proteger su código fuente, debe escribirlo en C ++ y crear un módulo Node nativo.

¿Cómo puedo deshabilitar devtools de los complementos de C ++ y cómo puedo acceder a toda la API de electron desde los complementos de C ++? ¿Hay algún plan para empaquetar una aplicación sin devtool? Esto puede ser útil para prevenir los hacks y con menos tamaño de la aplicación ( @ zcbenz )

Todos estamos cansados ​​de que se publique nuestro código fuente. Me mudo a nw

@ ahmtcn123 ¿Cómo está ayudando su comentario a resolver este problema?

Desea crear aplicaciones con técnicos web que, por esencia, tengan su código fuente público, así que deténgase con esa actitud.

• Puede contribuir a Electron para abordar este problema
• Escribir módulos C ++
• Minimice / ofusque / altere su código (y no olvide deshabilitar los mapas de origen)
• Puede cambiar a otra tecnología similar (como nw.js), o puede ser nativo
• Aquí se han compartido algunas otras soluciones, puede cambiar la ofuscación por el rendimiento (que no es una elección tan evidente cuando ya conocemos el rendimiento / consumo de recursos de Electron)

¡salud!

_editar: sigan votando en contra de los chicos_ 🍿

¿Por qué no es compatible con v8snapshot?

Entiendo que no podemos proteger completamente el código fuente. pero otra forma puede ser crear un servicio web utilizando tecnología compilada nativa (como golang) para proteger el código lógico y llamar desde la interfaz de usuario electrónica a través de localhost.

la última palabra

noroeste

¿Por qué se cerró este problema?

Porque ocultar el código fuente siempre ha sido un tema controvertido porque se considera que la seguridad a través de la oscuridad es un método muy malo para proteger su código.

Si desea algo de protección, utilice métodos más estándar, como autenticación para realizar acciones críticas, cifrado, etc.

Atentamente, puede escribir su aplicación en C y distribuir binarios, obtendremos su código fuente de todos modos.

PD: puedes acceder al código fuente de los grandes (whatsapp web, slack, teams, vscode) y a ninguno de ellos le importa, quizás estés haciendo algo mal.

"" "PD: puedes acceder al código fuente de los grandes (whatsapp web, slack, equipos, vscode) y a ninguno de ellos le importa, tal vez estés haciendo algo mal." ""

Difícilmente se puede hacer un argumento más tonto.

Vender software sin querer que se someta a ingeniería inversa y se utilice de formas que no se supone que no sea anormal, de hecho, existen leyes exactamente para eso, lo que no impide que los usuarios sigan haciéndolo.

@kidandcat

Atentamente, puede escribir su aplicación en C y distribuir binarios, obtendremos su código fuente de todos modos.

Continúe, obtenga la fuente de todas las aplicaciones más vendidas como Microsoft Word, Photoshop o incluso los juegos más vendidos. ¿Eres multimillonario y no lo sé o qué?

No jejeje, no soy multimillonario porque tener el código fuente de esos programas es inútil, ¿qué vas a hacer con él?

Chicos, por favor, hay muchas personas en este hilo que son notificadas por cada comentario, por favor manténgalo constructivo.

Para posiblemente resumir por qué, en mi opinión, tener que lidiar con las peculiaridades del código fuente de JavaScript no es un factor decisivo en muchos casos:

• Muchos de los ejemplos de aplicaciones / servicios que se enumeran aquí están impulsados ​​principalmente por su _tracción_; Tomemos Twitter, por ejemplo, no es exactamente un misterio cómo funciona internamente, pero incluso si lo copia y lo reproduce en su totalidad no lo llevará a ninguna parte sin el tráfico, la publicidad, la marca, la infraestructura de respaldo, etc.
• La ofuscación adecuada hace que sea extremadamente, _prohibitivamente_ difícil acceder al código fuente de una manera significativa, hasta el punto en que se vuelve mucho más factible simplemente observar el comportamiento de la aplicación en sí y aplicar ingeniería inversa basándose en eso, sin depender del original. código fuente, como en el caso de, por ejemplo, C ++
• Robar ideas y / o soluciones de una aplicación protegida por la ley de derechos de autor es una cuestión legal, no técnica, y como tal, proteger la implementación es un asunto legal, independientemente del nivel de protección implementado; una empresa china sospechosa robará su logotipo y aplicación sin problemas, independientemente de si está escrito en JavaScript o en ensamblador
• Además, puede incluir código C ++ en su aplicación si no está convencido de la ofuscación, o puede mover el código a un servicio remoto que, a diferencia de todo lo demás (incluido C ++), está perfectamente protegido de la inspección directa (no de la ingeniería inversa). aunque)

@JohnWeisz dijo muchas cosas realmente sensatas. También agregaré que si no es suficiente para usted, puede usar WebAssembly hoy. En términos de protección del código fuente, eso debería ser bastante bueno.

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

@kidandcat ¿Es cierto? "Atentamente, puede escribir su aplicación en C y distribuir binarios, obtendremos su código fuente de todos modos".

Busqué en Google, parece que es imposible obtener el código fuente de los binarios compilados desde C / C ++. Como máximo, podemos obtener declaraciones de ensamblaje.

Estoy desarrollando un software de escritorio comercial de Windows. La lógica del código es una competencia clave. Esta lógica tiene que ejecutarse en el lado del cliente, pero no quiero que mis competidores la obtengan. Entonces, la protección del código es un factor decisivo en mi caso.

@ z1988hf

Parece que es imposible obtener el código fuente de los binarios compilados desde C / C ++. Como máximo, podemos obtener declaraciones de ensamblaje.

Lo que eso realmente significa es que puede aplicar ingeniería inversa al código fuente original, o algo equivalente, solo que generalmente es prohibitivamente difícil y, por lo tanto, costoso. Lo mismo puede decirse del código ofuscado.

@kidandcat ¿Es cierto? "Atentamente, puede escribir su aplicación en C y distribuir binarios, obtendremos su código fuente de todos modos".

Busqué en Google, parece que es imposible obtener el código fuente de los binarios compilados desde C / C ++. Como máximo, podemos obtener declaraciones de ensamblaje.

Estoy desarrollando un software de escritorio comercial de Windows. La lógica del código es una competencia clave. Esta lógica tiene que ejecutarse en el lado del cliente, pero no quiero que mis competidores la obtengan. Entonces, la protección del código es un factor decisivo en mi caso.

También el ensamblaje es code mate, tu lógica estará ahí. Deberá hacer más cosas para proteger su código que solo compilarlo. (pero como dijo @JohnWeisz , el software de ingeniería inversa es muy caro, por lo que no tendrá que preocuparse si sus competidores no están interesados ​​en tirar algunos miles de dólares solo para probarlo)

Para aquellos que hacen referencia a aplicaciones como Slack por no preocuparse por la protección del código fuente, esa no es la mejor comparación para todas las aplicaciones. Slack es un servicio que vive en línea y su aplicación electrónica es solo un caparazón para mostrar su aplicación web. La mayor parte de la salsa secreta de aplicaciones como slack vive en servidores web.

Para aquellos que hacen referencia a aplicaciones como Slack por no preocuparse por la protección del código fuente, esa no es la mejor comparación para todas las aplicaciones. Slack es un servicio que vive en línea y su aplicación electrónica es solo un caparazón para mostrar su aplicación web. La mayor parte de la salsa secreta de aplicaciones como slack vive en servidores web.

@tu favorito
¿Qué tal Spotify?, sabemos a qué te refieres, pero ¿qué hay de las aplicaciones fuera de línea?

La salsa secreta de @annymosse Spotify no es su aplicación. Si alguien robara la fuente de la aplicación Spotify, realmente no importaría. La aplicación es lo suficientemente buena. La verdadera razón por la que la gente usa y paga Spotify es por la oferta de contenido y la conveniencia de transmitir música. Hay algunos detalles de UX que probablemente muchos de los clientes de Spotify prefieren a las alternativas, pero los competidores realmente no necesitan el código fuente para copiarlos. Además, no he intentado mirar el código fuente de Spotify, pero me imagino que tienen algún tipo de protección integrada en la aplicación en alguna parte. Probablemente alguna ofuscación sólida, así como complementos nativos de C. Creo que esto sería un requisito para ellos debido a DRM.

@yourfavorite solo eche un vistazo a la fuente, asar files y package.json y *.js

No estoy discutiendo contra la protección del código fuente, sino que Slack y Spotify probablemente no sean las mejores comparaciones de lo que la mayoría de la gente está haciendo con el electrón. Además, si la protección del código fuente es fundamental para su producto, entonces quizás electron no sea la mejor opción en este momento.

Y para ser claro, estoy a favor de que la protección del código fuente de algún tipo llegue a electron.

Necesito protección de código fuente. Permítanme proporcionar un caso de uso aquí:

Estoy intentando crear una base de software de traducción en la API de Google Translate.

El usuario arrastra un archivo de subtítulos .srt / .ass al software, y el software usaría la API de Google Translate para traducir cada línea.

Ejemplo

El usuario descargó 1 video y 1 subtítulo en inglés.
Ahora pueden usar este software para traducir este subtítulo en inglés.
al chino o cualquier otro idioma.
Para que puedan entender el contenido.

Problema

Si el código fuente es fácil de conseguir.
aparentemente, el atacante podría obtener mi clave y secreto de API. y abusar de ella.
y obtendría una factura enorme de Google ($ 500? $ 1000? ¿más?)

Actualización rápida (2020-marzo-29)

Estoy usando Vue.js + Webpack con Electron.js
para que todo el código se minimice, por lo que ya no es un problema

@ 1c7

Bueno, tal vez debería usar alguna protección externa para lograr esto. También podría obtener fácilmente su clave API desde un software C ++, no hay problema. Así que esto no es realmente un problema específico de los electrones.

@lvkins oh ya veo. No sabía que el software C ++ también tuviera este problema. No estoy familiarizado con este idioma.
¡Gracias por los consejos!

Básicamente, todos los lenguajes de programación pueden someterse a ingeniería inversa. Siempre fue una gran preocupación. Es cierto que cualquier protección es mejor que ninguna protección, pero aún así; tenemos que hacer un esfuerzo adicional para proteger los datos confidenciales, sin importar el lenguaje de programación. En su caso, probablemente debería optar por una biblioteca de C ++, ponerle un poco de sal extra y vincularla a su node.js, eso debería bastar.

@lvkins Me estás respondiendo, ¿verdad?
Gracias por la sugerencia. Investigaría sobre esto.

Quiero usar Electron.js porque quiero que este software de traducción pueda ejecutarse tanto en Mac como en Windows.

Parece que Electron.js + algo de C ++ podría proteger mi clave y secreto de API

Gracias @lvkins

@ 1c7 De hecho 😃

Empiece aquí: https://nodejs.org/api/addons.html

Si le preocupa la falta total de seguridad de Electron, también puede probar NW.js.

¡Buena suerte!

@ 1c7 y ¿por qué no Linux? !! Creo que es la misma base de código para todas las plataformas, ¿verdad?

@annymosse Me olvidé de mencionar Linux, nada en contra de Linux.

FYI:

• Estoy usando una Macbook Pro 2017 de 15 pulgadas (Mac)
• La mayoría de mis usuarios usan Windows (Windows)
• No he visto a ninguno de mis usuarios de software usándolo en Linux (Linux)

Estaba pensando en convertir https://github.com/1c7/Translate-Subtitle-File
este proyecto en un proyecto serio (cobrar dinero y tener mayor calidad (dedicar más tiempo))
así que estoy investigando ahora

Esta herramienta se enfocaría principalmente en el mercado de China por ahora. (todo el botón y el texto estarían en chino)
i18n está en el mapa pero no lo estará pronto

Tenía un plan para crear la API del traductor i18n y Yandex, pero debido al mismo problema, cancelé el proyecto, luego, en Linux, la mayoría de los usuarios más nuevos no confían en los programas que creen que no existen en Linux o no hay alternativa así que si creas ese proyecto y tus objetivos de usuarios solo traducen los medios, pueden usar cualquier disto de Linux o mi distribución preferida deepin (distribución china de Linux), espero lo mejor para ti y para todos los usuarios de Linux.

Sus claves de API y su secreto nunca deben estar en una aplicación publicada. En lugar de eso, tienes
en sus API / backend, y protéjalos con algún tipo de
autenticación / estrangulamiento. Luego, haz que tu aplicación consuma tus API.

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

@annymosse https://github.com/annymosse Me olvidé de mencionar Linux,
nada contra Linux

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/electron/electron/issues/2570?email_source=notifications&email_token=ADCOXMFCSHRX3PZTE7GHKDTQPRLQRA5CNFSM4BODX2F2YY3PNVWWK3TUL52HS4DFLOVREXG43WWK3TUL52HS4DFVREXG43WZDMVN5 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/ADCOXMCKPUOMQPM3JKZP5J3QPRLQRANCNFSM4BODX2FQ
.

Existe una biblioteca llamada bytenode que le permite convertir sus archivos Javascript en archivos binarios para que nadie pueda leerlos.

Primero instale bytenode en su servidor y en su carpeta:

>npm i -g bytenode
>npm i bytenode

Cree un archivo nodeJS normal con el siguiente código. Imaginemos que nombramos el siguiente código: ok.js

>console.log('bytenode works!);
Luego, compile su código javascript. El comando creará un archivo .JSC con el mismo nombre que su archivo.

user<strong i="15">@machine</strong>:~$ bytenode -c ok.js
Luego, en un archivo JS principal de electrones, llamará a su binario, llamémoslo test.js:

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

Guárdalo.

Luego, llamará test.js: node test.js para probarlo. Haz un "cat ok.jsc" para ver que realmente es un binario y que nadie puede ver tu código. Puede mover su archivo js de prueba simple original a otra ubicación.
No lo probé desde un electrón, pero supongo que funcionaría, ¿no es así?