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

Nicola Mingotti nmingotti at gmail.com
Thu Dec 23 13:36:50 PST 2021



On 12/19/21 17:08, graham kelly via Cuis-dev wrote:
>
>
> 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
>
>

I found some more info, in the discussion there is Robert Nelson, so 
what is there
must be considered definitely reliable. And it is not too-too old (2017).
https://forum.beagleboard.org/t/how-to-protect-scripts-and-codes/26575

It is not possible to protect source code in the BeagleBoard.
Therefore all my Python, Node, Smalltalk code is available for copy/paste.

That is a pity and a problem.
I will consider well what parts it makes sense to rewrite in C++, bury
into an Arduino or provide as Web services.

bye
Nicola








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20211223/7d827940/attachment-0001.htm>


More information about the Cuis-dev mailing list