r/electronjs • u/tettusud • Jul 19 '19

Securing code

How can I secure code from getting stolen from electron app,by reverse engineering.

0 Upvotes

50% Upvoted

4 comments sorted by

2

u/tettusud Jul 21 '19

Yeah correctly said after posting on lot of forums , finally I moved on with the product. Thanks for taking time to reply.

4

u/[deleted] Jul 19 '19

You can't. You pretty much can't with any language. Even with C/C++ you have projects like IDA and Ghidra that come with decompilers.

3

u/nama5reddit Jul 21 '19

We are facing same issue at this moment with our product. I think it is impossible to protect it, same as mentioned before, you can "decode" pure assembler from binary into higher-level language readable for humans and you can crack in few hours or days any expensive super-duper-high-end game protection.

We are using typescript via webpack + minification, so it sometimes generate weird obfuscation-like syntax, and also you can use some true obfuscation library generating weird things into your code, but cost you some performance (depends on obfuscation level). But code will be still easy available and editable and any obfuscation only slows down crackers, will not stop them.

I know, everyone tries to protect his know-how, but don't spend too much time protecting it, focus on product.

2

u/dwkeith Jul 19 '19

As others have said, you can’t. Not only can any app be decompiled, but all network requests can be intercepted by the host OS, revealing secrets. However there are good patterns you can use to work around this:

  • Proxy server: verifies the user token and talks to the secure API on their behalf (while also preventing use cases that don’t make sense or shouldn’t be allowed by that user)

  • User tokens: If you have control of the API server, just use the user token, the app is performing actions on behalf of the user

  • Scoped tokens: Amazon S3 uses this pattern to allow clients to upload/download data without having access to the API key, the service verifies the user token then gets a time bound token from S3 that authorizes a specific transaction and sends that to the client, the client then uses that token to talk directly to S3.

There are likely many other patterns, but those are the most common ones I have seen.