0

Our public API (ruby) saves JSON assets to an Amazon S3 bucket. Those assets are showed to our users through a javascript reader.

Our customers would like to have those assets obfuscated. I'm currently looking into some workflow to:

  1. Obfuscate in ruby
  2. Save it on S3 (with Paperclip)
  3. Deobfuscate in javascript

The point (2) is pretty much figured out as I can create a new style and use a processor with Paperclip.

For the (1) and (3) I'm struggling to find a working solution that won't be too easy to be reverse engineered.

Daniel Costa
  • 275
  • 2
  • 14
  • A complete guide present here https://stackoverflow.com/questions/2123437/ruby-obfuscator. https://github.com/jwt/ruby-jwe – NN796 Jun 24 '19 at 08:38
  • for (3) it's impossible. Client-side JS can be read by anybody. So, there is no reliable way to de-obfuscate the resource without also giving away the de-obfuscation mechanic and thus likely the obfuscation mechanic. What is the purpose of this anyway? Any resource has to be readable in order to work. And you need that readable in the client. So, by definition, any resource given to the client will be available. – VLAZ Jun 24 '19 at 08:38
  • @VLAZ yes you are right, as long as we de-obfuscate in JS, anyone can de-obfuscate. The purpose of obfuscation is to "make obscure, unclear, or unintelligible.". Our goal is to not have it readable by the "human eye" easily and to be able to rotate obfuscation methods. If you feel like uncompressing our 300k lines of frontend minified code and reverse engineer it, then yes, you gonna have access to it. – Daniel Costa Jun 24 '19 at 11:20
  • @NN796 this is to obfuscate ruby code, I'm trying to obfuscate some JSON assets. – Daniel Costa Jun 24 '19 at 11:21
  • @DanielCosta I'm still not clear on what the end goal is. If you just want to stop casual observers, you can base64 encode it. It's almost useless as a protection mechanism but it would stop casual people from looking into it. If you want to make it harder for more determined people to the point where you want to rotate de-obfuscation mechanisms, you've already lost. Almost nobody who is going to bother looking into a base64 encoded strings would be stopped by harsher measures. At the very least, they could just drop a breakpoint after decoding and look at the data there. – VLAZ Jun 24 '19 at 11:31
  • @VLAZ the end goal doesn't really matter here. The question is quite simple: what method should be used that allows to obfuscate a file in Ruby and de-obfuscate in javascript. – Daniel Costa Jun 26 '19 at 11:52
  • @DanielCosta that's *a solution*. I don't know what *the problem* is. Are you trying to protect the data in flight from somebody snooping with Wireshark? Are you trying to protect from somebody opening the dev tools and the network tab? Are you trying to protect the data from being used by any user? The first's solution is HTTPS, the second it's encoding the data. The third is to not transfer the data. I'm not sure what "obfuscating the entire payload, then deobfuscate it and be able to rotate the mechanisms" solves. – VLAZ Jun 26 '19 at 12:22
  • @VLAZ We have a 3D model that is in form of a text file. This file is read by our custom 3D viewer. Our goal is to obfuscate this 3D model because this file is accessible by anyone. Our 3D viewer takes care of de-obfuscating and displaying it. The reason we doing that is that in its text form, this file could be read by competitors 3D viewers. – Daniel Costa Jun 28 '19 at 09:48

0 Answers0