I build my first electron app but now I wonder how to protect the source code to be view by other developers.
The official doc says :
To protect your app's resources and source code from the users, you
can choose to package your app into an asar archive with little
changes to your source code.
So far the best I can think of is uglyfy the source-code and package it into a asar file, but the asar file is just an archive and can be easily be extracted. I don't see how having that make your code "protected from the user"
Any ideas ?
There is no official way to copy-protect your code at the moment, sorry - if you want to do this, you'll have to invent your own way (or just not worry about it)
It's impossible to fully protect the code, no matter how you package it, in order for it to be run it has to be accessible and decrypted which means the key has to be stored locally.
Consider this scenario;
The authors of the electron system and asar file format implement encryption similar to a password protected zip, and give you the ability to specify the archive password at compile time so that it is 'safely' stored inside the .exe and the asar file can't be opened/read without it.
A hacker could still figure out the key by compiling electron themselves with some test keys, for instance AAAA and AAAB, then comparing the resultant binary file to determine the location of the key string inside it. Once they know how to extract the key from the exe it's game over.
I guess the strongest protection you can make is if you modify the electron source code yourself to store and retrieve the key, but even then an attacker can decompile the code, compare it with a decompiled standard version of electron, figure out where your code modifications start and reverse engineer it until they figure out how you are storing the key.
Again, the moment they have the key, it's game over, and in order for electron to run any code it has to be able to read it which means it has to have the key available locally. Catch 22.
Related
When I wanted to export the model I was working on as a Java application, I encountered an error regarding the databases I loaded into the model. When I said OK to the error, I realized that all the files in the folder I wanted to create the Java application were deleted. That folder was desktop by the way.
Right now all the files (i mean all of them!) on my desktop are deleted and they don't even show up in the recycle bin. How are we going to solve this situation? How can AnyLogic have the authority to delete all files in that folder? How is this authority not shared with me and not warned beforehand?
When you work with software in general, you need to have a version control in place that will allow you to recover your information. These problems occur, and if AnyLogic has access to your computer it's because you grant the permission and it needs the permission. If you make your desktop your project folder, then i would say you are to blame.. why would you do that...
Using GIT as Ben commented, is always a good idea... but it requires you to be conscious about when you commit a version.
What I do, is I use dropbox and all my projects are done in a dropbox folder... the good thing is that dropbox always saves automatically all the files on the folder... this has saved my life multiple times and I suggest you to do something like that in the future. So on one hand you have the autosaving features, which is useful, but sometimes you erase everything by mistake, and the autosave is not useful, but dropbox saves no matter what.
I have a simple GWT app.
Whenever I run gwt compilation for production, I also see a file with the extension .devmode.js being generated.
Questions:
This looks like a devmode-related file; do I actually need it while running in production? Do I need to delete it?
What does it do?
If useless, is there any way to stop it from being generated while in production?
I'm using GWT 2.8.
Kind regards,
Andrei
It is specific to legacy Dev Mode, and not used in Super Dev Mode. If you don't ever use legacy Dev Mode, you don't need it.
You don't need it in production... unless you ever need to debug your app in production. If you ever want to debug your app in production (with legacy dev mode), you should leave it.
You do not need to delete it - it will not be used unless you attempt to enter dev mode, and it is a static file, and cannot be used to maliciously debug your app, unless the attacker also has all of your original Java source code already.
The Linker system does not currently have a way to prevent it from being emitted. The "generation" of it is very simple, only the __MODULE_NAME__ tokens are replaced with the name of your app, so there is essentially no penalty paid in creating it.
Unless you need the extra 1k of disk space in your generated app, I wouldn't worry about it at all as there is no risk in having it. If you do need that extra 1k, either modify your current linker to avoid emitting it, or add a later build step to delete it.
Theres a few questions similar to this, so I'll try to be clear as possible.
We have an existing, fairly large and complex, GWT webgame I have been asked to make work offline. It has to be offline in pretty much the strictest sense.
Imagine we have been told to make it work off a CD Rom.
So installation is allowed, but we cant expect the users to go to a Chrome/Firefox store and install it from there. It would need to be off the disc.
Likewise, altering of the browsers start-up flags would be unreasonable to expect of users.
Ideally, it would be nice if they just clicked a HTML file for the start page and it opened in their browsers of choice.
We successfully got it working this way in Firefox by adding;
"<add-linker name='xsiframe' />"
To our gwt.xml settings. This seems to solve any security issues FF has with local file access.
However, this does not solve the problem for Chrome.
The main game starts up, but various file requests are blocked due to security issues like these;
XMLHttpRequest cannot load file:///E:/Game%20projects/[Thorn]%20Game/ThornGame/text/messages_en.properties. Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https, chrome-extension-resource.MyApplication-0.js:34053 com_google_gwt_http_client_RequestBuilder_$doSend__Lcom_google_gwt_http_client_RequestBuilder_2Ljava_lang_String_2Lcom_google_gwt_http_client_RequestCallback_2Lcom_google_gwt_http_client_Request_2 MyApplication-0.js:34053
Now I was aware same origin policy issues might popup as during development we often tested locally using flags in chrome to bi-pass them.
Thing is...now I dont know how to get around them when we cant use startup flags.
Obviously in the example given its just the .properties file GWT uses to get some language related text. I could dump that inline in one way or another.
However, its only one of many,many,many files being blocked.
The whole game was made to run off *.txt game scripts on the sever - to allow easy updating by non-coders. Really the actual GWT code is just an "engine" and all the XMLHttpRequested files supply the actual "game".
These files are of various types; csv, txt, ntlist, jam.
The last two being custom extensions for what are really just txt files.
All these files are blocked by chromes security. It seems from what I can make out only images are allowed to be accessed locally.
Having all these files compiled in would just be impossible, as they are not fixed in number (ie, one central .txt file determains various scene .txt files which in turn determain various object files and directory's...).
Putting all this into a bundle would be nightmare to create and maintain.
So in essence I need some way to supply a offline version of a GWT project that can access a large number of various files in its subdirectories without security issues.
So far all I can think of is;
A) Theres something I can tell chrome via html or gwt that allows these files to be read in Chrome like FF can. (I suspect this isn't possible).
An alternative to XMLHttpRequest maybe?
B) I need to somehow package a game+a webbrowser in a executable package that has permission to access files in its directory's. (http://www.appcelerator.com/titanium ? ?? ).
C) I need to package and have the user run a full webserver that can then deliver all these files in a XMLHttp accessible way.
D) Bit of a funny one...we cant tell the user to add flags to browser start up...but Maybe I could write a game installer which just detects if they have Chrome or Firefox. It then opens up the games html in their browser with the correct flags for them? This would open up security issues if they browse elsewhere with that instance though, so Id presumably need other flags to disable the url bar if that's possible.
I am happy to make various changes to our code to achieve any of this - but as mentioned above theres no way to determain all the files needing to be accessed at compile time.
And finally, of course, it all has to be as easy as possible for the end user.
Ideally just clicking a html file, or installing something no more complex then a standard windows program.
Thanks for reading this rather long explanation, any pointers and ideas would be very welcome. I especially will appreciate multiple different options or feedback from anyone that's done this.
========================================
I accepted the suggestion to use Chromiumembedded below.
This works and does what I need (and much much more)
To help others that might want to use it, I specifically made two critical changes to the example project;
Because CEF needs a absolute path to the web apps local html, I wrote a c++ function to get the directory the .exe was launched from. This was a platform specific implementation, so if supporting a few OS's (which CEF does) be sure to write dedicated code for each.
Because my webapp will make use of local files, I enabled the Chrome flag for this by changing the browser settings;
browser_settings.file_access_from_file_urls = STATE_ENABLED;
These two changes were enough to get my app working, but it is obviously the bare minimum to make a application. Hopefully my finding will help others.
I'd suggest going the wrapper route. That is, provide a minimal browser implementation that opens your files directly. Options are Chromium Embedded[1]. If the nature of the application absolutely requires the files to be served as non-file urls then bundle a minimal webserver, have the on-disk executable start the server and open the bundled browser with whatever startup arguments you want.
[1] https://bitbucket.org/chromiumembedded/cef
I'm making a Lua game using the 2D framework 'LÖVE'.
I needed to know HOW to make a .exe file with it! I've done the command line, sucessfully zipped up my main.lua and the image, I've renamed the file extension to .exe!! When I run the .exe, I get a file extracting application coming up. This is not supposed to happen, right? I want it to be run as a game, not as a self-extracting application. Help?
From the sounds of it, you are trying to save your 'lovechive' with an .exe extension; your archiver is probably 'helpfully' assuming you meant to create a self extractor, which you didn't.
Okay, lets start by talking about how runable 'lovechives' work:
When love.exe starts up, it first checks its own name, if its called something other than love or love.exe it immediately checks to see if there is somethng stuck to its end. if there is, then it tries to interpret it as if it were a 'lovechive'.
So basically, we want to stick a zip-file to love's bottom (don't worry, it likes it).
Start by creating an ordinary zip archive of you game directory.
Remember to check for anything you don't actually mean to ship; plenty of love games have gone out containing backup copies of the source code, test artwork, and peoples' shopping lists. Don't be a statistic.
The filename is irrelevant for what were are doing here, so don't worry about the usual step of renaming it to a .love. just make sure that what you have is an plain-ol' ordinary zip.
The next step depends on your host platform, but basically you now need to do the whole "stick it to love's bottom' part now, generally this is done from the command-line:
On windows, the command is:
copy /b love.exe+YourGame.zip TheGame.exe
Where love.exe is the name of the main 'love' executable YourGame.zip is the name of zip file containing your game, and TheGame.exe is what you want the final game executable to be named.
On Linux or OSX, the command is:
cat love YourGame.zip > TheGame
Where love is the name of the main 'love' executable, YourGame.zip is the name of zip file containing your game, and TheGame is what you want the final game executable to be named.
These substituting the relevant filenames should let you produce versions for Linux, and Windows
(All I know about making 'merged' OSX Apps is that its more complicated.)
For the record, it is utterly trivial to extract files from the 'merged' game. Usually nothing more than changing the file extension, sometimes not even that.
And no, zip encryption doesn't help here; it won't run because love can't read the archive. (quite sensibly, really.)
Finally, If you are distributing to the Love community, they generally prefer that you just give them the 'lovechive.'
From https://love2d.org/wiki/Game_Distribution :
Here's how to do it on Windows. In a console, type this:
copy /b love.exe+game.love game.exe
Then, all you have to do is zip game.exe and required DLLs, and distribute them. Yes; this does mean that the game will have a private copy of LÖVE, but there's nothing wrong with that. It also means that you will have to create one package for each platform you would like to support, or simply offer the .love alone for the other platforms.
Sometimes when we issue an upgrade to our application we need to install some files to the application's Data folder. We want to make it possible for the users to move this folder to a place of their liking. But how to deal with this at install time?
I was thinking of deploying to the user's AppData folder and have the application somehow check there for new files at startup.
Any advice or references would be very welcome!
We use InnoSetup for a VB6 application if that matters for your answer.
Generally the best solution I've found is to allow the user to move the folder from within the application.
This allows the application to keep track of where its data is being kept (by adding a reference to it in a file or registry entry which it accesses at load time) and to access it seamlessly in the future.
Your update routines can then also access this information to determine where to place the update files.
Alternatively, make sure the folder name is as distinctive as possible and add a search routine to look for the directory in a number of sensible places at load time. Then write your manual specifying that the data folder can be moved to one of those locations ONLY.
Wouldn't the users just run an update or patch package? I'm not sure why they'd want or need to see such files. It's pretty rare for commercial software to offer users the options of where to store program settings and other internal-use files.
Give some thought to this before putting a lot of stuff into users' roaming profiles. You might want LocalAppData instead.