Hi Stef, Thanks for the support. I don't know if there is a way to do that for FFI except if you somehow modify the methods during execution to include the arguments in the method itself instead of relying on the source code for reflection. What would help in the meantime is to have a VM that is headless all the time (something like a forced --headless parameter), otherwise it is really easy for somebody to remove the --headless parameter and fire your image and navigate your code with all the power a Smalltalk IDE provides. Is there a way to compile a VM with such an option? (basically a HeadlessPharoConsole.exe). Regards! Esteban A. Maringolo On Sat, Aug 29, 2020 at 2:46 AM Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

Hi

I’m really interested in this. Because we should be able to ship without the sources. FFI needs the source at some point but I guess that this is the first time and that the information could be stored in the compiledMethod. But I do not remember.

Now may be esteban or pablo can give you some hints but frankly we are super super super busy but if you have a way and that Pharo should be changed to support this scenario let us know we will support you.

S

On 29 Aug 2020, at 04:49, Esteban Maringolo <emaringolo@gmail.com> wrote:

Hi,

Is there a way to get rid the .sources file in a deployment scenario?

I followed this guide [1], but I cannot get rid of the .sources files, because I'm using PharoADO (which uses PharoCOM) and it uses some reflection for FFI and for some reason that implies using the .sources file. I installed the FFICompilerPlugin as per the instructions, but I don't have a way to tell whether I did in the right place/moment, nor how to assess its proper installation.

If such [2] .sources file cannot be removed, what is the criteria for the lookup, can it be renamed or modified via some parameter/config?

Thanks!

[1] https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/D... [2] Pharo8.0-32bit-0932da8.sources in my case

Esteban A. Maringolo

-------------------------------------------- Stéphane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France

Hi Stef, That was the first thing I tried, but PharoADO (it is, PharoCOM) needs the source in order to do some of its stuff. But even so, I'd still like to have a VM that is used only for running the image headless, without any GUI (nor IDE). Regards! Esteban A. Maringolo On Mon, Aug 31, 2020 at 10:20 AM Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

If this is for obsfucation why not simply providing an empty source/changes file? And you can remove the decompiler (but then after you will never debug anymore your application).

S

Hi Stef,

Thanks for the support.

I don't know if there is a way to do that for FFI except if you somehow modify the methods during execution to include the arguments in the method itself instead of relying on the source code for reflection.

What would help in the meantime is to have a VM that is headless all the time (something like a forced --headless parameter), otherwise it is really easy for somebody to remove the --headless parameter and fire your image and navigate your code with all the power a Smalltalk IDE provides.

Is there a way to compile a VM with such an option? (basically a HeadlessPharoConsole.exe).

Regards!

Esteban A. Maringolo

On Sat, Aug 29, 2020 at 2:46 AM Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

Hi

I’m really interested in this. Because we should be able to ship without the sources. FFI needs the source at some point but I guess that this is the first time and that the information could be stored in the compiledMethod. But I do not remember.

Now may be esteban or pablo can give you some hints but frankly we are super super super busy but if you have a way and that Pharo should be changed to support this scenario let us know we will support you.

S

On 29 Aug 2020, at 04:49, Esteban Maringolo <emaringolo@gmail.com> wrote:

Hi,

Is there a way to get rid the .sources file in a deployment scenario?

I followed this guide [1], but I cannot get rid of the .sources files, because I'm using PharoADO (which uses PharoCOM) and it uses some reflection for FFI and for some reason that implies using the .sources file. I installed the FFICompilerPlugin as per the instructions, but I don't have a way to tell whether I did in the right place/moment, nor how to assess its proper installation.

If such [2] .sources file cannot be removed, what is the criteria for the lookup, can it be renamed or modified via some parameter/config?

Thanks!

[1] https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/D... [2] Pharo8.0-32bit-0932da8.sources in my case

Esteban A. Maringolo

-------------------------------------------- Stéphane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France

-------------------------------------------- Stéphane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France

Hi Jan, I wasn't aware of such a method, actually it doesn't have many users in the system. I'll do this and check whether this works. Esteban A. Maringolo On Wed, Sep 2, 2020 at 5:19 PM jan.struz <public+pharo@struz.cz> wrote:

Hi Esteban,

you can try this for all methods requiring source code, before removing .sources file:

someCompiledMethod embeddSourceInTrailer.

This works since Pharo 3.0 or so...

Jan

Save The World!

________________________________ Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

On Sep 3, 2020, at 9:49 AM, Trygve Reenskaug <trygver@ifi.uio.no> wrote:

The .sources file has been optional for as long as I can remember. Is it OK for list that somebody breaks this tradition? Trygve

Hi Trygve, I’m not sure what you mean by this question. Are you asking, “Is it acceptable to have code that relies on reflection in order to operate properly?” To this question I would answer “yes” since some things are easier to do using reflection. Or are you asking, “Would it be better to not have FFI at all until it can be implemented without reflection?” To this question I would answer “no” since people that don’t want reflection can choose to forego features that require it. Or are you asking, “Would it be nice if someone could do the work to implement FFI without reflection?” To this question I would answer “yes.” Unfortunately, there is a cost involved. So were you asking one of those questions or something else? James

My compromise would be to disable the GUI version of the VM. How can I compile a VM with the --headless setting hardcoded? Where to start? Esteban A. Maringolo On Fri, Sep 4, 2020 at 2:39 PM Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

Thanks James

This is pretty much the right questions :) And I would love to have money to solve the problems the way I would like but life is a compromise.

S

On 3 Sep 2020, at 20:50, Smalltalk@jgfoster.net <Smalltalk@JGFoster.net> wrote:

On Sep 3, 2020, at 9:49 AM, Trygve Reenskaug <trygver@ifi.uio.no> wrote:

The .sources file has been optional for as long as I can remember. Is it OK for list that somebody breaks this tradition? Trygve

Hi Trygve,

I’m not sure what you mean by this question.

Are you asking, “Is it acceptable to have code that relies on reflection in order to operate properly?” To this question I would answer “yes” since some things are easier to do using reflection.

Or are you asking, “Would it be better to not have FFI at all until it can be implemented without reflection?” To this question I would answer “no” since people that don’t want reflection can choose to forego features that require it.

Or are you asking, “Would it be nice if someone could do the work to implement FFI without reflection?” To this question I would answer “yes.” Unfortunately, there is a cost involved.

So were you asking one of those questions or something else?

James

-------------------------------------------- Stéphane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France

just a question what if a bad guy you want to protect from is just smart and use a default vm. I mean what kind of thieves do you want to protect from? Because you can let everything and block the menu + the DNU and other exception and nobody even you will be able to access the code. If you remove all the <world menu> menu and toolbar + DNU + exception ... S.

On 4 Sep 2020, at 22:05, Esteban Maringolo <emaringolo@gmail.com> wrote:

My compromise would be to disable the GUI version of the VM.

How can I compile a VM with the --headless setting hardcoded? Where to start?

Esteban A. Maringolo

On Fri, Sep 4, 2020 at 2:39 PM Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

Thanks James

This is pretty much the right questions :) And I would love to have money to solve the problems the way I would like but life is a compromise.

S

On 3 Sep 2020, at 20:50, Smalltalk@jgfoster.net <Smalltalk@JGFoster.net> wrote:

On Sep 3, 2020, at 9:49 AM, Trygve Reenskaug <trygver@ifi.uio.no> wrote:

The .sources file has been optional for as long as I can remember. Is it OK for list that somebody breaks this tradition? Trygve

Hi Trygve,

I’m not sure what you mean by this question.

Are you asking, “Is it acceptable to have code that relies on reflection in order to operate properly?” To this question I would answer “yes” since some things are easier to do using reflection.

Or are you asking, “Would it be better to not have FFI at all until it can be implemented without reflection?” To this question I would answer “no” since people that don’t want reflection can choose to forego features that require it.

Or are you asking, “Would it be nice if someone could do the work to implement FFI without reflection?” To this question I would answer “yes.” Unfortunately, there is a cost involved.

So were you asking one of those questions or something else?

James

-------------------------------------------- Stéphane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France

-------------------------------------------- Stéphane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France

Does "competition" has SmalltalkEmulator ? A Smalltalk-written VM will defeat any simple obfuscation scheme. 0.02 E.     Davide Grandi On 06/09/2020 15:55, Esteban Maringolo wrote:

Stef,

On Sat, Sep 5, 2020 at 12:49 PM Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

just a question what if a bad guy you want to protect from is just smart and use a default vm. You're talking about decompiling and I'm talking about not making it trivial to see the code, internals and other things. Security is always what you can afford to protect form, with enough resources anybody can crack most of the existing software.

...

I mean what kind of thieves do you want to protect from? Think of it this way... as it is is like saving a six digits password in plaintext on a file, what I propose is to have the same file, but with the password encrypted with a lousy crypto (still easy to crack with a dictionary attack but not as easy as seeing it at plain sight).

I'm not trying to protect from thieves, but from the competition. This client part of the software runs in a computer where there is also the software it's going to replace (eventually).

I simply want to obfuscate a little so it's not trivial to open it. I'm not asking about encrypted image files. :-)

...

Because you can let everything and block the menu + the DNU and other exception and nobody even you will be able to access the code. If you remove all the <world menu> menu and toolbar + DNU + exception ... I followed most of the guidelines to deploy it obfuscated [1]. But if there is a guide for obfuscation, it means that there is some need for it, I just want to go one extra step.

Thanks!

[1] https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/D...

Esteban A. Maringolo

-- Ing. Davide Grandi email : davide.grandi@email.it mobile : +39 339 7468 778 linkedin : http://linkedin.com/in/davidegrandi

On Sun, Sep 6, 2020 at 12:52 PM Davide Grandi <davide.grandi@email.it> wrote:

Does "competition" has SmalltalkEmulator ? A Smalltalk-written VM will defeat any simple obfuscation scheme.

Sorry, but I don't understand what you mean. Best regards,

If somebody gets to open the image and loads it with an Smalltalk Emulator to execute it I'll ask him/her to start working together, and even teach me how to do it. I don't want to shield the image from being accessed, just want to make it harder than simply removing the '--headless' parameter to the VM executable. Of course removing sources is a plus (I do for a VW deployed image), but even for this particular piece of software that I'm asking for, I don't need it. If I wanted to make the source public, I'll publish it in Github/Gitlab, otherwise I'd rather keep the code private. Regards, Esteban A. Maringolo On Sun, Sep 6, 2020 at 6:29 PM Davide Grandi <davide.grandi@email.it> wrote:

I mean that with SmalltalkEmulator, the Smalltalk interpreter written in Smalltalk, one can execute an image looking at classes, methods and maybe executing code at will.

And the only practical form of protection I see in Squeak/Pharo is to obfuscate code.

Maybe I'm wrong.

Davide Grandi

On 06/09/2020 22:27, Esteban Maringolo wrote:

...

On Sun, Sep 6, 2020 at 12:52 PM Davide Grandi <davide.grandi@email.it> wrote:

...

Does "competition" has SmalltalkEmulator ? A Smalltalk-written VM will defeat any simple obfuscation scheme. Sorry, but I don't understand what you mean.

Best regards,

-- Ing. Davide Grandi email : davide.grandi@email.it mobile : +39 339 7468 778 linkedin : http://linkedin.com/in/davidegrandi

Hi Davide, Thanks for the thorough response, but I think you're over dimensioning, and to some extent missing, my initial purpose and intention. I don't want to protect from somebody attempting to reverse engineer my application, that's impossible (more so given your references). I simply want to disable the option to open the IDE, even with all tool menus disabled. In Java if I deliver a .jar or .war anybody could reverse engineer it, but launching it won't open the development environment. For comparison with other Smalltalks I've used: * VisualWorks enables the distribution of a "headless" IMAGE (and parcels) without sources, if you revert that image to be headful all source code will be decompiled using meaningless variables. * Dolphin has the concept of SessionManager that is the entry point to the image startup, if you save your image with a Headless Session manager, then no GUI loop will start, same thing if you deploy as a COM component. * VAST produces its own ICX file where you can choose what to include in it, it's not simply saving the image but building a new one from within the development image, it's one step further. * VSE had the SLL (similar to DLLs), if you don't bind the IDE's SLLs then there is no way to start the IDE (I never built a headless VSE app though). So what I'd like is an always Pharo headless image or Pharo headless vm, instead of being controlled by a parameter in the VM. Regards, Esteban A. Maringolo On Mon, Sep 7, 2020 at 12:04 PM Davide Grandi <davide.grandi@email.it> wrote:

Ok, I'll give you a result, meanwhile fixing some imprecisions.

The "class" is CogVmSimulator but it's use is very far from my knowlegde, I recalled having seen a picture of Pharo-in-Pharo (or Squeak-in-Squeak) running under this simulator. It lives near the Cog side (or the OpenVM side) of Squeak/Pharo (If I'm not wrong Squeak ran into an emulator, before walking on his legs-his VM).

There are many of these simulator, for other Smalltalk : - Hobbes and others for Xerox (thanks to files of Mario Molczko and/or Bitsavers - Dan Ingalls Apda Smalltalk + old Smalltalk -72 /-76 and maybe others I don't yet know about

The reason is quite simple : the object memory is written to disk and the spec of executing Smalltalk are known either from the books or by the source.

The root is Xerox's SystemTracer, a class that wrote a running image to disk, optionally changing object format (see the Green Book).

So : - if you can read the image - you can run into a simulator - or decode it without to much effort (5 emulators for Xerox V2 image, so far). (try to open an image with a text editor : intriguing !)

I don't know how Cincom or Instantiations protect the released st code, but for Pharo and Squeak this is not a point : they are all open.

So, as if you wanna "protect" names and methods of a running image ... ... you have to (IMHO) : - encrypt executable and image (and modify the VM) - or obfuscate your classes and methods renaming it to C1, C2, ..., m1:p1:p2: and so on (keeping a map for debugging)

Sorry to be imprecise about names and locations apart from suggest to see 4 emulators 4 running in a squeak image running ... in javascript in your browser (so total is 5) at : https://smalltalkzoo.thechm.org/HOPL-Squeak.html?earlyst80 (thanks to Vanessa Freudemberg & Dan Ingalls).

Sorry again & best regards,

Davide Grandi

On 06/09/2020 23:51, Esteban Maringolo wrote:

...

If somebody gets to open the image and loads it with an Smalltalk Emulator to execute it I'll ask him/her to start working together, and even teach me how to do it.

I don't want to shield the image from being accessed, just want to make it harder than simply removing the '--headless' parameter to the VM executable. Of course removing sources is a plus (I do for a VW deployed image), but even for this particular piece of software that I'm asking for, I don't need it.

If I wanted to make the source public, I'll publish it in Github/Gitlab, otherwise I'd rather keep the code private.

Regards,

Esteban A. Maringolo

On Sun, Sep 6, 2020 at 6:29 PM Davide Grandi <davide.grandi@email.it> wrote:

...

I mean that with SmalltalkEmulator, the Smalltalk interpreter written in Smalltalk, one can execute an image looking at classes, methods and maybe executing code at will.

And the only practical form of protection I see in Squeak/Pharo is to obfuscate code.

Maybe I'm wrong.

Davide Grandi

On 06/09/2020 22:27, Esteban Maringolo wrote:

...

On Sun, Sep 6, 2020 at 12:52 PM Davide Grandi <davide.grandi@email.it> wrote:

...

Does "competition" has SmalltalkEmulator ? A Smalltalk-written VM will defeat any simple obfuscation scheme. Sorry, but I don't understand what you mean.

Best regards, -- Ing. Davide Grandi email : davide.grandi@email.it mobile : +39 339 7468 778 linkedin : http://linkedin.com/in/davidegrandi

-- Ing. Davide Grandi email : davide.grandi@email.it mobile : +39 339 7468 778 linkedin : http://linkedin.com/in/davidegrandi

Hi Stef, I don't know what's the demand for such a feature. In the Windows and Desktop era it might have been very important, but I don't see that kind of integration these days, when most system integrations happen at the HTTP level. For my particular case I don't need a DLL. Regards! Esteban A. Maringolo On Mon, Sep 7, 2020 at 1:55 PM Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

I would like also to be able to deploy a pharo app as a dll juts time and money.

S.

On 7 Sep 2020, at 17:28, Esteban Maringolo <emaringolo@gmail.com> wrote:

Hi Davide,

Thanks for the thorough response, but I think you're over dimensioning, and to some extent missing, my initial purpose and intention.

I don't want to protect from somebody attempting to reverse engineer my application, that's impossible (more so given your references). I simply want to disable the option to open the IDE, even with all tool menus disabled.

In Java if I deliver a .jar or .war anybody could reverse engineer it, but launching it won't open the development environment.

For comparison with other Smalltalks I've used: * VisualWorks enables the distribution of a "headless" IMAGE (and parcels) without sources, if you revert that image to be headful all source code will be decompiled using meaningless variables. * Dolphin has the concept of SessionManager that is the entry point to the image startup, if you save your image with a Headless Session manager, then no GUI loop will start, same thing if you deploy as a COM component. * VAST produces its own ICX file where you can choose what to include in it, it's not simply saving the image but building a new one from within the development image, it's one step further. * VSE had the SLL (similar to DLLs), if you don't bind the IDE's SLLs then there is no way to start the IDE (I never built a headless VSE app though).

So what I'd like is an always Pharo headless image or Pharo headless vm, instead of being controlled by a parameter in the VM.

Regards,

Esteban A. Maringolo

On Mon, Sep 7, 2020 at 12:04 PM Davide Grandi <davide.grandi@email.it> wrote:

Ok, I'll give you a result, meanwhile fixing some imprecisions.

The "class" is CogVmSimulator but it's use is very far from my knowlegde, I recalled having seen a picture of Pharo-in-Pharo (or Squeak-in-Squeak) running under this simulator. It lives near the Cog side (or the OpenVM side) of Squeak/Pharo (If I'm not wrong Squeak ran into an emulator, before walking on his legs-his VM).

There are many of these simulator, for other Smalltalk : - Hobbes and others for Xerox (thanks to files of Mario Molczko and/or Bitsavers - Dan Ingalls Apda Smalltalk + old Smalltalk -72 /-76 and maybe others I don't yet know about

The reason is quite simple : the object memory is written to disk and the spec of executing Smalltalk are known either from the books or by the source.

The root is Xerox's SystemTracer, a class that wrote a running image to disk, optionally changing object format (see the Green Book).

So : - if you can read the image - you can run into a simulator - or decode it without to much effort (5 emulators for Xerox V2 image, so far). (try to open an image with a text editor : intriguing !)

I don't know how Cincom or Instantiations protect the released st code, but for Pharo and Squeak this is not a point : they are all open.

So, as if you wanna "protect" names and methods of a running image ... ... you have to (IMHO) : - encrypt executable and image (and modify the VM) - or obfuscate your classes and methods renaming it to C1, C2, ..., m1:p1:p2: and so on (keeping a map for debugging)

Sorry to be imprecise about names and locations apart from suggest to see 4 emulators 4 running in a squeak image running ... in javascript in your browser (so total is 5) at : https://smalltalkzoo.thechm.org/HOPL-Squeak.html?earlyst80 (thanks to Vanessa Freudemberg & Dan Ingalls).

Sorry again & best regards,

Davide Grandi

On 06/09/2020 23:51, Esteban Maringolo wrote:

If somebody gets to open the image and loads it with an Smalltalk Emulator to execute it I'll ask him/her to start working together, and even teach me how to do it.

I don't want to shield the image from being accessed, just want to make it harder than simply removing the '--headless' parameter to the VM executable. Of course removing sources is a plus (I do for a VW deployed image), but even for this particular piece of software that I'm asking for, I don't need it.

If I wanted to make the source public, I'll publish it in Github/Gitlab, otherwise I'd rather keep the code private.

Regards,

Esteban A. Maringolo

On Sun, Sep 6, 2020 at 6:29 PM Davide Grandi <davide.grandi@email.it> wrote:

I mean that with SmalltalkEmulator, the Smalltalk interpreter written in Smalltalk, one can execute an image looking at classes, methods and maybe executing code at will.

And the only practical form of protection I see in Squeak/Pharo is to obfuscate code.

Maybe I'm wrong.

Davide Grandi

On 06/09/2020 22:27, Esteban Maringolo wrote:

On Sun, Sep 6, 2020 at 12:52 PM Davide Grandi <davide.grandi@email.it> wrote:

Does "competition" has SmalltalkEmulator ? A Smalltalk-written VM will defeat any simple obfuscation scheme.

Sorry, but I don't understand what you mean.

Best regards,

-- Ing. Davide Grandi email : davide.grandi@email.it mobile : +39 339 7468 778 linkedin : http://linkedin.com/in/davidegrandi

-- Ing. Davide Grandi email : davide.grandi@email.it mobile : +39 339 7468 778 linkedin : http://linkedin.com/in/davidegrandi

-------------------------------------------- Stéphane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France