asar
asar copied to clipboard
electron
Add Encryption Feature
Feature request:
Add the ability to encrypt the .asar archive with one or more algorithms based on client-submitted hash/seed/salt. Conversely, also add the ability read the encrypted .asar file by providing the hash/seed/salt.
This would slow down reading times, but for an added benefit for those wanting to keep their code safer. A quick Google search for .asar and instructions to unpack will be the first result.
How would you provide that decryption key? You need it in order to read the ASAR archive, which contains all of the application code
Not necessarily. The start script could be outside of the ASAR archive, providing it the decryption key before reading from the ASAR. (I believe this is how RubyEncoder and others do it).
Another option would be to mark individual files/folders as encrypted that way the ASAR itself isn't encrypted, but certain files/folders within the ASAR are. This would allow a start script within the ASAR to provide the decryption key for said encrypted files.
I would also imagine a viable option via the environment: ASAR_DECRYPT="mySecretKey" main.js.
From my understanding, you don't need ALL of the application code in the ASAR... Am I wrong?
@KevinMartin then what's the point of encrypting it at all, if the key is sitting right next to it?
You wouldn't put it in the main script... This could be done one of three ways:
- The main script will show a dialog (let's say on first-use of the application) asking the user to enter a license key. The main script could then contact the server to see if the license key is valid. If so, it'll return the decryption key over the wire and feed it to the ASAR.
- This fails because you would need to save the key somewhere once you've fetched it and the location would have to be in plain text.
- If the application doesn't require a license key and just wants to keep the code more secure, the installation script could just save the decryption key in a predetermined location and then loaded upon start.
- This also fails because the location is in plain text.
- I believe what RubyEncoder does is create a binary executable file that either has the key inside or knows where the key file would be on the system.
- This is the best solution but is out of the scope of the project.
I believe the best thing to do would be to just add the functionality of encryption/decryption and allow the application to handle the rest. Just like a ZIP file... You can put a password on the ZIP file, but it doesn't care where you put the password...
You just described all the ways that it doesn't work in the previous comment! :)
Well, I did give a way that it would work:
add the functionality of encryption/decryption and allow the application to handle the rest. Just like a ZIP file... You can put a password on the ZIP file, but it doesn't care where you put the password...
Furthermore, there could be further discussion. I'm sure there might be a better way to do this.
Over the weekend, I was looking at the src and was thinking that instead of adding an encryption or password option, it may be better (or interesting) to instead add a transform option where a transformation object is given to the asar or disk object that provides that content to the transformation object.
The transformation object would have two methods: read and write (or whatever other naming convention you would like to use). By having this, users can write their own encryption methods or statistical analysis functions or whatever.
A bootstrap electron application that loads protected features packed in separate ASAR could make use of encryption to secure the feature. The key can be provided the user.
I have implemented a similar feature in one of my own Electron applications (Not with an ASAR though) using cryptoJS-AES to encrypt certain application modules. Users permitted to use the feature are given a key to enter in a dialogue.
I don't propose that this be a built in ability, but I can't see anything stopping devs from just encrypting modules in the same way themselves.
@KevinMartin What prevents you from simply storing the encrypted files within the asar and later decrypt them via some middleware when they are needed?
The idea is to not use any middleware and have it be integrated into the tools we currently use.
Plus, that method would require a hack on the require function just like asar-require does... which isn't ideal.
how about a solution where electron-packager handles the encryption of the asar file with a random key and only electron executable is able to read it?
or a unified encryption key unknown to users for all asar files. and the key would be included with electron itself (though this is less secure)
Why not to entirely switch to ZIP and stop reinventing the wheel? It supports all of this, for over decade.
@ArktekniK
I have implemented a similar feature in one of my own Electron applications (Not with an ASAR though) using cryptoJS-AES to encrypt certain application modules. Users permitted to use the feature are given a key to enter in a dialogue.
Can you share any examples or advice of how you pulled this off?
Sure. I can provide guidance but the code itself is for a corporate product.
It depends on what your goals are. If you want to hide your source code from prying eyes then you can only really obfuscate it. This is because you'll need some way of providing a decryption key to electron applications. This could be within the electron executable itself but it's still trivial for someone to retrieve that key anyway and decrypt the asar.
If your goal is to hide the contents of a particular file from everyone except a chosen few, (perhaps a config file with credentials or IDs etc) then you can encrypt the file with Crypto JS. I used crypto js's AES component with a passcode that only some people knew. I then provided a prompt to enter the passphrase.
This was some time ago but I remember that if you load electron without an app.asar, it'll load the bootstrap asar that lets you drag and drop an asar onto it. Using the debugger you can replicate the code to load in your decrypted archive.
The problem comes from providing the keys widely to decrypt your protected files. Sorry to not have been more help
you can use the transform option to provide a function that will transform (or indeed, encrypt) a file stream on the way in to the asar. Getting it back out and decrypting it is another matter; I've wondered if there's scope for a transform option when reading stuff out of the ASAR to do a similar job as the equivalent on the way in when writing?
how i can use EncloseJS and V8Snapshot with EleteronJS and Asar files? my app size is 7 GB,app have many video files.
This is an really cool idea, keeping on mind that this is an compressing method like zip, rar, etc. Unless if that can affect perfomance in the builded apps i think what that function may be available as something optional to do for the user, it must be there.
This is currently opening thousands of Electron apps to injection vulnerabilities as per https://www.contextis.com/en/blog/basic-electron-framework-exploitation
Do you guys think it would be a good time to start looking at this in a more favorable light?
This is currently opening thousands of Electron apps to injection vulnerabilities as per https://www.contextis.com/en/blog/basic-electron-framework-exploitation
Do you guys think it would be a good time to start looking at this in a more favorable light?
This would still only be a form of security through obscurity. IIUC a determined attacker could still acquire the password, decrypt the files, implant the backdoor and then distribute the modified app.
This is becoming more an issue at scale due to the recent ransomware and backdoor attacks. Code signing and validation should be added to the core of Electron so no unsigned packages can be loaded and existing apps can not be tempered.
The Electron team should really take responsibility and implement such a simple but very important core feature.
Encryption is already widely available in node.
We actually need this feature in electron, as many of us don't want to expose our commercial level software code to anyone else. Here is a guy I found who is able to do this but I am not completely able to understand that how he is doing all this but he actually able to encode asar file. Link: https://github.com/toyobayashi/electron-asar-encrypt-demo
Easy, Cheap, Secure. Pick two.
Point is, Electron makes it very easy to hit the ground running with a functional desktop app with tools web developers are used to (Easy & Cheap). If you want to add "Secure" in to the mix, you have to forego one of the other two (or, perhaps both); there is no solution that works easily, cheaply and securely.
I'm not an Electron contributor, but I have spent a lot of time with this "feature".
Here are the problems that need solving to do this:
Ensure ASAR integrity
We need to ensure that the ASAR does not have code in it that it wasn't shipped with. The obvious choice is to use traditional RSA signatures (fast and proven), so you would embed a per-application public key in the final application, checksum the ASAR, and sign it with a per-application private key at build time, and then verify the checksum and its signature at runtime. The problems with this is that it's relatively trivial to find the embedded public key, replace it with your own, and re-sign the ASAR with the corresponding private key (after you've made whatever modifications, malicious or otherwise, that you need to) and redistribute it. It's also trivial to lift the ASAR from one application and run it in your own, so it doesn't matter that it has retained integrity.
Ensure ASAR authenticity
We need to ensure that the ASAR has been produced by whom it pertains to have been produced by. As above, but with a check on the public key to make sure it's the one we expect, but you have the same problem, the bit that checks the public key is not immutable and can be tampered with (and the ASAR can be lifted in to another Electron application, thus bypassing this check entirely)
Ensure ASAR privacy
The solution here is to use an encryption cipher of some kind on the way in to the ASAR. If the user has to provide the key at runtime, this is kind of do-able, however, once the "stuff" is unencrypted, it exists unencrypted in memory and can be fetched relatively easily. In the other case, where the user doesn't need to provide anything, and the means to decrypt are hidden in the application, it doesn't take a lot for an attacker to find the key and do the decryption themselves outside of the application, thus revealing all the stuff you wanted to keep secret.
The fact remains that the application must be shipped with everything it needs to authenticate, verify integrity, and decrypt the ASAR, so any measures that you could put in place are easily circumvented, and the tools/skills to protect authenticity, integrity and privacy checks are not easy to use, nor are they cheap.
I hope some of the core members of Electron, get involved as this is really a very important feature. @MarshallOfSound
I'd personally be OK with just the ability to use signed node snapshots like nw.js provides. That alone provides a level of tampering detection I kinda sorta legally require to use Electron? We just can't afford to handle HIPAA data -or other sensitive things- securely without some kind of ability to tell wether or not our application has been compromised.
Try https://obfuscator.io/ for a true obfuscator with debug protection and self defending code.
I found another solution for encrypting files, it is a bit complex and may not work perfectly for all projects but it has a great capability to hide the code in the form of byte code. Further help is provided here: https://stackoverflow.com/a/68710667/7352827
Try https://obfuscator.io/ for a true obfuscator with debug protection and self defending code.
Card stealer on this link, be careful!
