So to recap my understanding.
You hope[d] to somehow edit a copy of your main RB file, and from that make individually customized scrambled RBS files.
This is actually possible.
But your RBS files, put within your distributed RBZ archive cannot be 'signed' for use in >=v2016 [all loading-policies]... unless you actually submit each one of the RBZ files separately and on receipt then send it to your individual user.
Here's an idea...
RBZ contents as follows...
MyLovelyTool.rb == the 'loader'
MyLovelyTool == the subfolder containing...
MyLovelyTool_main_code.rb == compiled by the signing process to RBS or RBE if limited to >=v2016
MyLovelyTool.hash == the signed file referencing all .rb/rbs/rbe/js.htm.html.css files in the RBZ
AND
MyLovelyTool_user_data.rbs == which you make from an RB on a per user basis - containing the individual details you want...
It contains the same module/class set up as the main_code and simply sets the @@a or whatever.
The main_code uses Sketchup;;require('MyLovely_user_data') as it initially loads, so that the customized details are used...
This way the main IP relevant main)code can be RBS or RBE and incorporated in the signing hash, and the user_data can be somewhat obfuscated in your own RBS which is added to the signed RBZ later on...
It will still be loaded by the signed file, while containing individual details.
Be aware that RBS made by your old scrambler exe is readily crack-able, but probably sufficient obfuscation in your case - certainly better than a plain RB - which'd be easily editable.
You can't make a securely encrypted RBE version without going through the signing/encryption process via the web-site.
You could have course make mock RBZs for each user with a matching MyLovelyTool_user_data subfolder and submit those for signing/RBEing, then use just the RBE... adding it to the main RBZ before giving it to the user...
BUT this route seems too much effort for little benefit...
There must be an easier way to do this !