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

[graham kelly]

On 12/16/21 2:40 AM, Gerald Klix via Cuis-dev wrote:
>
>
> 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.
Couldn't you use a blocklist, where competitors aren't allowed to see 
the code... but everyone else can?
>>>>
>>>> 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.
...and makes sure the source code is believable, less a user copies the 
"source code" and fuzzes until they get valid Smalltalk.
>>> 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.
>>>
Or not root, at least on Linux a process running as the same user can 
sometimes read all of that memory.
>>> 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.
+1. However, what about the Dynabook vision?
>>>>
>>>>
>>>> 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.
For now, at least... What about the Dynabook vision? Cuis might put a 
backdoor into the core system and allow Cuis to reinstate the compiler, 
tools, etc. And /all/ of that could plausibly be for the Dynabook vision.
>>
>> 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

Love (for the Dynabook vision),

Graham

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20211219/8290e6bc/attachment.htm>