Howdy, Stranger!
We are about to switch to a new forum software. Until then we have removed the registration on this forum.
Categories
- All Categories 25.7K
- Announcements & Guidelines 13
- Common Questions 30
- Using Processing 22.1K
- Programming Questions 12.2K
- Questions about Code 6.4K
- How To... 4.2K
- Hello Processing 72
- GLSL / Shaders 292
- Library Questions 4K
- Hardware, Integration & Other Languages 2.7K
- Kinect 668
- Arduino 1K
- Raspberry PI 188
- Questions about Modes 2K
- Android Mode 1.3K
- JavaScript Mode 413
- Python Mode 205
- Questions about Tools 100
- Espanol 5
- Developing Processing 548
- Create & Announce Libraries 211
- Create & Announce Modes 19
- Create & Announce Tools 29
- Summer of Code 2018 93
- Rails Girls Summer of Code 2017 3
- Summer of Code 2017 49
- Summer of Code 2016 4
- Summer of Code 2015 40
- Summer of Code 2014 22
- p5.js 1.6K
- p5.js Programming Questions 947
- p5.js Library Questions 315
- p5.js Development Questions 31
- General 1.4K
- Events & Opportunities 288
- General Discussion 365
In this Discussion
- asimes December 2014
- calsign November 2014
- cunami December 2014
- KevinWorkman December 2014
- PhiLho December 2014
Answers
This old thread may be of interest.
I would recommend ProGuard for obfuscation (and more), although you may run into problems with libraries and such that rely on reflection (maybe even Processing core, but I can't be sure). Once set up properly, it should make reverse engineering significantly more difficult. The advice in the thread above also sounded promising, but it depends heavily on your specific situation.
Security through obscurity is not security.
Anything that you run on the client side can be "reverse engineered".
The solution is to mostly not care about "reverse engineering". And anything that needs to be secure (passwords, database access, etc) should be run on the server side.
Code obfuscation is not really in the spirit of Processing's community (with the exception of when giving code to someone who is asking for their assignment to be done for them, then providing code they can't claim to have made is kinda funny). Also, as pointed out, this is not secure, unobfuscating code can be done by a patient programmer
Well I know its impossible to protect the code from a good and patient programmer but you know I would like to make it not straight forward. Same as windows puts a serial but in most cases it gets cracked. If there would be no serial most people would just press "next" and don't care about the serial. But if you have the serial most people will buy windows and the unimportant ones will use a cracked version (they probably can't afford it anyway).
Also I hear it often that this is not the forum where you should not speak about code protection, but I would leave it to the user if he protects it or not. I think that people that don't like the idea of protecting the code should have the knowledge about it. The decision if the developer uses his knowledge to protect the code or not should be let to him.
Anyway, maybe I should get back to the question:....as this is not a discussion topic :D
The point is: whatever approach you take to "secure" your code, it won't be secure. Your example is flawed: it's like if Microsoft implemented a serial key, but then accepted anything you entered into the serial key text box. What's the point?
Even if you run your code through an obfuscator, people can still get to your code.
Anything you think needs to be secure, needs to be done on the server side.
Personally, I don't care if you keep your code open, closed or obfuscated. The "spirit of Processing" isn't a rule, anyway.
The above comments just warn you that whatever protection scheme you use, it is prone to be frail. If that's OK for you, protecting from 90 % of curious users, go for it. ProGuard is probably the best option in this field.