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

[Gerald Klix]

On 12/16/21 12:07 AM, Nicola Mingotti via Cuis-dev wrote:
> 
> 
> 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:
Well -- forgive me some nitpicking here -- the compiler is rather dumb,
which makes it easy for the decompiler to look smart :=}
> "you lost the .sources file, I can't see the variables". And i didn't 
> even notice the difference !
Oh yes, I remember that conversation. Now that you mention it,
AFIR it was our first conversation.
> 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.
Yes it is so simple, that even script kiddies can do it.
> 
> 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
Some hot glue may help. Maybe the SD-Card-Slot can be disabled
by some means of firmware-configuration. If you want to do
this properly you should also disable any JTAG-interface.
> 
> 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.
IC, deter the script kiddies is a sensible goal.
It will also save time, because you don't need to support/fix
devices that were hacked by some (not so) educated user.
> 
> 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.
AppImages are rather lean, when it comes to dependencies, but
the dependency-hell starts when you want to build the AppImage-builder
by your self.
I like Google's go-compiler, it produces statically linked executables,
that only need a syscall-interface.
> 
> 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.
If you stick to ZIP-files the result is fairly portable;
disregarding the VM executable and the shared objects/DLLs it needs.

An app-store or any other sort of application -- in fact Cuis image -
repository would help, if we can find a portable
and easy way to install the squeak vm and a simple local
app-store.
> 
> 
> bye
> Nicola
> 

Best Regards,

Gerald