| Author |
Message |
|
| Guest |
 Posted: Wed Sep 05, 2007 9:21 pm |
 |
|
|
Guest
|
Why can't you do that with a multi-file application?
Good point. |
|
|
| Back to top |
|
| mcampbell |
| Posted: Wed Sep 05, 2007 11:19 pm |
|
|
|
User
Joined: 21 Aug 2007
Posts: 23
Location: Suburb of Atlanta, GA
|
On 9/5/07, Benjamin Tolputt <bjt@pmp.com.au> wrote:
> I would agree that there seems to be some confusion in the discussion.
> On the other hand, being able to create a single executable (with
> perhaps one or two other files for the related beam archives) is where I
> am coming from.
>
> As I mentioned in an earlier email, the standard in game deployment is a
> single executable, with whatever necessary DLL's required (as few as
> possible), and a small number of (generally large) archive files for the
> game resources (everything from scripts & byte-code to image, models, &
> sound files).
What kid of games are you talking about? I'll admit, I'm probably
using as bad an anti-example as I can come up with, but a recent
MMORPG clocks in at 6709 files. Probably 20 of those are for a custom
UI I've installed.
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
    
|
| vladdu |
| Posted: Thu Sep 06, 2007 6:39 am |
|
|
|
User
Joined: 28 Feb 2005
Posts: 397
Location: Gothenburg, Sweden
|
Hi,
On 9/6/07, Benjamin Tolputt <bjt@pmp.com.au (bjt@pmp.com.au)> wrote:Quote: The primary reason I suggested having the beam files "compiled into" the
executable is that the game publishing industry is quite strict about
having copyright protection mechanisms embedded into the deployment. I
am recommending Erlang as the "primary" development language rather than
just the "scripting" language (as this would make best use of Erlang's
superior concurrency) and, as such, being able to protect (if only
marginally) the beam files that actually relate to how Erlang loads
modules, executes, etc (i.e. the kernel, stdlib, etc) is somoewhat of a
commercial (as opposed to "technical") necessity.
Why would beam files more securely protected if packed in a zip archive as compared to unpacked in a directory?
There is already a mechanism to encrypt the debug_info data that might be included in the beam files. I suppose it would be relatively easy to do the same with the actual beam code and decrypt at load time.
best regards,
Vlad
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Sep 06, 2007 6:57 am |
|
|
|
Guest
|
Vlad Dumitrescu wrote:
> Why would beam files more securely protected if packed in a zip
> archive as compared to unpacked in a directory?
It is not so much "securing" the beam files from people as to stop them
"replacing" the beam files easily. In an encrypted zip (or better yet,
appended to a protected executable) the "core" beam files used at the
"low level" of Erlang can be protected from "easy" replacement by casual
users.
Everyone in game development realizes that it is impossible to
completely protect a product from hacking, but it is a commercial
necessity (coming from the publishers) that one include SOME form of
copyright protection mechanism. By adding a "standard" EXE protection
mechanism to the Erlang VM executable and including the "core" Erlang
beam files (i.e. kernel, stdlib, etc) in the exe file - we get enough
"protection coverage" to make the publishers happy.
For me, there is also the added bonus of simple "single file" deployment
but I don't have to deal with third-parties in order to deploy (and so
it is not a necessity for me).
> There is already a mechanism to encrypt the debug_info data that might
> be included in the beam files. I suppose it would be relatively easy
> to do the same with the actual beam code and decrypt at load time.
This is talking about something completely different. I am not
particularly worried about the byte-code being readable. It is more
about making it hard for them to be changed (which I realize is somewhat
the opposite of an Erlang advantage we all like).
Regards,
B.J.Tolputt
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| vladdu |
| Posted: Thu Sep 06, 2007 7:19 am |
|
|
|
User
Joined: 28 Feb 2005
Posts: 397
Location: Gothenburg, Sweden
|
Hi,
On 9/6/07, Benjamin Tolputt <bjt@pmp.com.au (bjt@pmp.com.au)> wrote:Quote: Vlad Dumitrescu wrote:
> Why would beam files more securely protected if packed in a zip
> archive as compared to unpacked in a directory?
It is not so much "securing" the beam files from people as to stop them
"replacing" the beam files easily. In an encrypted zip (or better yet,
appended to a protected executable) the "core" beam files used at the
"low level" of Erlang can be protected from "easy" replacement by casual
users.
> There is already a mechanism to encrypt the debug_info data that might
> be included in the beam files. I suppose it would be relatively easy
> to do the same with the actual beam code and decrypt at load time.
This is talking about something completely different. I am not
particularly worried about the byte-code being readable. It is more
about making it hard for them to be changed (which I realize is somewhat
the opposite of an Erlang advantage we all like).
Erm, if the byte-code is encrypted, how would you replace a beam file with a different one without breaking the encryption?
If the encryption is broken, then it feels about just as easy to replace a file in the file system or in a zip archive.
One could also use separate schemes to ensure it's difficult to tamper with data, like for example storing the MD5 signature of files somewhere.
regards,
Vlad
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Fri Sep 07, 2007 10:24 am |
|
|
|
Guest
|
Vlad Dumitrescu wrote:
> Erm, if the byte-code is encrypted, how would you replace a beam file
> with a different one without breaking the encryption?
You wouldn't. Like most "single player" games, you would simply "patch"
the archive containing the beam files "as a whole" (i.e. as a binary
patch to the archive file rather than individual patches to the files
contained therein).
> If the encryption is broken, then it feels about just as easy to
> replace a file in the file system or in a zip archive.
>
> One could also use separate schemes to ensure it's difficult to tamper
> with data, like for example storing the MD5 signature of files somewhere.
I think the actual problem here is being misunderstood (i.e. I am not
explaining it well enough). We know that DRM (which is what client-side
encryption amounts to) is not "true" protection. It is, however, a
necessity to get a deal through the established game publishing firms.
The fact that it ties into one of my desired features is (believe it or
not) a coincidence in this situation. Erlang as a game development
language came out of a discussion based around Tim Sweeney's
presentation on multi-core enabled game engines (funnily enough, not
simply a plug for the new Unreal Engine). Being a "high concurrency"
language/virtual machine with SMP support now on most platforms - I
thought Erlang was a perfect fit. The problems did not come up from the
language itself (as functional languages such as Lisp have already been
used successfully in console games) but from the actual deployment
features of Erlang (which was designed for easy, hot-swappable upgrading).
In summary, we KNOW DRM (i.e. "client side" encryption & single archive
deployments) are not the best (or even a completely successful) method
of protecting the application from unauthorized copying/changing. It,
however, is necessary to get the publishing deals for PC games (the
target market).
Regards,
B.J.Tolputt
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| vladdu |
| Posted: Fri Sep 07, 2007 10:35 am |
|
|
|
User
Joined: 28 Feb 2005
Posts: 397
Location: Gothenburg, Sweden
|
Hi,
The explanation this time is clearer, thanks.
On 9/7/07, Benjamin Tolputt <bjt@pmp.com.au (bjt@pmp.com.au)> wrote: Quote: Vlad Dumitrescu wrote:
> Erm, if the byte-code is encrypted, how would you replace a beam file
> with a different one without breaking the encryption?
You wouldn't. Like most "single player" games, you would simply "patch"
the archive containing the beam files "as a whole" ( i.e. as a binary
patch to the archive file rather than individual patches to the files
contained therein).
I'm not sure where the misunderstanding lies. Here's how I understand this:
You say some kind of DRM is necessary in order to get a deal. Sure, that's agreed.
You say it's easier/safer to put all beam files in an archive and protect it, as compared to protect each beam file. I may be wrong, but I think there's no difference. If the code loader is extended so that it can load from an encrypted archive, then it can just as easily load from separately encrypted beam files. A cracker can do something about it if it cracks the encryption, and in that case both alternatives are just as easy to tamper with. Without the encryption key, a modified beam file would useless in both cases.
What am I missing? What is a packaging into a smaller set of files adding to the security level?
regards,
Vlad
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Fri Sep 07, 2007 3:23 pm |
|
|
|
Guest
|
Benjamin Tolputt wrote:
> Vlad Dumitrescu wrote:
>> Erm, if the byte-code is encrypted, how would you replace a beam file
>> with a different one without breaking the encryption?
>
> You wouldn't. Like most "single player" games, you would simply "patch"
> the archive containing the beam files "as a whole" (i.e. as a binary
> patch to the archive file rather than individual patches to the files
> contained therein).
I think you missed Vlad's point: it is the encryption, alone, that puts
obstacles in the way of "unauthorized" changes. Whether the files are
stored in a single archive or separately has nothing to do with it.
> In summary, we KNOW DRM (i.e. "client side" encryption & single archive
> deployments) are not the best (or even a completely successful) method
> of protecting the application from unauthorized copying/changing.
Any generic support for copy protection in the VM could easily be
*generically* bypassed, for all applications that used it. If you want
to obtain security through obscurity, it has to be done for each
application independently, otherwise it is not "obscure" in the sense
required. So, why are you asking for this as a generic feature?
(The VM is open source; encryption of beam files is easy to add.)
> It, however, is necessary to get the publishing deals for PC games (the
> target market).
It would also add complexity to the VM and have a performance cost.
--
David Hopwood <david.hopwood@industrial-designers.co.uk>
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Fri Sep 07, 2007 5:50 pm |
|
|
|
Guest
|
David Hopwood wrote:
> It would also add complexity to the VM and have a performance cost.
Running out of a compressed archive is extremely common in the Java world. I've
always wondered if there is a performance hit there... but if so, no one seems
to be worried about it.
Ben
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Fri Sep 07, 2007 8:03 pm |
|
|
|
Guest
|
On 9/7/07, Ben Munat <bent@munat.com> wrote:
> David Hopwood wrote:
> > It would also add complexity to the VM and have a performance cost.
>
> Running out of a compressed archive is extremely common in the Java world. I've
> always wondered if there is a performance hit there... but if so, no one seems
> to be worried about it.
>
I'd imagine that it's measurably faster actually. All of the bytecode
lives in RAM once it's loaded, and disk is the bottleneck for loading
from compressed archives. Not only are you reading less blocks, but
there's less wasted space and less seeks with reading one file as
opposed to many.
-bob
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Fri Sep 07, 2007 11:29 pm |
|
|
|
Guest
|
Ben Munat wrote:
> David Hopwood wrote:
>> It would also add complexity to the VM and have a performance cost.
>
> Running out of a compressed archive is extremely common in the Java world.
It was encryption that I was referring to as having a performance cost.
Compression adds complexity, but not usually a significant performance cost.
It can result in a performance gain if the decompression algorithm is fast
enough, and if there was enough redundancy in the original format that we
are doing substantially less I/O to read the compressed file.
So compression might be beneficial, but that is independent of any desire
for copy protection.
--
David Hopwood <david.hopwood@industrial-designers.co.uk>
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Sat Sep 08, 2007 4:54 am |
|
|
|
Guest
|
What is probably needed here is a custom beam loader that can check
signatures on the beam files. This variant would replace the bit that
loads a beam from disk with a function that first scans the beam to
generate a hash and then compares the hash to a manifest that has been
signed by the publisher's pubkey. It would deter casual attacks and
any additional security you want to add would probably be best handled
in the beam loading mechanism anyway, so this would also be the
logical place to start if you wanted to later add beam encryption,
etc.
jim
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Sat Sep 08, 2007 5:42 am |
|
|
|
Guest
|
Vlad Dumitrescu wrote:
> The explanation this time is clearer, thanks.
OK, cool.
> You say some kind of DRM is necessary in order to get a deal. Sure,
> that's agreed.
>
> You say it's easier/safer to put all beam files in an archive and
> protect it, as compared to protect each beam file. I may be wrong, but
> I think there's no difference. If the code loader is extended so that
> it can load from an encrypted archive, then it can just as easily load
> from separately encrypted beam files. A cracker can do something about
> it if it cracks the encryption, and in that case both alternatives are
> just as easy to tamper with. Without the encryption key, a modified
> beam file would useless in both cases.
>
> What am I missing? What is a packaging into a smaller set of files
> adding to the security level?
A couple of things here. Firstly, by having the files "out in the open"
(i.e. same filename, etc) - it makes it REALLY easy to compare to the
original. It is pretty easy to work out how to the encryption used (&
the key) when you have the original file to compare to.
Game software DRM is all about _inconveniencing_ the hackers. It is an
axiom that having both the encrypted file & encryption key in the hands
of the client is not 100% secure. So arguments on that will only get
agreement from me. We cannot really raise the security level by putting
the files into a single archive, but we can raise the "inconvenience
level" making it more difficult
There is also "standard practice" to consider. As I mentioned in another
email - the standard practice for game deployment is a small number of
large archive files. By enabling the code to be extracted from a zip or
other archive - there is a single "bottleneck" in the code that can be
altered to other archive file formats (encrypted or otherwise).
The point *I* am trying to make is that enabling a single file (or
perhaps double "exe + archive" file) distribution enables the game
developers to get past the above "commercial hurdles", while also giving
the other developers asking for single/dual file deployments what they
desire.
Please note, this is not a demand or even a pushy request (contrary to
what I am sure it appears to be). I am simply trying to explain WHY some
of us desire the deployment characteristics we are asking for.
Regards,
B.J.Tolputt
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Sat Sep 08, 2007 5:46 am |
|
|
|
Guest
|
Jim McCoy wrote:
> What is probably needed here is a custom beam loader that can check
> signatures on the beam files. This variant would replace the bit that
> loads a beam from disk with a function that first scans the beam to
> generate a hash and then compares the hash to a manifest that has been
> signed by the publisher's pubkey. It would deter casual attacks and
> any additional security you want to add would probably be best handled
> in the beam loading mechanism anyway, so this would also be the
> logical place to start if you wanted to later add beam encryption,
> etc.
>
That would be one essential step. The other would be being able to load
beams from an archive file of some form. If I understand Kenneth
Lundin's email correctly - this is in the works but without a "delivery
date".
Regards,
B.J.Tolputt
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Thomas Lindgren |
| Posted: Sat Sep 08, 2007 11:14 am |
|
|
|
User
Joined: 09 Mar 2005
Posts: 284
|
--- Benjamin Tolputt <bjt@pmp.com.au> wrote:
> There is also "standard practice" to consider. As I
> mentioned in another
> email - the standard practice for game deployment is
> a small number of
> large archive files. By enabling the code to be
> extracted from a zip or
> other archive - there is a single "bottleneck" in
> the code that can be
> altered to other archive file formats (encrypted or
> otherwise).
>
> The point *I* am trying to make is that enabling a
> single file (or
> perhaps double "exe + archive" file) distribution
> enables the game
> developers to get past the above "commercial
> hurdles", while also giving
> the other developers asking for single/dual file
> deployments what they
> desire.
Storing multiple beam files in a single archive has
been done at least three times that I know of. Here is
a simple fourth approach (untested, of course):
* compile your modules into binaries M1,...,Mn
(compile:file(...,[...,binary,...]) should do it)
* create an archive:
Bin = term_to_binary([{mod1,"file1",M1},...]),
file:write("archive", Bin)
* at startup, load the code manually:
{ok, Archive} = file:read_file("archive"),
[ code:load_binary(Mod, File, Code)
|| {Mod, File, Code} <- binary_to_term(Archive) ]
Note that this requires some code to be present to
bootstrap, and sucks a big binary into the system. But
you can see the principle.
The beam emulator contains some precompiled bytecode
too, if memory serves. I'm not sure how that is
generated in detail, but you might be able to use the
same mechanism.
Best,
Thomas
____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.
http://mobile.yahoo.com/go?refer=1GNXIC
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
