[Cuis-dev] Is it possible to hide the source code in a Cuis project ?

[Nicola Mingotti]

On 12/15/21 15:43, Gerald Klix wrote:
> Hi Nicola,
>
> On 12/15/21 12:34 PM, Nicola Mingotti via Cuis-dev wrote:
>> Hi guys,
>>
>> I am considering the possibility of delivering an application
>> I am closing these days in the BeagleBone Black / BeagleBone AI in 
>> Cuis-Smalltalk.
>>
>> The application is already written in Python + Node it would
>> be mostly a translation effort.
>>
>> It would be a major advantage If could hide the code from unwelcome 
>> eyes (the competence).
>> My classes, specific for the application, should be by default 
>> visible only
>> byte compiled.
>>
>> I discovered a few days ago the possibility of seeing the bytecode
>> of a method doing : "Inspect compiled method" so I started to ask
>> myself. Does Cuis need only the compiled method to run? Is it
>> necessary to have also the source code in place ?
> Yes! You can switch of the warnings about missing changes and
> source files and it will happily squeak along without source code.
>>
>> Ideally It would be great if I could keep also the classes source 
>> code into
>> the BBB, but encrypted. In such a way that, if the customer needs
>> a modification, I log in remotely, decrypt the source, make the
>> changes and leave there again only the byte code.
> There should an easier way to do that.
> The only piece of information the decompiler can not reproduce
> are the names of local variables and parameters. AFIR each method
> has a pointer (a 32-bit offset) into the changes file (or the source 
> file). These can be replaced by a collection of local variables names.
> This will enable you to make onsite modifications without the source,
> by relying on the decompiler only. If you want to go
> that way, drop me a note and will look up the details.
>>
>> Just guessing. It could be that my classes are subclasses of 
>> EncrypedClass which
>> by default shows only mangled sourcecode in the Browser, unless the 
>> programmer
>> provides a deciphering password.
> Your changes are rather dim. The decompiler is much to good at 
> decompiling. Of course you might be able to remove the decompiler,
> but it would be easy to file it in again as long there is a compiler
> available. Removing the Compiler will make it impossible to
> make on-site changes and render every useful tool, browser, debugger 
> etc.pp. useless. I bet it will render the image useless.
> Maybe you remember the changes you made to the startup-code,
> even in this part there are references to the compiler.
>
> The only chance I see here, is to change the VM to make it
> load an encrypted image and password-protect access to
> the browser tools in your UI. Of course if someone gains root
> access to your computer, he/she could easily read the decrypted
> image from RAM.
>
> In a nutshell: It is not worth the effort.
>
> I might be worthwhile to run your application with an (overlay)
> file-system that supports encryption (encfs for example).
> Again you need to block access to the browsers in your UI.
>
>
>>
>> Let me know what you think. If this is possible it would be
>> extremely interesting. If you think is very complex to achieve I put it
>> in the desiderata list, procrastinate, and keep it mind for the future.
> I would like to see app distribution with a single file for Cuis
> applications. That is appending the image to the VM executable
> maybe compressed an encrypted. The big problem here is that
> some plugins can not be compiled as internal plugins
> and some drivers must be shared objects/DLLs. Of course
> the VM could be changed here, but that would mean
> Squeak/VMMaker programming.
>
> It is much easier to add modules to Python's
> module loader infrastructure that load encrypted
> modules.
>>
>>
>> Bye
>> Nicola
>
>
> HTH and Best Regards,
>
> Gerald

Thank you Gerald !

Now that you tell me "the compiler is smart" i remembered once in the 
past you told me also:
"you lost the .sources file, I can't see the variables". And i didn't 
even notice the difference !
Therefore I guess our de-compiler is far too smart, leaving only the 
bytecode gives back very readable code
as far as i remember. So obfuscation via removing source code is not a 
viable option.

Luckily the BBB has on board storage, it is not dependent on the SDcard. 
I could sabotage
the SDcard holder, that seems the fastest dumbest way to keep the random 
techie out
of my data. s/he/it

Also, very few people know Smalltalk, this is a second level deterrent. 
Even if
they can fix the SDcard slot then they need to be able to read the code, 
and
this would require some time. For this application I don't have a secret 
formula
to hide, I just don't want others to copy/paste easily the whole 
application, change 2 colors + 1 label
and sell it as their own.

Appimage are cool. I personally don't use them but the concept is good.
In the and every time you install something in the Mac or Windows a huge 
package
comes down, in Linux and BSD we are too perfectionist, we try to get 
dependencies
first and then the program we want. That is maybe the right thing to do, 
but not
the practical thing to do, especially today that a 10Tera disk cost 200euro.

In Linux i guess it is not a big problem to share a Cuis program. E.g. I 
would just
send you a .tar.gz of my cuis-project-xyz directory. But It would be all 
in clear, and that
often is not desirable. For the other systems i don't know.


bye
Nicola