Getting rid of .sources file for deployment

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Getting rid of .sources file for deployment

Esteban A. Maringolo
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/DeployYourPharoApplication.md#sources-obfuscation
[2] Pharo8.0-32bit-0932da8.sources in my case


Esteban A. Maringolo

Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of .sources file for deployment

Stéphane Ducasse
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 <[hidden email]> 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/DeployYourPharoApplication.md#sources-obfuscation
[2] Pharo8.0-32bit-0932da8.sources in my case


Esteban A. Maringolo


--------------------------------------------
Stéphane Ducasse
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

Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of .sources file for deployment

Esteban A. Maringolo
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
<[hidden email]> 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 <[hidden email]> 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/DeployYourPharoApplication.md#sources-obfuscation
> [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
>

Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of .sources file for deployment

Stéphane Ducasse
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
<[hidden email]> 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 <[hidden email]> 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/DeployYourPharoApplication.md#sources-obfuscation
[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
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

Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of .sources file for deployment

Esteban A. Maringolo
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
<[hidden email]> 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
> <[hidden email]> 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 <[hidden email]> 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/DeployYourPharoApplication.md#sources-obfuscation
> [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
>

Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of .sources file for deployment

jan.struz
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.
Save The World!
Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of .sources file for deployment

Trygve
In reply to this post by Esteban A. Maringolo
The .sources file has been optional for as long as I can remember. 
Is it OK for list that somebody breaks this tradition?
Trygve

On 2020-08-29 04:49, Esteban Maringolo 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/DeployYourPharoApplication.md#sources-obfuscation
[2] Pharo8.0-32bit-0932da8.sources in my case


Esteban A. Maringolo


--

The essence of object orientation is that objects collaborate  to achieve a goal.
Trygve Reenskaug      
[hidden email]
Morgedalsvn. 5A       
http://folk.uio.no/trygver/
N-0378 Oslo             
http://fullOO.info
Norway                     Tel: (+47) 468 58 625

Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of .sources file for deployment

jgfoster

On Sep 3, 2020, at 9:49 AM, Trygve Reenskaug <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of .sources file for deployment

Stéphane Ducasse
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, [hidden email] <[hidden email]> wrote:


On Sep 3, 2020, at 9:49 AM, Trygve Reenskaug <[hidden email]> 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
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

Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of .sources file for deployment

Esteban A. Maringolo
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
<[hidden email]> 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, [hidden email] <[hidden email]> wrote:
>
>
> On Sep 3, 2020, at 9:49 AM, Trygve Reenskaug <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of .sources file for deployment

Esteban A. Maringolo
In reply to this post by jan.struz
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 <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of .sources file for deployment

Stéphane Ducasse
In reply to this post by Esteban A. Maringolo
May be a better way would be patch the call to the decompiler and remove it as well some parts of the sources.
Let us know your progress because I’m interested (even this scenario is not part of our focus).
Now even with Java I think that you can decompile code. 


On 4 Sep 2020, at 22:05, Esteban Maringolo <[hidden email]> 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
<[hidden email]> 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, [hidden email] <[hidden email]> wrote:


On Sep 3, 2020, at 9:49 AM, Trygve Reenskaug <[hidden email]> 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
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

Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of .sources file for deployment

Stéphane Ducasse
In reply to this post by Esteban A. Maringolo
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 <[hidden email]> 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
<[hidden email]> 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, [hidden email] <[hidden email]> wrote:


On Sep 3, 2020, at 9:49 AM, Trygve Reenskaug <[hidden email]> 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
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

Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of .sources file for deployment

Esteban A. Maringolo
Stef,

On Sat, Sep 5, 2020 at 12:49 PM Stéphane Ducasse
<[hidden email]> 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/DeployYourPharoApplication.md#sources-obfuscation

Esteban A. Maringolo

Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of .sources file for deployment

Davide Grandi-3
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
> <[hidden email]> 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/DeployYourPharoApplication.md#sources-obfuscation
>
> Esteban A. Maringolo

--
Ing. Davide Grandi
email    : [hidden email]
mobile   : +39 339 7468 778
linkedin : http://linkedin.com/in/davidegrandi


Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of .sources file for deployment

Stéphane Ducasse
In reply to this post by Esteban A. Maringolo
So if you remove the code open the worldmenu and the debugger you should get done. 
After the people could use —eval to open a browser but this is more difficult. 

On 6 Sep 2020, at 15:55, Esteban Maringolo <[hidden email]> wrote:

Stef,

On Sat, Sep 5, 2020 at 12:49 PM Stéphane Ducasse
<[hidden email]> 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/DeployYourPharoApplication.md#sources-obfuscation

Esteban A. Maringolo


--------------------------------------------
Stéphane Ducasse
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

Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of .sources file for deployment

Davide Grandi-3
In reply to this post by Davide Grandi-3
 >any simple obfuscation scheme

any simple _protection_ scheme, except obfuscation.

0.01 E. ...

     Davide Grandi

On 06/09/2020 17:51, Davide Grandi wrote:

> 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
>> <[hidden email]> 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/DeployYourPharoApplication.md#sources-obfuscation
>>
>> Esteban A. Maringolo
>
--
Ing. Davide Grandi
email    : [hidden email]
mobile   : +39 339 7468 778
linkedin : http://linkedin.com/in/davidegrandi


Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of .sources file for deployment

Esteban A. Maringolo
In reply to this post by Davide Grandi-3
On Sun, Sep 6, 2020 at 12:52 PM Davide Grandi <[hidden email]> 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,

Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of .sources file for deployment

Davide Grandi-3
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 <[hidden email]> 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    : [hidden email]
mobile   : +39 339 7468 778
linkedin : http://linkedin.com/in/davidegrandi


Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of .sources file for deployment

Esteban A. Maringolo
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 <[hidden email]> 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 <[hidden email]> 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    : [hidden email]
> mobile   : +39 339 7468 778
> linkedin : http://linkedin.com/in/davidegrandi
>
>

12