Electron: Is the source really protected with building apps with Electron?

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.

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.

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

@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.

Sounds good protect the source! :key:

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

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

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

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

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.

How can we compile c++ code in it?

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

@boeserwolf thanks! :)

Subscribed

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

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?

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.

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 ;)

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

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?

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).

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/

@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.

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

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.

@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).

You can encrypt your data and decrypt it on runtime and load it directly into variables like tokens or any kind of sensitive data but if you're talking about encrypting whole javascript files then it will take a toll on performance. You can give a shot to Node C++ Addons

As nodejs says it:

Node.js Addons are dynamically-linked shared objects, written in C++, that can be loaded into Node.js using the require() function, and used just as if they were an ordinary Node.js module. They are used primarily to provide an interface between JavaScript running in Node.js and C/C++ libraries.

Basically it compiles your code into binary and that way you can abstract your code and performance will be alot faster and you can hide your code to some extent.

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.

how can i disable devtools from c++ addons and how can i access all of the API of electron from c++ addons and is there any plan to package an app without the devtool this may helpfull to prevent the hacks and with less size of the application (@zcbenz )

We all tired of our sourcecode gets published. Im moving to nw

@ahmtcn123 How is your comment helping solving this problem?

You want to build apps with web techs that by essense have their source code public, so stop with that attitude.

• You can contribute to Electron to address this problem
• Write C++ modules
• Minify / obfuscate / mangle your code (and don’t forget to disable source maps)
• You can move to another similar tech (like nw.js), or you can go native
• A few other solutions has been shared here, you can trade obfuscation for performances (which is a not a so evident choice to make when we already know the performances/resources consumption of Electron)

cheers!

_edit: keep down-voting guys_ 🍿

Why not support v8snapshot?

I understand we can not completely protect the source code. but another way can be creating web service using native compiled technology(like golang) for protecting logic code and calling from electron UI through localhost.

the last word

NW

why was this issue closed?

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.

"""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

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?

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

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)

@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

@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.

@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 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)

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.

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??

@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.

@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

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.

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 or any other languages.
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? more?)

Quick Update (2020-March-29)

I am using Vue.js + Webpack with Electron.js
so all the code would get minify, so it's not a problem anymore

@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.

@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!

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.

@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

@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!

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

@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

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.

Your API keys & secret should never be in a published app. Instead have
them on your APIs/backend, abd protect them with some type of
authentication/throtling. Then have your app consume your APIs.

Em dom, 20 de out de 2019 10:22, Cheng Zheng notifications@github.com
escreveu:

@annymosse https://github.com/annymosse I just forgot to mention Linux,
nothing against Linux

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/electron/electron/issues/2570?email_source=notifications&email_token=ADCOXMFCSHRX3PZTE7GHKDTQPRLQRA5CNFSM4BODX2F2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBYJ5TI#issuecomment-544251597,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADCOXMCKPUOMQPM3JKZP5J3QPRLQRANCNFSM4BODX2FQ
.

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?

@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.

@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

@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.

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)

Your app should send text to your server, which then forwards it to Google, receives the translation, and sends that back to the app.

You should have your own server acting as a middleman between your customers and Google's translation service, and only your server should have your API key.

It's probably against Google's terms of use to share your API key anyway.

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)

Your app should send text to your server, which then forwards it to Google, receives the translation, and sends that back to the app.

You should have your own server acting as a middleman between your customers and Google's translation service, and only your server should have your API key.

It's probably against Google's terms of use to share your API key anyway.

alright for commercial project, which provide a resource money to handle the service costs and its team maintenance, but we need a source protection for open source projects such tools , at least to keep it hard to debug it and make some black hacks.

Gave up on Electron for a while thinking that this issue would be solved years back. Still no solution? Very disappointing. I wish i had the time to put in so i can come up with my own solution for this. 😟

Gave up on Electron for a while thinking that this issue would be solved years back. Still no solution? Very disappointing. I wish i had the time to put in so i can come up with my own solution for this. 😟

Its impossible to hide the js code. Even if you separate every function to single file and obfuscate it, as long as files are on client computer it can be reverse engineered. But you can support your app with server