<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 12/16/21 2:40 AM, Gerald Klix via
Cuis-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:99c2f77f-42e4-0b32-b168-9cc0a8d06161@klix.ch">
<br>
<br>
On 12/16/21 12:07 AM, Nicola Mingotti via Cuis-dev wrote:
<br>
<blockquote type="cite">
<br>
<br>
On 12/15/21 15:43, Gerald Klix wrote:
<br>
<blockquote type="cite">Hi Nicola,
<br>
<br>
On 12/15/21 12:34 PM, Nicola Mingotti via Cuis-dev wrote:
<br>
<blockquote type="cite">Hi guys,
<br>
<br>
I am considering the possibility of delivering an
application
<br>
I am closing these days in the BeagleBone Black / BeagleBone
AI in Cuis-Smalltalk.
<br>
<br>
The application is already written in Python + Node it would
<br>
be mostly a translation effort.
<br>
<br>
It would be a major advantage If could hide the code from
unwelcome eyes (the competence).
<br>
My classes, specific for the application, should be by
default visible only
<br>
byte compiled.
<br>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
Couldn't you use a blocklist, where competitors aren't allowed to
see the code... but everyone else can?<br>
<blockquote type="cite"
cite="mid:99c2f77f-42e4-0b32-b168-9cc0a8d06161@klix.ch">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<br>
I discovered a few days ago the possibility of seeing the
bytecode
<br>
of a method doing : "Inspect compiled method" so I started
to ask
<br>
myself. Does Cuis need only the compiled method to run? Is
it
<br>
necessary to have also the source code in place ?
<br>
</blockquote>
Yes! You can switch of the warnings about missing changes and
<br>
source files and it will happily squeak along without source
code.
<br>
<blockquote type="cite">
<br>
Ideally It would be great if I could keep also the classes
source code into
<br>
the BBB, but encrypted. In such a way that, if the customer
needs
<br>
a modification, I log in remotely, decrypt the source, make
the
<br>
changes and leave there again only the byte code.
<br>
</blockquote>
There should an easier way to do that.
<br>
The only piece of information the decompiler can not reproduce
<br>
are the names of local variables and parameters. AFIR each
method
<br>
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.
<br>
This will enable you to make onsite modifications without the
source,
<br>
by relying on the decompiler only. If you want to go
<br>
that way, drop me a note and will look up the details.
<br>
<blockquote type="cite">
<br>
Just guessing. It could be that my classes are subclasses of
EncrypedClass which
<br>
by default shows only mangled sourcecode in the Browser,
unless the programmer
<br>
provides a deciphering password.
<br>
</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. <br>
<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,
<br>
but it would be easy to file it in again as long there is a
compiler
<br>
available. Removing the Compiler will make it impossible to
<br>
make on-site changes and render every useful tool, browser,
debugger etc.pp. useless. I bet it will render the image
useless.
<br>
Maybe you remember the changes you made to the startup-code,
<br>
even in this part there are references to the compiler.
<br>
<br>
The only chance I see here, is to change the VM to make it
<br>
load an encrypted image and password-protect access to
<br>
the browser tools in your UI. Of course if someone gains root
<br>
access to your computer, he/she could easily read the
decrypted
<br>
image from RAM.
<br>
<br>
</blockquote>
</blockquote>
</blockquote>
Or not root, at least on Linux a process running as the same user
can sometimes read all of that memory.<br>
<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.
<br>
<br>
I might be worthwhile to run your application with an
(overlay)
<br>
file-system that supports encryption (encfs for example).
<br>
Again you need to block access to the browsers in your UI.
<br>
<br>
<br>
<blockquote type="cite">
<br>
Let me know what you think. If this is possible it would be
<br>
extremely interesting. If you think is very complex to
achieve I put it
<br>
in the desiderata list, procrastinate, and keep it mind for
the future.
<br>
</blockquote>
I would like to see app distribution with a single file for
Cuis
<br>
applications. That is appending the image to the VM executable
<br>
maybe compressed an encrypted. The big problem here is that
<br>
some plugins can not be compiled as internal plugins
<br>
and some drivers must be shared objects/DLLs. Of course
<br>
the VM could be changed here, but that would mean
<br>
Squeak/VMMaker programming.
<br>
<br>
It is much easier to add modules to Python's
<br>
module loader infrastructure that load encrypted
<br>
modules.
<br>
</blockquote>
</blockquote>
</blockquote>
+1. However, what about the Dynabook vision?<br>
<blockquote type="cite"
cite="mid:99c2f77f-42e4-0b32-b168-9cc0a8d06161@klix.ch">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<br>
<br>
Bye
<br>
Nicola
<br>
</blockquote>
<br>
<br>
HTH and Best Regards,
<br>
<br>
Gerald
<br>
</blockquote>
<br>
Thank you Gerald !
<br>
<br>
Now that you tell me "the compiler is smart" i remembered once
in the past you told me also:
<br>
</blockquote>
Well -- forgive me some nitpicking here -- the compiler is rather
dumb,
<br>
which makes it easy for the decompiler to look smart :=}
<br>
<blockquote type="cite">"you lost the .sources file, I can't see
the variables". And i didn't even notice the difference !
<br>
</blockquote>
Oh yes, I remember that conversation. Now that you mention it,
<br>
AFIR it was our first conversation.
<br>
<blockquote type="cite">Therefore I guess our de-compiler is far
too smart, leaving only the bytecode gives back very readable
code
<br>
as far as i remember. So obfuscation via removing source code is
not a viable option.
<br>
</blockquote>
Yes it is so simple, that even script kiddies can do it.
<br>
<blockquote type="cite">
<br>
Luckily the BBB has on board storage, it is not dependent on the
SDcard. I could sabotage
<br>
the SDcard holder, that seems the fastest dumbest way to keep
the random techie out
<br>
of my data. s/he/it
<br>
</blockquote>
Some hot glue may help. Maybe the SD-Card-Slot can be disabled
<br>
by some means of firmware-configuration. If you want to do
<br>
this properly you should also disable any JTAG-interface.
<br>
<blockquote type="cite">
<br>
Also, very few people know Smalltalk, this is a second level
deterrent. Even if
<br>
they can fix the SDcard slot then they need to be able to read
the code, and
<br>
this would require some time. For this application I don't have
a secret formula
<br>
to hide, I just don't want others to copy/paste easily the whole
application, change 2 colors + 1 label
<br>
and sell it as their own.
<br>
</blockquote>
IC, deter the script kiddies is a sensible goal.
<br>
It will also save time, because you don't need to support/fix
<br>
devices that were hacked by some (not so) educated user.
<br>
</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 <i>all</i> of that could plausibly be for
the Dynabook vision.<br>
<blockquote type="cite"
cite="mid:99c2f77f-42e4-0b32-b168-9cc0a8d06161@klix.ch">
<blockquote type="cite">
<br>
Appimage are cool. I personally don't use them but the concept
is good.
<br>
In the and every time you install something in the Mac or
Windows a huge package
<br>
comes down, in Linux and BSD we are too perfectionist, we try to
get dependencies
<br>
first and then the program we want. That is maybe the right
thing to do, but not
<br>
the practical thing to do, especially today that a 10Tera disk
cost 200euro.
<br>
</blockquote>
AppImages are rather lean, when it comes to dependencies, but
<br>
the dependency-hell starts when you want to build the
AppImage-builder
<br>
by your self.
<br>
I like Google's go-compiler, it produces statically linked
executables,
<br>
that only need a syscall-interface.
<br>
<blockquote type="cite">
<br>
In Linux i guess it is not a big problem to share a Cuis
program. E.g. I would just
<br>
send you a .tar.gz of my cuis-project-xyz directory. But It
would be all in clear, and that
<br>
often is not desirable. For the other systems i don't know.
<br>
</blockquote>
If you stick to ZIP-files the result is fairly portable;
<br>
disregarding the VM executable and the shared objects/DLLs it
needs.
<br>
<br>
An app-store or any other sort of application -- in fact Cuis
image -
<br>
repository would help, if we can find a portable
<br>
and easy way to install the squeak vm and a simple local
<br>
app-store.
<br>
<blockquote type="cite">
<br>
<br>
bye
<br>
Nicola
<br>
<br>
</blockquote>
<br>
Best Regards,
<br>
<br>
Gerald
<br>
</blockquote>
<p>Love (for the Dynabook vision),</p>
<p>Graham<br>
</p>
</body>
</html>