[Newbies] Squeak in commercial projects

[Ron Teitelbaum]

Hey Bert,

Ohh that is too cool!  It makes perfect sense too.  I wonder if we shouldn't
build a package for that in cryptography.  I'll have to play with it.  It
could be fun too because we could use a key and the name to hash the
selector.

Still I suppose that not knowing the name of the selector doesn't prevent
you from stepping through the code.  It may be harder to read but it is
still readable.  It's like reading the decompiled code of VW with all the
A1's.  But it is at least one more step toward protecting code.

How hard would it be to add a decrypt algorithm to the VM so that we could
mangle and encrypt the selectors and ivars?  It would be neat if we could
have the vm take the selector and/or code, decrypt it, then verify a hmac on
the method, before calling it.

Great tip Bert, you are terrific!!

Ron Teitelbaum

> -----Original Message-----
> From: beginners-bounces at lists.squeakfoundation.org [mailto:beginners-
> bounces at lists.squeakfoundation.org] On Behalf Of Bert Freudenberg
> Sent: Wednesday, March 07, 2007 1:29 PM
> To: A friendly place to get answers to even the most basic questions
> aboutSqueak.
> Subject: Re: [Newbies] Squeak in commercial projects
> 
> Well, it's basically just
> 
> 	#myFirst:secret:selector: become: #a:a:a:
> 
> and then rehash the method dictionaries where it was used and class
> Symbol. The VM does not care, it only looks at identity.
> 
> - Bert -
> 
> On Mar 7, 2007, at 17:11 , Ron Teitelbaum wrote:
> 
> > Hey Bert,
> >
> > This sounds pretty interesting, can you share more about how to mangle
> > names.  Does it require a change in the VM to de-mangle?
> >
> > Ron Teitelbaum
> >
> >> From: Bert Freudenberg
> >>
> >> On Mar 7, 2007, at 8:57 , goran at krampe.se wrote:
> >>
> >>> Hi!
> >>>
> >>> Just a note - decompiling from bytecodes is very easy in Squeak. The
> >>> only thing missing is the original indentation and any comments. But
> >>> everything else is there. Just so you know.
> >>
> >> Well, if you're really concerned about decompiling, just mangle the
> >> selectors. As long as you are not constructing Symbols at runtime
> >> (#asSymbol, #intern:) this works perfectly well. Same for class names
> >> and instance variable names.
> >>
> >>> Locking down the image is of course doable - so that you can't
> >>> easily
> >>> get to the tools etc - but there are of course ways to go around
> >>> that
> >>> too. For example, I guess you can use an image file analyzer
> >>> (there is
> >>> at least one I think) or hack a VM to do stuff when the image is
> >>> loaded.
> >>
> >> Sure. But if the names are mangled this is about as much fun as
> >> reverse engineering machine code. No wait, the tool support is still
> >> better ;)
> >>
> >>>> But doesn't this imply that the source is downloaded, making it
> >>>> easy
> >>>> (easier) to hack the system? I could make the private Monticello
> >>>> connection secure, update the system and then delete the source...
> >>>> just
> >>>> thinking out loud.
> >>>
> >>> Yes - a Monticello package is just a zip file of source code. Sure,
> >>> you
> >>> can make the transfer "secure" using SSL or whatever - and you can
> >>> apply
> >>> it and throw it away
> >>
> >> Well, you certainly would want to encrypt and sign the patch. If you
> >> are *that* paranoid I'd not even use MC but just image segments.
> >>
> >> It's all a question of cost/value. I for one would be more concerned
> >> about preventing malicious code injection than the possibility of
> >> reverse engineering. But you have to weigh that yourself.
> 
> 
> 
> 
> _______________________________________________
> Beginners mailing list
> Beginners at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/beginners