<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <div class="moz-cite-prefix">On 12/19/21 17:08, graham kelly via Cuis-dev wrote: </div> <blockquote type="cite" cite="mid:d1596ce9-b0fe-8c4e-f3d2-b25f44abe75a@gmail.com"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <div class="moz-cite-prefix">On 12/16/21 2:40 AM, Gerald Klix via Cuis-dev wrote: </div> <blockquote type="cite" cite="mid:99c2f77f-42e4-0b32-b168-9cc0a8d06161@klix.ch"> On 12/16/21 12:07 AM, Nicola Mingotti via Cuis-dev wrote: <blockquote type="cite"> On 12/15/21 15:43, Gerald Klix wrote: <blockquote type="cite">Hi Nicola, On 12/15/21 12:34 PM, Nicola Mingotti via Cuis-dev wrote: <blockquote type="cite">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. </blockquote> </blockquote> </blockquote> </blockquote> Couldn't you use a blocklist, where competitors aren't allowed to see the code... but everyone else can? <blockquote type="cite" cite="mid:99c2f77f-42e4-0b32-b168-9cc0a8d06161@klix.ch"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> 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 ? </blockquote> Yes! You can switch of the warnings about missing changes and source files and it will happily squeak along without source code. <blockquote type="cite"> 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. </blockquote> 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. <blockquote type="cite"> 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. </blockquote> </blockquote> </blockquote> </blockquote> ...and makes sure the source code is believable, less a user copies the "source code" and fuzzes until they get valid Smalltalk. <blockquote type="cite" cite="mid:99c2f77f-42e4-0b32-b168-9cc0a8d06161@klix.ch"> <blockquote type="cite"> <blockquote type="cite">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. </blockquote> </blockquote> </blockquote> Or not root, at least on Linux a process running as the same user can sometimes read all of that memory. <blockquote type="cite" cite="mid:99c2f77f-42e4-0b32-b168-9cc0a8d06161@klix.ch"> <blockquote type="cite"> <blockquote type="cite">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. <blockquote type="cite"> 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. </blockquote> 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. </blockquote> </blockquote> </blockquote> +1. However, what about the Dynabook vision? <blockquote type="cite" cite="mid:99c2f77f-42e4-0b32-b168-9cc0a8d06161@klix.ch"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> Bye Nicola </blockquote> HTH and Best Regards, Gerald </blockquote> Thank you Gerald ! Now that you tell me "the compiler is smart" i remembered once in the past you told me also: </blockquote> Well -- forgive me some nitpicking here -- the compiler is rather dumb, which makes it easy for the decompiler to look smart :=} <blockquote type="cite">"you lost the .sources file, I can't see the variables". And i didn't even notice the difference ! </blockquote> Oh yes, I remember that conversation. Now that you mention it, AFIR it was our first conversation. <blockquote type="cite">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. </blockquote> Yes it is so simple, that even script kiddies can do it. <blockquote type="cite"> 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 </blockquote> 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. <blockquote type="cite"> 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. </blockquote> 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. </blockquote> 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. <blockquote type="cite" cite="mid:99c2f77f-42e4-0b32-b168-9cc0a8d06161@klix.ch"> <blockquote type="cite"> 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. </blockquote> 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. <blockquote type="cite"> 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. </blockquote> 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. <blockquote type="cite"> bye Nicola </blockquote> Best Regards, Gerald </blockquote> Love (for the Dynabook vision), Graham <fieldset class="moz-mime-attachment-header"></fieldset> </blockquote> 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). <a class="moz-txt-link-freetext" href="https://forum.beagleboard.org/t/how-to-protect-scripts-and-codes/26575">https://forum.beagleboard.org/t/how-to-protect-scripts-and-codes/26575</a> 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 </body> </html>