Electron: A fonte está realmente protegida com a construção de aplicativos com Electron?

Não, é muito fácil obter seu código-fonte mesmo quando você os empacota no arquivo asar , o mecanismo V8 JavaScript nunca foi projetado para ocultar o código-fonte. O NW.js consegue ocultar completamente um arquivo do código-fonte, mas com o preço de um downgrade de desempenho significativo.

Portanto, se você realmente deseja proteger seu código-fonte, deve escrevê-lo em C ++ e fazer um módulo Node nativo.

Existem algumas opções, mas o nível de proteção que oferecem é limitado pelos motivos mencionados pelo @zcbenz :

• Você poderia implementar alguma lógica de descriptografia por conta própria, em um complemento de nó C ++, mas provavelmente ainda será quebrável (por exemplo, depure o programa e copie o código-fonte após a descriptografia, mas antes da avaliação).
• Também existe o EncloseJS , que afirma compilar seu código para node.js / io.js, então pode funcionar com Electron.
• nw.js , que é um projeto semelhante, tem suporte para instantâneos v8 que fornecem algum tipo de proteção (veja os detalhes aqui ).

Observe que todos esses métodos incorrerão em alguma penalidade de desempenho.

@etiktin Também estou encontrando isso.
É possível apenas aplicar o código node.js diretamente no addon C ++?

@fritx , Node tem um módulo chamado vm que pode avaliar o código. Eu acho que você poderia encontrar uma maneira de chamá-lo ou está sublinhando a API C ++ de seu addon e usá-lo para carregar seu código.
Lembre-se de que o usuário ainda consegue abrir as ferramentas do desenvolvedor e ver o script carregado. Mesmo se você conseguir bloquear isso usando uma compilação Electron customizada e o addon verificando se sua compilação Electron não foi adulterada, o usuário ainda poderá ver seu código como uma string na memória.

Parece bom proteger a fonte! :chave:

Então eu tenho uma pergunta, como aplicativos de elétrons de código fechado, como GitKraken, Whatsapp ou Slack podem esconder o código?

@ alexis57 tenho a mesma pergunta; talvez seja apenas porque o elemento inspecionar está desabilitado ou algo assim

Ou talvez o código principal venha de uma biblioteca C / C ++ e então eles usam electron apenas para a GUI, não sei ...

Gostaria de saber como o whatsapp e o slack protegem seu código-fonte também

AFAIK é simplesmente desprotegido. Você pode extrair seu app.asar e acessar o código-fonte. Para partes confidenciais do aplicativo, você geralmente escreve complementos personalizados em uma linguagem compilada como C / C ++, conforme sugerido acima.

Como podemos compilar o código c ++ nele?

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

@boeserwolf obrigado! :)

Subscrito

Também é possível com node-ffi . O elétron deve ser usado apenas para a IU.

Pode valer a pena explorar a escrita do código em C / C ++ e, em seguida, usar uma ferramenta como o emscripten para convertê-lo em web assembly. Isso deve funcionar muito bem com o Chromium

Qualquer coisa pode ser desmontada / desofuscada com bastante esforço. Escrever seu código em JavaScript e incluí-lo no ASAR manteria a maioria das pessoas fora. Existe uma razão para proteger o código que o copyright / licenciamento não cobre?

Meus 2 centavos aqui, NW parece resolver o problema dos instantâneos v8
https://nwjs.io/blog/js-src-protect-perf/

Me deparei com este artigo de nwjs, "código binário compilado agora é executado tão rápido quanto o código-fonte JS sem sobrecarga de desempenho" que era de 30% anteriormente, e será ativado por padrão na versão posterior do NW.

Muito interessado nisso, também li o artigo que

É muito desconfortável para os desenvolvedores. Desista e mude para NW ...

Eu gostaria de compartilhar outro projeto node.js que usa proteção de código de uma maneira muito elegante: https://github.com/zeit/pkg

Talvez haja esperança de proteção de fonte no Electron?

Além de usar C ++ para algumas partes, você também pode reduzir e _ofuscar_ sua fonte JavaScript (por exemplo, usando javascript-obfuscator ).

A minimização e a ofuscação juntas aumentam _dramaticamente_ o esforço necessário (e, portanto, o _custo_) para "roubar" seu código, muitas vezes até o ponto em que a engenharia reversa de todo o aplicativo do zero se torna facilmente muito mais viável - e tecnicamente não há nada que você possa fazer sobre a engenharia reversa, mesmo que você vá para o nativo completo (nada, além de buscar a lei).

Se você não está preocupado em ocultar seu código-fonte, mas deseja ocultar seus segredos, como:

• Credenciais OAuth
• URLs não destinados a serem conhecidos pelo público (ou seja, terminais de API de back-end privados)
• Credenciais da API REST
• Quaisquer chaves e segredos
• Senhas

Criei um serviço GRATUITO para resolver esse problema. Tive de fazer isso porque estava fazendo um aplicativo comercial de elétrons e estava preocupado em ter minhas credenciais roubadas.

Ele funciona criando um aplicativo auxiliar de plataforma cruzada que inicia seu aplicativo de elétron real IFF com o qual seu aplicativo não foi adulterado. Depois de iniciar o aplicativo, ele passará suas credenciais por meio das variáveis ​​de ambiente.

Mais Informações:

Introdução:
https://medium.com/@rocketlaunchr.cloud/introducing -electron-vault-d09ade2c2020

Documentação:
https://rocketlaunchr.github.io/electron-vault-docs/

@JohnWeisz

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

Como o servidor do servidor remoto sabe realmente que o cliente é, na verdade, seu aplicativo Electron inalterado?
Esse é o problema que eu estava tentando resolver.

Se você usar o OAuth com o tipo de concessão Client Credentials , seu client_secret ainda estará embutido em seu aplicativo e qualquer pessoa poderá, em teoria, lê-lo. Com o código-fonte do Electron 100% aberto e disponível, é fácil pesquisar strings que pareçam "interessantes".

Não existe uma maneira 100% infalível de resolver o problema, mas acredito que minha solução é uma melhoria definitiva.

Eu acredito que isso é possível construindo seus aplicativos JS com webpack ou estrutura SPA como angular2 / 4/6 ou vuejs2. isso minimiza seu código e é meticuloso, embora se extraia o arquivo asar, pode ser difícil para eles lerem seu código

Acho que o problema não deve se concentrar apenas na criptografia real. Mas no fato, nenhum outro aplicativo / usuário adulterou o código-fonte do cliente.

Ter um arquivo asar assinado ou binário semelhante a partir do qual o código-fonte é carregado permitiria que o electron checasse a integridade do arquivo. Visto que a verificação de integridade poderia ser integrada no próprio binário eletrônico, não haveria uma sobrecarga no código javascript. Basicamente, na construção, o elétron pode receber um sinalizador --include-integridade-check, caso contrário, a maneira normal de fazer isso é compilada.

@tulpn

Uma vez que a verificação de integridade poderia ser integrada no próprio binário eletrônico, não haveria um ...

- então já é apenas uma questão de extrair qualquer verificação de integridade ou criptografia / descriptografia que o Electron fizer, e você terá o código-fonte. Estou convencido de que a ofuscação é a única abordagem que você pode fazer aqui (seja minificação, minimização + ofuscação ou compilação de código nativo).

Isso, ou mover parte do código do seu aplicativo para um serviço remoto (com autenticação, se precisar de segurança).

Você pode criptografar seus dados e descriptografá-los em tempo de execução e carregá-los diretamente em variáveis ​​como tokens ou qualquer tipo de dados confidenciais, mas se você está falando sobre criptografar arquivos javascript inteiros, o desempenho será prejudicado. Você pode experimentar os complementos do Node C ++

Como o nodejs diz:

Os complementos do Node.js são objetos compartilhados vinculados dinamicamente, escritos em C ++, que podem ser carregados no Node.js usando a função require () e usados ​​como se fossem um módulo Node.js comum. Eles são usados ​​principalmente para fornecer uma interface entre o JavaScript em execução nas bibliotecas Node.js e C / C ++.

Basicamente, ele compila seu código em binário e dessa forma você pode abstrair seu código e o desempenho será muito mais rápido e você pode ocultar seu código até certo ponto.

Não, é muito fácil obter seu código-fonte mesmo quando você os empacota no arquivo asar , o mecanismo V8 JavaScript nunca foi projetado para ocultar o código-fonte. O NW.js consegue ocultar completamente um arquivo do código-fonte, mas com o preço de um downgrade de desempenho significativo.

Portanto, se você realmente deseja proteger seu código-fonte, deve escrevê-lo em C ++ e fazer um módulo Node nativo.

como posso desabilitar devtools de addons c ++ e como posso acessar toda a API do electron de addons c ++ e existe algum plano para empacotar um aplicativo sem o devtool isso pode ser útil para evitar hacks e com menos tamanho do aplicativo ( @ zcbenz )

Todos nós estamos cansados ​​de nosso código fonte ser publicado. Estou me mudando para o novo

@ ahmtcn123 Como seu comentário está ajudando a resolver esse problema?

Você deseja construir aplicativos com técnicos da web que, essencialmente, tenham seu código-fonte público, então pare com essa atitude.

• Você pode contribuir com a Electron para resolver este problema
• Escreva módulos C ++
• Minimize / ofusque / destrua seu código (e não se esqueça de desativar os mapas de origem)
• Você pode mudar para outra tecnologia semelhante (como nw.js), ou você pode ir para o nativo
• Algumas outras soluções foram compartilhadas aqui, você pode trocar ofuscação por performances (o que não é uma escolha tão evidente de se fazer quando já sabemos as performances / consumo de recursos do Electron)

Felicidades!

_edit: continue votando mal, pessoal_ 🍿

Por que não oferece suporte a v8snapshot?

Eu entendo que não podemos proteger completamente o código-fonte. mas outra maneira pode ser criar um serviço da web usando tecnologia compilada nativa (como golang) para proteger o código lógico e chamar da IU do elétron por meio do host local.

a última palavra

NO

por que este problema foi fechado?

Porque ocultar o código-fonte sempre foi um tópico controverso, pois é considerado Segurança através da obscuridade um método muito ruim para proteger o seu código.

Se você quiser alguma proteção, use métodos mais padrão, como autenticação para executar ações críticas, criptografia e assim por diante.

Atenciosamente, você pode escrever seu aplicativo em C e distribuir binários, nós obteremos seu código-fonte de qualquer maneira.

PD: você pode acessar o código fonte dos big boys (whatsapp web, slack, times, vscode) e nenhum deles se importa com isso, talvez você esteja fazendo algo errado.

"" "PD: você pode acessar o código-fonte dos big boys (whatsapp web, slack, times, vscode) e nenhum deles se importa com isso, talvez você esteja fazendo algo errado." ""

Dificilmente se pode fazer um argumento mais idiota.

Vender software sem querer que ele seja submetido a engenharia reversa e usado de maneiras que não deveria não é anormal; na verdade, existem leis exatamente para isso, o que não impede que os usuários continuem fazendo isso.

@kidandcat

Atenciosamente, você pode escrever seu aplicativo em C e distribuir binários, nós obteremos seu código-fonte de qualquer maneira.

Vá em frente, obtenha a fonte de todos os aplicativos mais vendidos, como Microsoft Word, Photoshop ou até mesmo dos jogos mais vendidos. Você é um bilionário e eu não sei disso ou o quê?

Não rsrsrs, não sou bilionário porque ter o código fonte desses programas é inútil, o que você vai fazer com isso?

Pessoal, por favor, há muitas pessoas neste tópico que são notificadas a cada comentário, por favor, sejam construtivos.

Para resumir, possivelmente, por que, em minha opinião, ter que lidar com as peculiaridades do código-fonte do JavaScript não é um obstáculo em muitos casos:

• Muitos dos aplicativos / serviços de exemplo listados aqui são impulsionados em grande parte por sua _tração_; Pegue o Twitter, por exemplo, não é exatamente um mistério como ele funciona internamente, mas mesmo copiando-o totalmente e reproduzindo-o integralmente não levará você a lugar nenhum sem o tráfego, a publicidade, a marca, a infraestrutura de apoio, etc.
• A ofuscação adequada torna extremamente, _proibitivamente_ difícil acessar o código-fonte de qualquer forma significativa, a ponto de se tornar muito mais viável simplesmente observar o comportamento do próprio aplicativo e fazer engenharia reversa com base nele, sem depender do original código-fonte - bem como no caso de, por exemplo, C ++
• Roubar ideias e / ou soluções de um aplicativo protegido pela lei de direitos autorais é uma questão legal, não técnica e, como tal, proteger a implementação é uma questão legal, independentemente do nível de proteção implementado; uma empresa chinesa suspeita roubará seu logotipo e aplicativo sem problemas, independentemente de ter sido escrito em JavaScript ou Assembly
• Além disso, você pode incluir código C ++ em seu aplicativo se não estiver convencido sobre a ofuscação ou mover o código para um serviço remoto que, ao contrário de tudo (incluindo C ++), está perfeitamente protegido de inspeção direta (não de engenharia reversa no entanto)

@JohnWeisz disse muitas coisas realmente sensatas. Acrescentarei também que, se não for o suficiente para você, você pode usar o WebAssembly hoje. Em termos de proteção do código-fonte, isso deve ser muito bom.

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

@kidandcat É verdade? "Sinceramente, você pode escrever seu aplicativo em C e distribuir binários, nós obteremos seu código-fonte de qualquer maneira."

Pesquisei no google, parece que é impossível obter o código-fonte de binários compilados em C / C ++. No máximo, podemos obter instruções de montagem.

Estou desenvolvendo um software de desktop Windows comercial. A lógica do código é uma competência chave. Essa lógica deve ser executada no lado do cliente, mas não quero que meus concorrentes a entendam. Portanto, a proteção de código é o fator decisivo no meu caso.

@ z1988hf

parece que é impossível obter o código-fonte de binários compilados em C / C ++. No máximo, podemos obter instruções de montagem

O que isso realmente significa é que você pode fazer a engenharia reversa do código-fonte original ou algo equivalente, mas geralmente é proibitivamente difícil e, portanto, caro. O mesmo pode ser dito sobre o código ofuscado.

@kidandcat É verdade? "Sinceramente, você pode escrever seu aplicativo em C e distribuir binários, nós obteremos seu código-fonte de qualquer maneira."

Pesquisei no google, parece que é impossível obter o código-fonte de binários compilados em C / C ++. No máximo, podemos obter instruções de montagem.

Estou desenvolvendo um software de desktop Windows comercial. A lógica do código é uma competência chave. Essa lógica deve ser executada no lado do cliente, mas não quero que meus concorrentes a entendam. Portanto, a proteção de código é o fator decisivo no meu caso.

Além disso, a montagem é um parceiro de código, sua lógica estará lá. Você precisará fazer mais coisas para proteger seu código do que apenas compilá-lo. (mas como @JohnWeisz disse, software de engenharia reversa é muito caro, então você não precisa se preocupar se seus concorrentes não estão interessados ​​em jogar alguns milhares de dólares apenas para experimentá-lo)

Para aqueles que estão se referindo a aplicativos como o Slack como não se importando com a proteção do código-fonte, essa não é a melhor comparação para todos os aplicativos. O Slack é um serviço que vive online e seu aplicativo eletrônico é apenas um shell para exibir seu aplicativo da web. A maior parte do molho secreto de aplicativos como o Slack reside em servidores da web.

Para aqueles que estão se referindo a aplicativos como o Slack como não se importando com a proteção do código-fonte, essa não é a melhor comparação para todos os aplicativos. O Slack é um serviço que vive online e seu aplicativo eletrônico é apenas um shell para exibir seu aplicativo da web. A maior parte do molho secreto de aplicativos como o Slack reside em servidores da web.

@seu favorito
que tal o spotify !!!, nós sabemos o que você quer dizer, mas e os aplicativos offline ??

O molho secreto do @annymosse Spotify não é o app deles. Se alguém roubou o código-fonte do aplicativo Spotify, isso realmente não importaria. O aplicativo é bom o suficiente. O verdadeiro motivo pelo qual as pessoas usam e pagam pelo Spotify é a oferta de conteúdo e a conveniência de streaming de música. Existem alguns detalhes de experiência do usuário que provavelmente são preferidos a alternativas por muitos dos clientes do Spotify, mas os concorrentes não precisam realmente do código-fonte para copiá-los. Além disso, não tentei olhar o código-fonte do Spotify, mas imagino que eles tenham algum tipo de proteção embutida no aplicativo em algum lugar. Provavelmente alguma ofuscação sólida, bem como addons C nativos. Acho que isso seria um requisito para eles devido ao DRM.

@seufavorito basta dar uma olhada na fonte deles, pense que às vezes não estamos escondendo nossa fonte para aplicativos comerciais, fazemos isso para evitar nossos serviços longe de hackers, pois eles obtêm algumas linhas fracas, de qualquer forma, só precisamos desse recurso se há uma capacidade de fazer isso, pelo menos algum método para passar asar files e package.json e *.js

Não estou argumentando contra a proteção do código-fonte, mas sim que o Slack e o Spotify provavelmente não são as melhores comparações para o que a maioria das pessoas está fazendo com o elétron. Além disso, se a proteção do código-fonte for crítica para o seu produto, talvez o elétron não seja a melhor opção no momento.

E para ser claro, sou a favor da proteção do código-fonte de algum tipo chegando ao elétron.

Preciso de proteção do código-fonte. Deixe-me fornecer um caso de uso aqui:

Estou tentando construir uma base de software de tradução na API do Google Translate

O usuário arrasta um arquivo de legenda .srt / .ass para o software, e o software usa a API do Google Translate para traduzir cada linha.

Exemplo

O usuário baixou 1 vídeo e 1 legenda em inglês.
Agora eles podem usar este software para traduzir esta legenda em inglês
em chinês ou qualquer outro idioma.
Para que eles possam entender o conteúdo.

Problema

Se o código-fonte for fácil de obter.
aparentemente, o invasor conseguiu obter minha chave e segredo de API. e abusar dela.
e eu receberia uma fatura enorme do Google ($ 500? $ 1000? mais?)

Atualização rápida (2020-março-29)

Estou usando Vue.js + Webpack com Electron.js
então todo o código ficaria reduzido, então não é mais um problema

@ 1c7

Bem, talvez você deva usar alguma proteção externa para conseguir isso. Eu poderia facilmente pegar sua chave API de um software C ++ também, sem problemas. Portanto, este não é realmente um problema específico do elétron.

@lvkins oh, entendo. Eu não sabia que o software C ++ também tinha esse problema. Não estou familiarizado com este idioma.
Obrigado pelas dicas!

Basicamente, todas as linguagens de programação podem sofrer engenharia reversa. Sempre foi uma grande preocupação. É verdade que qualquer proteção é melhor do que nenhuma proteção, mas ainda assim; precisamos fazer um esforço extra para proteger os dados confidenciais, independentemente da linguagem de programação. No seu caso, você provavelmente deve ir para uma biblioteca C ++, colocar um pouco de sal extra nela e vinculá-la ao seu node.js. Isso deve bastar.

@lvkins Você está me respondendo certo?
Obrigado pela sugestão. Eu iria investigar isso.

Quero usar Electron.js porque quero que este software de tradução possa ser executado em Mac e Windows.

Parece que Electron.js + algum C ++ pode proteger minha chave e segredo de API

Obrigado @lvkins

@ 1c7 Certamente 😃

Comece aqui: https://nodejs.org/api/addons.html

Se a total falta de segurança do electron o preocupa, também pode experimentar o NW.js.

Boa sorte!

@ 1c7 e por que não Linux? !! Eu acho que é o mesmo código-base para todas as plataformas, certo ??!

@annymosse Eu apenas esqueci de mencionar o Linux, nada contra o Linux.

PARA SUA INFORMAÇÃO:

• Estou usando um Macbook Pro 2017 de 15 polegadas (Mac)
• A maioria dos meus usuários usa Windows (Windows)
• Não vi nenhum usuário do meu software usando-o no Linux (Linux)

Eu estava pensando em transformar https://github.com/1c7/Translate-Subtitle-File
este projeto em um projeto sério (cobra dinheiro e tem maior qualidade (gaste mais tempo nisso))
então estou fazendo minha pesquisa agora

Esta ferramenta visaria principalmente o mercado da China por enquanto. (todos os botões e textos estariam em chinês)
i18n está no mapa, mas não será em breve

Eu tinha um plano para criar a API do tradutor i18n e Yandex, mas devido ao mesmo problema eu cancelei o projeto, então no Linux a maioria dos usuários mais novos não tem confiança nos programas que eles acham que não existe no Linux ou não há alternativa portanto, se você criar esse projeto e seus usuários direcionarem apenas a tradução da mídia, eles poderão usar qualquer Linux disto ou minha distribuição preferida deepin (distribuição Linux em chinês), espero o melhor para você e todos os usuários do Linux.

Suas chaves e segredo de API nunca devem estar em um aplicativo publicado. Em vez disso,
-los em suas APIs / back-end, e protegê-los com algum tipo de
autenticação / limitação. Em seguida, faça com que seu aplicativo consuma suas APIs.

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

@annymosse https://github.com/annymosse Eu apenas esqueci de mencionar o Linux,
nada contra Linux

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/electron/electron/issues/2570?email_source=notifications&email_token=ADCOXMFCSHRX3PZTE7GHKDTQPRLQRA5CNFSM4BODX2F2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBYJ5TI#issuecomment-544251597 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/ADCOXMCKPUOMQPM3JKZP5J3QPRLQRANCNFSM4BODX2FQ
.

Existe uma biblioteca chamada bytenode que permite converter seus arquivos Javascript em arquivos binários para que ninguém possa lê-los.

Primeiro instale o bytenode em seu servidor e em sua pasta:

>npm i -g bytenode
>npm i bytenode

Crie um arquivo nodeJS normal com o seguinte código nele. Vamos imaginar que nomeamos o seguinte código: ok.js

>console.log('bytenode works!);
Em seguida, compile seu código javascript. O comando criará um arquivo .JSC com o mesmo nome do seu arquivo.

user<strong i="15">@machine</strong>:~$ bytenode -c ok.js
Então, em um arquivo JS de elétron principal, você chamará seu binário, vamos chamá-lo de test.js:

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

Salve isso.

Em seguida, você chamará test.js: node test.js para testá-lo. Faça um "cat ok.jsc" para ver que é realmente um binário e que ninguém pode ver seu código. Você pode mover seu arquivo js de teste simples original para outro local.
Não testei do elétron, mas acho que funcionaria, não é?