I will have a Squeak app that uses Seaside. It will not be offered hosted,
but users will get a copy of it in some form to install and use. Starting with my working Squeak image, what options do I have to: - make the source code hidden (byte-code level stuff is fine) - optionally: offer it to them as a single Windows executable Thanks! Sophie _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
>>>>> "itsme213" == itsme213 <[hidden email]> writes:
itsme213> - make the source code hidden (byte-code level stuff is fine) You'll need to protect your code using legal means, not technical means. Byte code is deliberately easy to decompile. After all, the debugger has to do that to work. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Sophie424
FAQ: Distributing Squeak Programs
http://wiki.squeak.org/squeak/3563 Omitting the source is easy, don't distribute the .sources and .changes. But, someone with Squeak can get at your "bytecode" and look at it in a code browser. The variable names all get dropped, as do the comments, but the code is easy to read. You can preview this by removing your .sources and .changes file. Back when Smalltalk was more commercially successful, you'd see ads for Smalltalk obfuscators. I haven't seen such a thing for Squeak. On Dec 1, 2007 11:32 PM, itsme213 <[hidden email]> wrote: > I will have a Squeak app that uses Seaside. It will not be offered hosted, > but users will get a copy of it in some form to install and use. > > Starting with my working Squeak image, what options do I have to: > - make the source code hidden (byte-code level stuff is fine) > - optionally: offer it to them as a single Windows executable > > Thanks! > > Sophie > > > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
But if you strip out the right development tool stuff when you package your
app that can make it very hard for people to look at the decompiled bytecode. Remove inspectors, browsers, the decompiler, etc. and also make sure that no Smalltalk code can be filed in so that the tools can't be added back in. You should be okay in theory against most would be hackers. The only way to examine the application then would be to have some sort of image file browsing tool. -Carl Gundel, author of Liberty BASIC http://www.libertybasic.com From: "David Mitchell" <[hidden email]> > FAQ: Distributing Squeak Programs > http://wiki.squeak.org/squeak/3563 > > Omitting the source is easy, don't distribute the .sources and > .changes. But, someone with Squeak can get at your "bytecode" and look > at it in a code browser. The variable names all get dropped, as do the > comments, but the code is easy to read. > > You can preview this by removing your .sources and .changes file. > > Back when Smalltalk was more commercially successful, you'd see ads > for Smalltalk obfuscators. I haven't seen such a thing for Squeak. > > On Dec 1, 2007 11:32 PM, itsme213 <[hidden email]> wrote: >> I will have a Squeak app that uses Seaside. It will not be offered >> hosted, >> but users will get a copy of it in some form to install and use. >> >> Starting with my working Squeak image, what options do I have to: >> - make the source code hidden (byte-code level stuff is fine) >> - optionally: offer it to them as a single Windows executable >> >> Thanks! >> >> Sophie >> >> >> >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
>>>>> "Carl" == Carl Gundel <[hidden email]> writes:
Carl> The only way to examine the application then would be to have some sort Carl> of image file browsing tool. Just like the one provided in the VMMaker package? :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
On 3-Dec-07, at 7:38 PM, Randal L. Schwartz wrote: >>>>>> "Carl" == Carl Gundel <[hidden email]> writes: > > Carl> The only way to examine the application then would be to have > some sort > Carl> of image file browsing tool. > > Just like the one provided in the VMMaker package? :) Err.... I'm not aware of one! tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Cackles a lot, but I ain't seen no eggs yet. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
>>>>> "tim" == tim Rowledge <[hidden email]> writes:
Carl> The only way to examine the application then would be to have some >> sort Carl> of image file browsing tool. >> >> Just like the one provided in the VMMaker package? :) tim> Err.... I'm not aware of one! You mean InterpreterSimulator new openOn: Smalltalk imageName doesn't create an image browsing tool? That seems to be part of the VMMaker package. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Carl Gundel
"Carl Gundel" <[hidden email]> wrote
> But if you strip out the right development tool stuff when you package > your app that can make it very hard for people to look at the decompiled > bytecode. Remove inspectors, browsers, the decompiler, etc. and also make > sure that no Smalltalk code can be filed in so that the tools can't be > added back in. You should be okay in theory against most would be > hackers. The only way to examine the application then would be to have > some sort of image file browsing tool. That could be adequate for my needs (I'm sure a determined hacker can get past, that's fine). Is removing these tools as simple as removing their classes before saving the image? And any way to reduce things to a single executable, one that either launched the right image with the right VM, or (preferably) included the right image and VM internally in some way? p.s. Since this would be a web app, I would most likely want users to run it headless (don't know how yet). Sophie _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Randal L. Schwartz
On 04/12/2007, Randal L. Schwartz <[hidden email]> wrote:
> >>>>> "tim" == tim Rowledge <[hidden email]> writes: > > Carl> The only way to examine the application then would be to have some > >> sort > Carl> of image file browsing tool. > >> > >> Just like the one provided in the VMMaker package? :) > > tim> Err.... I'm not aware of one! > > You mean > > InterpreterSimulator new openOn: Smalltalk imageName > > doesn't create an image browsing tool? That seems to be part > of the VMMaker package. > And for this, i think, the best way is to create own, proprietary VM with own bytecode e.t.c. e.t.c. :) Which raises another question: does the result(hidden source) worth efforts? > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> > Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. > See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
On 3-Dec-07, at 8:43 PM, Igor Stasenko wrote: > On 04/12/2007, Randal L. Schwartz <[hidden email]> wrote: >>>>>>> "tim" == tim Rowledge <[hidden email]> writes: >> >> Carl> The only way to examine the application then would be to >> have some >>>> sort >> Carl> of image file browsing tool. >>>> >>>> Just like the one provided in the VMMaker package? :) >> >> tim> Err.... I'm not aware of one! >> >> You mean >> >> InterpreterSimulator new openOn: Smalltalk imageName >> >> doesn't create an image browsing tool? That seems to be part >> of the VMMaker package. >> > Yes. Well I suppose in one way that is an image browsing tool; it is awful slow as a way of stealing code though. A bit like spelunking machine code to steal MS BASIC off an Altair. > > And for this, i think, the best way is to create own, proprietary VM > with own bytecode e.t.c. e.t.c. :) .. and rewriting the compiler to produce those alternative bytecodes. And debugging the whole thing so you can trust it. > > Which raises another question: does the result(hidden source) worth > efforts? If you really truly consider the cost of someone stealing your code to be say $100M then it might just be worth it. Otherwise, nah. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Low on thinking gas. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
On 12/3/07 11:57 PM, "tim Rowledge" <[hidden email]> wrote:
> A bit like spelunking machine > code to steal MS BASIC off an Altair. I think that's the funniest thing I've heard/read all day. Chris _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
On 3-Dec-07, at 9:20 PM, Chris Cunnington wrote: > On 12/3/07 11:57 PM, "tim Rowledge" <[hidden email]> wrote: > >> A bit like spelunking machine >> code to steal MS BASIC off an Altair. > > > I think that's the funniest thing I've heard/read all day. Then my day has been worthwhile :-) tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Hex dump: Where witches put used curses... _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Randal L. Schwartz
2007/12/3, Randal L. Schwartz <[hidden email]>:
> >>>>> "itsme213" == itsme213 <[hidden email]> writes: > > itsme213> - make the source code hidden (byte-code level stuff is fine) > > You'll need to protect your code using legal means, not technical means. Byte > code is deliberately easy to decompile. After all, the debugger has to do > that to work. The debugger/decompiler is not perfect, there are byte code sequences he can not decompile. You'd need a special compiler that adds these as unreachable code. Cheers Philippe > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> > Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. > See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Randal L. Schwartz
> You mean
> > InterpreterSimulator new openOn: Smalltalk imageName > > doesn't create an image browsing tool? That seems to be part > of the VMMaker package. I remember to create a little tool called ImageBrowser: http://map1.squeakfoundation.org/package/92e8f376-ba20-4c38-8b3a-abfb2bf24624 It loads an image with InterpreterSimulator, and looks at all classes in the loaded image, access the method dictionaries and CompiledMethods. From a CompiledMethod, it gets the source pointer and fetches the method source from the .changes file. One could modify it to decompile the compiled method with literals in the other image. -- Yoshiki _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Sophie424
On Dec 4, 2007, at 5:41 , itsme213 wrote: > "Carl Gundel" <[hidden email]> wrote >> But if you strip out the right development tool stuff when you >> package >> your app that can make it very hard for people to look at the >> decompiled >> bytecode. Remove inspectors, browsers, the decompiler, etc. and >> also make >> sure that no Smalltalk code can be filed in so that the tools >> can't be >> added back in. You should be okay in theory against most would be >> hackers. The only way to examine the application then would be to >> have >> some sort of image file browsing tool. > > That could be adequate for my needs (I'm sure a determined hacker > can get > past, that's fine). Is removing these tools as simple as removing > their > classes before saving the image? And any way to reduce things to a > single > executable, one that either launched the right image with the right > VM, or > (preferably) included the right image and VM internally in some way? It is possible, but takes some (probably a lot of) effort. And why would that be worth it? Which other web programming framework comes in one file? Why should Seaside? > p.s. Since this would be a web app, I would most likely want users > to run it > headless (don't know how yet). Depends on your target platform. - Bert - _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |