Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is the source really protected with building apps with Electron? #2570

Closed
ashking opened this issue Aug 24, 2015 · 62 comments
Closed

Is the source really protected with building apps with Electron? #2570

ashking opened this issue Aug 24, 2015 · 62 comments

Comments

@ashking
Copy link

@ashking ashking commented Aug 24, 2015

Hey guys,

This is not entirely a bug.

I was wondering; are the apps built with Electron protects the source? I tried JxCore and it does not protect source. How about electron?

Cheers

@zcbenz

This comment has been minimized.

Copy link
Member

@zcbenz zcbenz commented Aug 24, 2015

No, it is very easy to get your source code even when you packaged them in asar archive, the V8 JavaScript engine is never designed to hide source code. NW.js does succeed to hide one file of the source code completely, but with the price of significant performance downgrade.

So if you really to want to protect your source code, you have to write them in C++ and make a native Node module.

@zcbenz zcbenz closed this Aug 24, 2015
@etiktin

This comment has been minimized.

Copy link
Contributor

@etiktin etiktin commented Aug 24, 2015

There are some options, but the level of protection they provide is limited by the reasons @zcbenz mentioned:

  • You could implement some decryption logic on your own, in a C++ node addon, but it will probably still be breakable (e.g. debug the program and copy the source after decryption but before eval).
  • There's also EncloseJS, that claims to compile your code for node.js/io.js, so it might work with Electron.
  • nw.js, which is a similar project, has support for v8 snapshots which provide some kind of protection (see details here).

Note that all of this methods, will incur some performance penalty.

@fritx

This comment has been minimized.

Copy link
Contributor

@fritx fritx commented Jul 27, 2016

@etiktin I'm running into this too.
Is it possible to just apply node.js code in C++ addon directly?

@etiktin

This comment has been minimized.

Copy link
Contributor

@etiktin etiktin commented Jul 27, 2016

@fritx, Node has a module called vm which can eval code. I guess you could find a way to call it or it's underlining C++ API from your addon and use that to load your code.
Keep in mind that the user could still manage to open the developer tools and see the loaded script. Even if you manage to block that using a custom Electron build and the addon checking to see that your Electron build wasn't tampered with, the user could still see your code as a string in memory.

@fizzvr

This comment has been minimized.

Copy link

@fizzvr fizzvr commented Aug 17, 2016

Sounds good protect the source! 🔑

@alexisfrjp

This comment has been minimized.

Copy link

@alexisfrjp alexisfrjp commented Feb 2, 2017

Then I have a question, how closed code electron apps such as GitKraken, Whatsapp or Slack can hide the code ?

@Hum4n01d

This comment has been minimized.

Copy link
Contributor

@Hum4n01d Hum4n01d commented Feb 3, 2017

@Alexis57 I have the same question; maybe it’s just that inspect element is disabled or something

@alexisfrjp

This comment has been minimized.

Copy link

@alexisfrjp alexisfrjp commented Feb 3, 2017

Or maybe the main code comes from a C/C++ library and then they use electron just for the GUI, don't know...

@nabtron

This comment has been minimized.

Copy link

@nabtron nabtron commented Mar 1, 2017

Would like to know how whatsapp and slack protect their source code too

@boeserwolf

This comment has been minimized.

Copy link

@boeserwolf boeserwolf commented Mar 22, 2017

AFAIK it's simply unprotected. You can extract their app.asar and access the source code. For sensitive parts of the application you usually write custom addons in a compiled language like C/C++, as suggested above.

@nabtron

This comment has been minimized.

Copy link

@nabtron nabtron commented Mar 22, 2017

How can we compile c++ code in it?

@boeserwolf

This comment has been minimized.

Copy link

@boeserwolf boeserwolf commented Mar 22, 2017

@nabtron

This comment has been minimized.

Copy link

@nabtron nabtron commented Mar 22, 2017

@boeserwolf thanks! :)

@vasyl-shumskyi

This comment has been minimized.

Copy link

@vasyl-shumskyi vasyl-shumskyi commented Jun 29, 2017

Subscribed

@alexisfrjp

This comment has been minimized.

Copy link

@alexisfrjp alexisfrjp commented Jun 30, 2017

It's also possible with node-ffi. Electron should be used only for the UI.

@bsclifton

This comment has been minimized.

Copy link
Member

@bsclifton bsclifton commented Jul 2, 2017

It might be worth exploring writing the code in C/C++ and then using a tool like emscripten to convert it to web assembly. This should work great with Chromium

Anything can be disassembled / unobfuscated with enough effort. Writing your code in JavaScript and having it included in the ASAR would keep the majority of people out. Is there a reason for protecting the code that copyright / licensing doesn't cover?

@craftpip

This comment has been minimized.

Copy link

@craftpip craftpip commented Jul 2, 2017

My 2 cents here, NW seem to solve the problem of v8 snapshots
https://nwjs.io/blog/js-src-protect-perf/

I came across this article from nwjs, "compiled binary code now run as fast as JS source code without performance overhead" which was 30% previously, and it will be turned on by default in the later release of NW.

@ConsoleTVs

This comment has been minimized.

Copy link

@ConsoleTVs ConsoleTVs commented Jul 7, 2017

Really interested in this, I also red the article @craftpip told us and seems to be rather interesting. If electron had code protection (even if it was slower at user-end) this will make a lot of developers feel safe and confident while writting their applications. Give it a chance electron team ;)

@ianli-sc

This comment has been minimized.

Copy link

@ianli-sc ianli-sc commented Jul 21, 2017

It's too uncomfortable for developers. Give up and switch to NW...

@baszczewski

This comment has been minimized.

Copy link

@baszczewski baszczewski commented Feb 8, 2018

I would like to share other node.js project which use code protection in very elegant way: https://github.com/zeit/pkg

Maybe there is hope for source protection in Electron?

@JohnWeisz

This comment has been minimized.

Copy link

@JohnWeisz JohnWeisz commented Apr 17, 2018

In addition to using C++ for some parts, you can also minify and obfuscate your JavaScript source (e.g. using javascript-obfuscator).

Minification and obfuscation together will dramatically increase the required effort (and thus cost) to "steal" your code, often up to the point that reverse-engineering your entire application from scratch easily becomes much more feasible -- and there is technically nothing you can do about reverse-engineering, even if you go full-native (nothing, besides seeking the law).

@rocketlaunchr-cto

This comment was marked as off-topic.

Copy link

@rocketlaunchr-cto rocketlaunchr-cto commented May 8, 2018

If you're not worried about hiding your source code BUT you do want to hide your secrets such as:

  • OAuth credentials
  • URLs not intended to be known to the public (i.e. private backend API endpoints)
  • REST API credentials
  • Any Keys and Secrets
  • Passwords

I've created a FREE service to address this issue. I had to make it because I was making a commercial electron app and was worried about having my credentials stolen.

It works by creating a cross-platform helper application which launches your actual electron application IFF your application has not been tampered with. Once it launches the application, it will pass your credentials through the environment variables.

More information:

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

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

@rocketlaunchr-cto

This comment was marked as off-topic.

Copy link

@rocketlaunchr-cto rocketlaunchr-cto commented May 8, 2018

@JohnWeisz

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

How does the remote server server truly know that the client is actually your unaltered Electron App?
That's the problem I was trying to solve.

If you use OAuth with the Client Credentials grant type, then your client_secret is still baked into your application and anyone can in theory read it. With Electron source code 100% open and available, it's easy to search for strings that appear "interesting".

There is no 100% fool proof way to solve the problem but I believe my solution is a definite improvement.

@Geowan

This comment has been minimized.

Copy link

@Geowan Geowan commented Jun 9, 2018

I believe this is possible by building your JS apps with webpack or SPA framework like angular2/4/6 or vuejs2. this minify your code and its painstaking even though one extracts the asar file it may be hard for them to read your code

@tulpn

This comment has been minimized.

Copy link

@tulpn tulpn commented Jul 6, 2018

I think the issue should not just focus on the actual encryption. But on the fact, that no other application/user has tampered with the source code of the client.

By having a signed asar archieved or similar binary from which the source code is loaded would allow electron to check the integrity of the file. Since the integrity check could be integrated in the electron binary itself, there would not be an overload in the javascript code. Basically on build the electron could get a flag --include-integrity-check, otherwise the normal way of doing it is compiled.

@JohnWeisz

This comment has been minimized.

Copy link

@JohnWeisz JohnWeisz commented Jul 6, 2018

@tulpn

Since the integrity check could be integrated in the electron binary itself, there would not be an ...

-- then it's already only a matter of extracting whichever integrity-checking or encryption/decryption Electron does, and you have the source code. I'm convinced obfuscation is the only approach you can take here (be it minification, minification+obfuscation, or native code compilation).

That, or moving some of your app code to a remote service (with authentication if you need security).

@ourfamilygithub

This comment has been minimized.

Copy link

@ourfamilygithub ourfamilygithub commented Dec 29, 2018

the last word

NW

@z1988hf

This comment has been minimized.

Copy link

@z1988hf z1988hf commented Jul 10, 2019

why was this issue closed?

@kidandcat

This comment has been minimized.

Copy link

@kidandcat kidandcat commented Aug 19, 2019

Because hidding source code has been always a controversial topic because it is considered Security through obscurity a very bad method to protect your code.

If you want some protection, use more standard methods, like authentication to perform critical actions, encryption, and so on.

Sincerely, you can write your app on C and distribute binaries, we will get your source code anyway.

PD: you can access the source code of the big boys (whatsapp web, slack, teams, vscode) and none of them care about it, maybe you are doing something wrong.

@turd-afk

This comment has been minimized.

Copy link

@turd-afk turd-afk commented Aug 26, 2019

"""PD: you can access the source code of the big boys (whatsapp web, slack, teams, vscode) and none of them care about it, maybe you are doing something wrong."""

One can hardly make a dumber argument.

Selling software without wanting it to be reverse engineered and used in ways it's not supposed to isn't abnormal, in fact there are laws exactly for that, which doesn't stop users from still doing it.

@kidandcat

This comment has been minimized.

Copy link

@kidandcat kidandcat commented Aug 26, 2019

@kidandcat

Sincerely, you can write your app on C and distribute binaries, we will get your source code anyway.

Go on, get the source of all the top selling apps like Microsoft word, Photoshop, or even top selling games. Are you a billionaire and I'm unaware of it or what?

No lol, I'm not billionaire because having the source code of those programs is useless, what are you going to do with it?

@martpie

This comment has been minimized.

Copy link

@martpie martpie commented Aug 26, 2019

Guys please, there are a lot of people in this thread who get notified for each comment, please keep it constructive.

@JohnWeisz

This comment has been minimized.

Copy link

@JohnWeisz JohnWeisz commented Aug 27, 2019

To possibly summarize why, in my opinion, having to deal with the source-code peculiarities of JavaScript isn't a deal-breaker in many cases:

  • A lot of example apps/services listed here are driven largely by their traction; take Twitter for example, it isn't exactly a mystery how it is working internally, but even by fully copying it and reproducing it in its entirety won't get you anywhere without the traffic, the advertising, the brand, the backing infrastructure, etc.
  • Proper obfuscation makes it extremely, prohibitively difficult to access the source code in any meaningful fashion, to the point where it becomes much more feasible to simply observe the behavior of the application itself and reverse-engineer it based on that, without relying on the original source code -- much like in the case of e.g. C++
  • Stealing ideas and/or solutions from an application protected by copyright law is a legal question, not a technical one, and as such, protecting the implementation is a legal affair, regardless of the level of protection implemented; a fishy Chinese firm will steal your logo and app without problems, regardless of whether it was written in JavaScript or Assembly
  • Additionally, you can include C++ code in your application if you are not convinced about obfuscation, or you can move code to a remote service which is, unlike everything else (including C++), is perfectly protected from direct inspection (not from reverse-engineering though)
@martpie

This comment has been minimized.

Copy link

@martpie martpie commented Aug 27, 2019

@JohnWeisz said a lot of really sensible things. I will also add that if it is not enough for you, you can use WebAssembly today. In terms of protecting source code, that should be quite good.

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

@z1988hf

This comment has been minimized.

Copy link

@z1988hf z1988hf commented Sep 6, 2019

@kidandcat Is it true?"Sincerely, you can write your app on C and distribute binaries, we will get your source code anyway."

I searched on google, seems it is impossible to get source code out of binaries compiled from C/C++. At most, we can get assembly statements.

I am developing a commerical windows desktop software. Code logic is key competence. These logic has to run on client side but I don't want my competitors to get it. So code protection is deal breaker in my case.

@JohnWeisz

This comment has been minimized.

Copy link

@JohnWeisz JohnWeisz commented Sep 6, 2019

@z1988hf

seems it is impossible to get source code out of binaries compiled from C/C++. At most, we can get assembly statements

What that really means is that you can pretty much reverse-engineer the original source code, or something equivalent, only it's usually prohibitively difficult and thus expensive. The same can be said about obfuscated code.

@kidandcat

This comment has been minimized.

Copy link

@kidandcat kidandcat commented Sep 6, 2019

@kidandcat Is it true?"Sincerely, you can write your app on C and distribute binaries, we will get your source code anyway."

I searched on google, seems it is impossible to get source code out of binaries compiled from C/C++. At most, we can get assembly statements.

I am developing a commerical windows desktop software. Code logic is key competence. These logic has to run on client side but I don't want my competitors to get it. So code protection is deal breaker in my case.

Also assembly is code mate, your logic will be there. You will need to do more things to protect your code than just compiling it. (but as @JohnWeisz said, reverse engineering software is very expensive, so you will not need to worry if your competitors are not interested in throwing some thousands of dollars just to try it)

@yourfavorite

This comment has been minimized.

Copy link

@yourfavorite yourfavorite commented Sep 6, 2019

For those that are referencing apps like Slack as not caring about source code protection, that’s not the best comparison for all apps. Slack is a service that lives online and their electron app is just a shell for displaying their web app. The majority of the secret sauce of apps like slack lives on web servers.

@annymosse

This comment has been minimized.

Copy link

@annymosse annymosse commented Sep 7, 2019

For those that are referencing apps like Slack as not caring about source code protection, that’s not the best comparison for all apps. Slack is a service that lives online and their electron app is just a shell for displaying their web app. The majority of the secret sauce of apps like slack lives on web servers.

@yourfavorite
how about spotify !!!,we know what do you mean but how about the offline apps??

@yourfavorite

This comment has been minimized.

Copy link

@yourfavorite yourfavorite commented Sep 7, 2019

@annymosse Spotify's secret sauce is not their app. If someone stole the Spotify app source, it wouldn't really matter. The app is good enough. The real reason people use and pay for Spotify is because of the content offering and the convenience of streaming music. There are some UX details that are probably preferred to alternatives by many of Spotify's customers but competitors don't really need the source code to copy that. Additionally, I haven't attempted to look at Spotify's source code, but I'd imagine they have some sort of protection built into the app somewhere. Likely some solid obfuscation as well as native C addons. I think this would be a requirement for them due to DRM.

@annymosse

This comment has been minimized.

Copy link

@annymosse annymosse commented Sep 7, 2019

@yourfavorite just take a look at them source ,put in your mind sometimes we're not hidding our source for commercial apps , we do that to prevent our services far than hackers which they get some weak lines,anyway we just need this feature if there's an ability to do that ,at least some method to pass the asar files and the package.json and *.js

@yourfavorite

This comment has been minimized.

Copy link

@yourfavorite yourfavorite commented Sep 7, 2019

I’m not arguing against source code protection, but rather that Slack and Spotify likely aren’t the best comparisons for what most people are doing with electron. Additionally, if source code protection is critical for your product, then perhaps electron is not the best fit at this time.

And to be clear, I’m in favor of source code protection of some kind coming to electron.

@1c7

This comment has been minimized.

Copy link

@1c7 1c7 commented Oct 20, 2019

I need source code protection. Let me provide a use case here:

I am trying to build a translation software base on Google Translate API

User drag a .srt/.ass subtitle file into the software, and the software would use Google Translate API to translate every single line.

Example

User downloaded 1 video and the 1 English subtitle. now they can use this software to translate this English subtitle into Chinese / Any other language they like. so they can understand the content.

Problem

If source code is easy to get. apparently attacker could get my API key&secret. and abuse it. and I would get a massive bill from Google. ($500? $1000? $10000? who knows)

@lvkins

This comment has been minimized.

Copy link

@lvkins lvkins commented Oct 20, 2019

@1c7

Well, perhaps you should be using some external protection to achieve this. I could easily grap your API key from a C++ software as well, no problem. So this is not really an electron specific issue.

@1c7

This comment has been minimized.

Copy link

@1c7 1c7 commented Oct 20, 2019

@lvkins oh I see. I didn't know C++ software have this problem too. I am not familiar with this language.
Thanks for the tips!

@lvkins

This comment has been minimized.

Copy link

@lvkins lvkins commented Oct 20, 2019

Basically every programming language can be reverse engineered. It always was a big concern. True that any protection is better than no protection, but still; we need to put some extra effort to protect the sensitive data, no matter which programming language. In your case, you should probably go for a C++ library, put some extra salt on it and link it to your node.js, That should do it.

@1c7

This comment has been minimized.

Copy link

@1c7 1c7 commented Oct 20, 2019

@lvkins You are replying to me right?
Thanks for the suggestion. I would investigate into this.

I want to use Electron.js because I want this translation software to be able to run on both Mac & Windows.

Seem like Electron.js + some C++ could protect my API key&secret

Thanks @lvkins

@lvkins

This comment has been minimized.

Copy link

@lvkins lvkins commented Oct 20, 2019

@1c7 Indeed 😃

Start here: https://nodejs.org/api/addons.html

If electron's total lack of security concerns you, you could also give NW.js a try.

Good luck!

@annymosse

This comment has been minimized.

Copy link

@annymosse annymosse commented Oct 20, 2019

@1c7 and why not Linux?!! i think it's same code-base to all the platforms right??!

@1c7

This comment has been minimized.

Copy link

@1c7 1c7 commented Oct 20, 2019

@annymosse I just forgot to mention Linux, nothing against Linux.

FYI:

  • I am using a Macbook Pro 2017 15 inch (Mac)
  • Most of my user use Windows (Windows)
  • I haven't seen any of my software user using it on Linux (Linux)

I was thinking about turning https://github.com/1c7/Translate-Subtitle-File
this project into a serious project (charge money & have higher quality(spend more time on it) )
so I am doing my research now

This tool would mostly target China market for now. (all the button and text would be in Chinese)
i18n is on the map but not gonna be soon

@annymosse

This comment has been minimized.

Copy link

@annymosse annymosse commented Oct 20, 2019

i had a plan to create i18n & Yandex translator API but coz of the same problem i canceled the project , then on Linux most of the newer users haven't a confidence of the programs which they think it's not exist in Linux or there's no alternative so if you create that project and your users targets only translate the media they can use any Linux disto or my preferred distribution deepin (Chinese Linux distro), hope the best to you and all the Linux users.

@paulovitorjp

This comment has been minimized.

Copy link

@paulovitorjp paulovitorjp commented Oct 20, 2019

@dotbloup

This comment has been minimized.

Copy link

@dotbloup dotbloup commented Dec 11, 2019

There is a library called bytenode which allows you to convert your Javascript files into binary files so that noone can read it.


First install bytenode on your server and in your folder:

>npm i -g bytenode
>npm i bytenode

Create a normal nodeJS file with the following code in it. Let's imagine we name the following code: ok.js

>console.log('bytenode works!);
Then, compile your javascript code. The command will create a .JSC file with the same name than your file.

user@machine:~$ bytenode -c ok.js
Then, in a main electron JS file, you will call your binary, let's call it test.js:

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

Save it.

Then, you will call test.js: node test.js to test it. Do a "cat ok.jsc" to see that it is really a binary and that nobody can't see your code. You can move your original plain test js file to another location.
I didn't test it from electron but I guess it would work, isn't it?

@JohnWeisz

This comment has been minimized.

Copy link

@JohnWeisz JohnWeisz commented Dec 11, 2019

@dotbloup

There is a library called bytenode which allows you to convert your Javascript files into binary files so that noone can read it.

No one will be able to read the original source, that's true (just as with obfuscation or even minification), but you still can't store any app secrets or other sensitive data in your code, because it can still be reverse engineered and/or extracted just the same, it's only a matter of time.

If you want to discourage folks from inspecting or "stealing" parts of your source code, this is a great tool to make it harder, and in many cases, prohibitively difficult. However, do not use it for any sort of real security, because it can be worked around, just as with C++ compilation.

@dotbloup

This comment has been minimized.

Copy link

@dotbloup dotbloup commented Dec 11, 2019

@JohnWeisz
I would love to see a proof of someone breaking the code of a V8 bytecode binary file. I have developped an application with nwjs and i converted the engine in a bin file using nwjc which is exactly the same as bytenode. This application is the Sitecozy broken link checker and it is available on the microsoft store for free.

I propose a challenge.
If anyone can break the code of the bin file of my app and send me the functions & the methods of my bin file, I would give you 150 euros. No need to recreate the code to provide the same effect, No need to show me my variables or my JSON messages, I am not stupid.

you can write to me at stepsahe AT hotmail DOT com

@JohnWeisz

This comment has been minimized.

Copy link

@JohnWeisz JohnWeisz commented Dec 11, 2019

@dotbloup

I mean people usually break copy protection systems in machine code compiled from C++ in a matter of weeks usually, and for decades now, think of pirated games. Point is, if the piece of information is there for the machine, it'll be there for the user to break it open as well.

The only way to securely store app secrets is a sealed system, such as a backend service.

The point here is extracting valuable information, functions and methods are not usually part of this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.