gamedevlists-general — List for discussing general game development issues

RE: [GD-General] Prices of well-known 3D engines

[Gareth L. <GL...@cl...>]

Sorry, ignore my previous email, I just read your first paragraph, assumed
the list was what you wanted to know.

For a fact I know

> - Renderware

Very dependant on what you want, they have various packages for support and
stuff. 

RE: [GD-General] Prices of well-known 3D engines

[Gareth L. <GL...@cl...>]

You can just email them directly. I did when I still owned B.O.G and they
varied from about $200k to $500k. 

And to answer your question, it's cheaper to buy :)

> -----Original Message-----
> From: Pierre Terdiman [mailto:p.t...@wa...]
> Sent: 03 June 2003 17:59
> To: gam...@li...
> Subject: [GD-General] Prices of well-known 3D engines
> 
> 
> Hi,
> 
> I'm looking for current prices of well-known 3D engines, to back up an
> argument I have with some people...  Any quick figures for me ?
> 
> I found those prices online:
> - Quake3
> - Cipher
> - Lithtech
> - Gamebryo (Netimmerse)
> 
> I'd like to know for :
> - Renderware
> - Unreal
> - others ?
> 
> Thanks,
> - Pierre
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 

[GD-General] Prices of well-known 3D engines

[Pierre T. <p.t...@wa...>]

Hi,

I'm looking for current prices of well-known 3D engines, to back up an
argument I have with some people...  Any quick figures for me ?

I found those prices online:
- Quake3
- Cipher
- Lithtech
- Gamebryo (Netimmerse)

I'd like to know for :
- Renderware
- Unreal
- others ?

Thanks,
- Pierre

RE: [GD-General] serial numbers

[Gareth L. <GL...@cl...>]

The trick is to use some kind of onliness. Downloading of new content for
example. Although sadly, even that can be downloaded by one and distributed
to everyone.

> -----Original Message-----
> From: Timur Davidenko [mailto:ti...@cr...]
> Sent: 03 June 2003 09:07
> To: gam...@li...
> Subject: RE: [GD-General] serial numbers
> 
> 
> Unlikely mandatory registration will bring any change, it is 
> valuable for online games of course,
> but for the simple Single Player, what can they do? 
> everything on the client can be cracked.
> IMHO it is worthless to waste allot of precisios game 
> development time, trying to protect from inevitable.
> 
> _________________________________
> Timur Davidenko.
> Crytek Studios (http://www.crytek.com)

RE: [GD-General] serial numbers

[Timur D. <ti...@cr...>]

Unlikely mandatory registration will bring any change, it is valuable =
for online games of course,
but for the simple Single Player, what can they do? everything on the =
client can be cracked.
IMHO it is worthless to waste allot of precisios game development time, =
trying to protect from inevitable.

_________________________________
Timur Davidenko.
Crytek Studios (http://www.crytek.com)



-----Original Message-----
From: Javier Arevalo [mailto:ja...@py...]
Sent: Friday, May 30, 2003 5:39 PM
To: gam...@li...
Subject: Re: [GD-General] serial numbers


What kind of drugs are you on, man? :)

I assume most games are uniquely signed to identify the receiver of =
betas.
We certainly did that on Praetorians (nice batch-mode signature tool for
those 85+ magazines!). Leaked versions may still appear, and despite the
fact that the leak can be traced back to one of the magazines, you will =
have
a hard time getting any compensation, the most you can hope for is their
promise that "they will be more careful in the future". The point of =
digital
signatures is "prevention": make sure the mag gets the point that their =
copy
is uniquely signed, that the signature is prominently displayed on the =
title
screen, that it can be hacked to not appear there but can't be removed
entirely, etc etc. and hope that, if they screw up, it will be with =
someone
else's title.

Flooding will not stop most p2p systems, they have learned to cope with
that: "trusted link sites", statistics for files, and pretty soon they =
will
have built-in ratings and "quality" estimators, just like they don't =
have
central servers anymore. The ones that don't adapt will simply stop =
being
used.

I wonder what the future is for mandatory online registration / =
verification
systems. These do create much more trouble for pirated versions, but =
have
tons of usability and privacy issues.

  Javier Arevalo
  Pyro Studios

Colin Fahey wrote:
>
> [1] First, put a unique code in each build of the game before the
> official release date, then do a Google search for any cracked
> versions, and then embarrass the reviewer who leaked the game to the
> public before it was
> even on sale!  Demand his head on a platter from the game magazine
> editor, or threaten to reduce your bribes for A+/100%/5-star ratings.
> Won't those punks change their tunes when you cut off their supply of
> cocaine, outcall escorts, and Japanese anime DVDs!
>
> [2] Later, when the game is in general release, do the Google search
> again, and send "Cease and Desist" e-mail to the punks offering
> cracks to your game, from fake law firms or from Yakuza assassins
> with an inexplicable desire to optimize "market efficiency" for your
> product.  Or invoke the Patriot Act and TIA or whatever and have the
> crackers tried by a secret military tribunal and summarily executed
> -- or at least brainwashed and cryogenically frozen to be revived
> later as Universal Soldiers, defending the government against freedom
> and democracy.
>
> [3] Then, do what Madonna does!  Flood Kazaa and Direct Connect with
> *fake* cracks to your game -- and put in some profane message to
> infuriate pirates! Releasing your most unimaginative game yet, just
> to get more cash out of your fan base, would complete the analogy,
> but that would simply be icing on the cake!  That will teach them to
> rage against the machine!  The freakin' machine is X-treme raging
> right back at 'em!  You da "Man"!



-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D557

Re: [GD-General] serial numbers

[Javier A. <ja...@py...>]

What kind of drugs are you on, man? :)

I assume most games are uniquely signed to identify the receiver of betas.
We certainly did that on Praetorians (nice batch-mode signature tool for
those 85+ magazines!). Leaked versions may still appear, and despite the
fact that the leak can be traced back to one of the magazines, you will have
a hard time getting any compensation, the most you can hope for is their
promise that "they will be more careful in the future". The point of digital
signatures is "prevention": make sure the mag gets the point that their copy
is uniquely signed, that the signature is prominently displayed on the title
screen, that it can be hacked to not appear there but can't be removed
entirely, etc etc. and hope that, if they screw up, it will be with someone
else's title.

Flooding will not stop most p2p systems, they have learned to cope with
that: "trusted link sites", statistics for files, and pretty soon they will
have built-in ratings and "quality" estimators, just like they don't have
central servers anymore. The ones that don't adapt will simply stop being
used.

I wonder what the future is for mandatory online registration / verification
systems. These do create much more trouble for pirated versions, but have
tons of usability and privacy issues.

  Javier Arevalo
  Pyro Studios

Colin Fahey wrote:
>
> [1] First, put a unique code in each build of the game before the
> official release date, then do a Google search for any cracked
> versions, and then embarrass the reviewer who leaked the game to the
> public before it was
> even on sale!  Demand his head on a platter from the game magazine
> editor, or threaten to reduce your bribes for A+/100%/5-star ratings.
> Won't those punks change their tunes when you cut off their supply of
> cocaine, outcall escorts, and Japanese anime DVDs!
>
> [2] Later, when the game is in general release, do the Google search
> again, and send "Cease and Desist" e-mail to the punks offering
> cracks to your game, from fake law firms or from Yakuza assassins
> with an inexplicable desire to optimize "market efficiency" for your
> product.  Or invoke the Patriot Act and TIA or whatever and have the
> crackers tried by a secret military tribunal and summarily executed
> -- or at least brainwashed and cryogenically frozen to be revived
> later as Universal Soldiers, defending the government against freedom
> and democracy.
>
> [3] Then, do what Madonna does!  Flood Kazaa and Direct Connect with
> *fake* cracks to your game -- and put in some profane message to
> infuriate pirates! Releasing your most unimaginative game yet, just
> to get more cash out of your fan base, would complete the analogy,
> but that would simply be icing on the cake!  That will teach them to
> rage against the machine!  The freakin' machine is X-treme raging
> right back at 'em!  You da "Man"!

Re: [GD-General] serial numbers

[Colin F. <cp...@ea...>]

>>> From: "Brian Hook" <xxxxxxxxxx>
>>>
>>> No matter how good your generator, someone will crack it if they want
>>> to.  But in all honesty, they'll just look for a crack at any of the
>>> numerous crack/codes sites.  Google will get you serial #s for just
>>> about any game you can imagine.  Or CD-keys.

[1] First, put a unique code in each build of the game before the official
release date, then do a Google search for any cracked versions, and then
embarrass the reviewer who leaked the game to the public before it was
even on sale!  Demand his head on a platter from the game magazine editor,
or threaten to reduce your bribes for A+/100%/5-star ratings.  Won't those
punks change their tunes when you cut off their supply of cocaine, outcall
escorts, and Japanese anime DVDs!

[2] Later, when the game is in general release, do the Google search again,
and send "Cease and Desist" e-mail to the punks offering cracks to your
game, from fake law firms or from Yakuza assassins with an inexplicable
desire to optimize "market efficiency" for your product.  Or invoke the
Patriot Act and TIA or whatever and have the crackers tried by a secret
military tribunal and summarily executed -- or at least brainwashed and
cryogenically frozen to be revived later as Universal Soldiers, defending
the government against freedom and democracy.

[3] Then, do what Madonna does!  Flood Kazaa and Direct Connect with *fake*
cracks to your game -- and put in some profane message to infuriate pirates!
Releasing your most unimaginative game yet, just to get more cash out of
your fan base, would complete the analogy, but that would simply be icing
on the cake!  That will teach them to rage against the machine!  The
freakin' machine is X-treme raging right back at 'em!  You da "Man"!

--- Colin

cp...@ea...

http://www.welovetheiraqiinformationminister.com/mss_readers.html

Re: [GD-General] serial numbers

[J C L. <cl...@ka...>]

On Wed, 28 May 2003 18:11:08 -0400 
Brian Hook <ho...@py...> wrote:

>> If you're generating keys over the net, then you're likely going
>> to have their email address, so use that instead of their name. 
>> It's guaranteed to be unique.

> It's also guaranteed to change.

And in the case of a role address is not guaranteed to be unique.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
cl...@ka...               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

Re: [GD-General] serial numbers

[Brian H. <ho...@py...>]

>The only way I see it being an issue, is if he changes email
>accounts and contacts you for a new key (re-install or=
 whatever).
>In that case you'd require that he give you sufficient proof=
 that he
>is who he says he is, then you just give him the key (or=
 generate a
>new one off of his new address).

Support hassles are far more prevalent than you'd expect.  People=
 
often can't remember who purchased a game (dad, mom, wife,=
 husband) 
and what e-mail was used.  Relying on e-mail addresses,=
 especially in 
this day of ISP (comcast.net, bellsouth.net, rr.com, cox.net,=
 etc.) 
and Web mail (Hotmail, Yahoo mail, etc.), seems to be a bad=
 idea.

>Is there another issue I'm missing?  Assuming Candy Cruncher=
 uses a
>key to unlock, you would probably have a fair bit of experience=
 with
>this by now.

Anyone could trivially backwards engineer our key generator,=
 because 
frankly, this isn't an area that is worth pursuing.  

No matter how good your generator, someone will crack it if they=
 want 
to.  But in all honesty, they'll just look for a crack at any of=
 the 
numerous crack/codes sites.  Google will get you serial #s for=
 just 
about any game you can imagine.  Or CD-keys.

So the only reason to do this is to stop the casual users who are=
 
scared or not knowledgeable enough to do this, and thankfully=
 (for 
us) that's the vast, vast majority of our audience.

All we do is generate a value from a combination of custom=
 product 
code and the user's name that they enter on the order form.  We=
 take 
that and generate a 16 (?) alphanum code, replacing often 
misinterpreted characters (e.g. no 'I' or 'O').

That's it.  Simple and easy.

Brian

Re: [GD-General] serial numbers

[Ken P. <ke...@dr...>]

At 05:11 PM 5/28/2003, Brian Hook wrote:

> >If you're generating keys over the net, then you're likely going to
> >have their email address, so use that instead of their name.  It's
> >guaranteed to be unique.
>
>It's also guaranteed to change.

G'day!

Sure, it's pretty likely.  But how important is that?

If you're mainly using it to generate a unique key for a customer, then it 
really doesn't matter.  He can change his address 1 million times.    The 
address is still in your database with his real name and whatever other 
info you captured with the sale.

The only way I see it being an issue, is if he changes email accounts and 
contacts you for a new key (re-install or whatever).  In that case you'd 
require that he give you sufficient proof that he is who he says he is, 
then you just give him the key (or generate a new one off of his new address).

Is there another issue I'm missing?  Assuming Candy Cruncher uses a key to 
unlock, you would probably have a fair bit of experience with this by now.

Stay Casual,

Ken

Re: [GD-General] serial numbers

[<cas...@ya...>]

Ken Paulson wrote:
> If you're generating keys over the net, then you're likely going to have
> their email address, so use that instead of their name.  It's guaranteed
to
> be unique.

Yeah, that's a good point.

Ignacio Castaño
cas...@ya...

Re: [GD-General] serial numbers

[Brian H. <ho...@py...>]

>If you're generating keys over the net, then you're likely going=
 to
>have their email address, so use that instead of their name. =
 It's
>guaranteed to be unique.

It's also guaranteed to change.

Brian

Re: [GD-General] serial numbers

[Ken P. <ke...@dr...>]

At 11:36 AM 5/27/2003, you wrote:
>MD5 is not trivially reversible, so this seems to work. However, if two
>users have the same name, the keys will also be the same, and some products
>don't requiere an username, so in that case I would have a single key!

If you're generating keys over the net, then you're likely going to have 
their email address, so use that instead of their name.  It's guaranteed to 
be unique.

[GD-General] Dithering from 24-bit to 16-bit

[Tom H. <to...@ve...>]

I'm looking for a tool that will take a 24-bit RGB image and reduce it down 
to lower bit depths (specifically, RGBA_4444, RGB_565, and RGBA_5551) with 
nice dithering to attempt to preserve the image quality. The perfect 
solution would be a Photoshop plug-in that worked kinda like their 
posterize function, but supported different bit depths per channel and did 
dithering.

Tom

Re: [GD-General] serial numbers

[<cas...@ya...>]

Thanks a lot for your explanation, now I understand.


Ignacio Castaño
cas...@ya...


Gareth Lewin wrote:
> Hmm, say (for arguments sake) that your hash is 12 characters. The
> sequential number is 4 characters.
>
> My name is Gareth Lewin, the code you give me is
>
> 0001-2486-2546-1356
>
> 2486-2546-1356 is the hash of "Gareth Lewin 0001"
>
> if another Gareth Lewin registered your product, you create the hash for
> "Gareth Lewin 002" and say that is 4532-5634-1867 so his key is
> 0002-4532-5634-1867
>
> Ofcourse you need to make sure your hash function generates vastly
differant
> values for "Gareth Lewin 001" and "Gareth Lewin 002"
>
> You can do that by taking the 4 digits as a hex number and xoring "Gareth
> Lewin" with it and hashing.
>
> So you generate a hash for "Gareth Lewin" xored (each 4 chars) by 0001
etc.
> This would work nicely if (and that's the case you describe) the hash
> function runs on a remote machine.
>
> This stuff won't work really well on the clients machine.
>
> Another idea is to have 255 or more secrets ( You can just take a
> dictionary, randomise it and use that as the secret table ), then the
> sequential number is just the index into the table.

RE: [GD-General] serial numbers

[Gareth L. <GL...@cl...>]

Hmm, say (for arguments sake) that your hash is 12 characters. The
sequential number is 4 characters.

My name is Gareth Lewin, the code you give me is

0001-2486-2546-1356

2486-2546-1356 is the hash of "Gareth Lewin 0001"

if another Gareth Lewin registered your product, you create the hash =
for
"Gareth Lewin 002" and say that is 4532-5634-1867 so his key is
0002-4532-5634-1867

Ofcourse you need to make sure your hash function generates vastly =
differant
values for "Gareth Lewin 001" and "Gareth Lewin 002"

You can do that by taking the 4 digits as a hex number and xoring =
"Gareth
Lewin" with it and hashing.

So you generate a hash for "Gareth Lewin" xored (each 4 chars) by 0001 =
etc.
This would work nicely if (and that's the case you describe) the hash
function runs on a remote machine.

This stuff won't work really well on the clients machine.

Another idea is to have 255 or more secrets ( You can just take a
dictionary, randomise it and use that as the secret table ), then the
sequential number is just the index into the table.

> -----Original Message-----
> From: Ignacio Casta=F1o [mailto:cas...@ya...]
> Sent: 27 May 2003 18:18
> To: gam...@li...
> Subject: Re: [GD-General] serial numbers=20
>=20
>=20
> Gareth Lewin wrote:
> > Just make the serial number out of two parts. The first part is a
> sequential
> > number, then hash the name and the serial number.
>=20
> But then, given a key, it's quite easy to generate a different one, =
by
> changing the sequential number.
>=20
> The validator doesn't know the sequential number of a given=20
> serial number
> beforehand. So, the sequential number cannot be added to the=20
> message with
> the secret and the public data. It has to be mixed with the=20
> result of the
> hash function. But how can I mix the sequence number and the hash in =
a
> non-obvios but reversible way?
>=20
> If it's too obvious, anybody can take an existing key, and=20
> generate many new
> keys using the same hash, but a different sequence number.
>=20
>=20
> Ignacio Casta=F1o
> cas...@ya...
>=20
>=20
> > -----Original Message-----
> > From: Ignacio Casta=F1o [mailto:cas...@ya...]
> > Sent: 27 May 2003 17:37
> > To: gam...@li...
> > Subject: Re: [GD-General] serial numbers
> >
> >
> > J C Lawrence wrote:
> > > Typical forms I've seen are a one-way hash ala MD5 of the
> > public data,
> > > along with a secret.  The resultant string (often with
> > another secret)
> > > is then digitally signed with the resultant string,
> > sometimes with a CRC
> > > or other padding data appended..  The application then=20
> verifies the
> > > signature to check that the key is of valid form, and the
> > central site
> > > can check that the key is legit.
> >
> > Thanks, I was looking for something like that so, but I still have =
a
> > problem. I create a message using the secret and the public=20
> data, and
> > generate the key aplying MD5 to it, so when the user logs in,
> > he provides
> > the previous key and the public data. I know the secret, so I
> > can recompute
> > the key and validate the key that the user provided.
> >
> > MD5 is not trivially reversible, so this seems to work.
> > However, if two
> > users have the same name, the keys will also be the same, and
> > some products
> > don't requiere an username, so in that case I would have a=20
> single key!
> >
> > How can I solve that? I'd like to add a random part to the
> > encoded message,
> > but then I don't know how to validate it...
> >
> > Thanks in advance,
> >
> >
> > Ignacio Casta=F1o
> > cas...@ya...
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: ObjectStore.
> > If flattening out C++ or Java code to make your application fit in =
a
> > relational database is painful, don't do it! Check out ObjectStore.
> > Now part of Progress Software.=20
http://www.objectstore.net/sourceforge
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D557
>


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU7



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D557

Re: [GD-General] serial numbers

[<cas...@ya...>]

Gareth Lewin wrote:
> Just make the serial number out of two parts. The first part is a
sequential
> number, then hash the name and the serial number.

But then, given a key, it's quite easy to generate a different one, by
changing the sequential number.

The validator doesn't know the sequential number of a given serial number
beforehand. So, the sequential number cannot be added to the message with
the secret and the public data. It has to be mixed with the result of the
hash function. But how can I mix the sequence number and the hash in a
non-obvios but reversible way?

If it's too obvious, anybody can take an existing key, and generate many new
keys using the same hash, but a different sequence number.


Ignacio Castaño
cas...@ya...


> -----Original Message-----
> From: Ignacio Castaño [mailto:cas...@ya...]
> Sent: 27 May 2003 17:37
> To: gam...@li...
> Subject: Re: [GD-General] serial numbers
>
>
> J C Lawrence wrote:
> > Typical forms I've seen are a one-way hash ala MD5 of the
> public data,
> > along with a secret.  The resultant string (often with
> another secret)
> > is then digitally signed with the resultant string,
> sometimes with a CRC
> > or other padding data appended..  The application then verifies the
> > signature to check that the key is of valid form, and the
> central site
> > can check that the key is legit.
>
> Thanks, I was looking for something like that so, but I still have a
> problem. I create a message using the secret and the public data, and
> generate the key aplying MD5 to it, so when the user logs in,
> he provides
> the previous key and the public data. I know the secret, so I
> can recompute
> the key and validate the key that the user provided.
>
> MD5 is not trivially reversible, so this seems to work.
> However, if two
> users have the same name, the keys will also be the same, and
> some products
> don't requiere an username, so in that case I would have a single key!
>
> How can I solve that? I'd like to add a random part to the
> encoded message,
> but then I don't know how to validate it...
>
> Thanks in advance,
>
>
> Ignacio Castaño
> cas...@ya...
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU7

RE: [GD-General] serial numbers

[Gareth L. <GL...@cl...>]

Just make the serial number out of two parts. The first part is a =
sequential
number, then hash the name and the serial number.

> -----Original Message-----
> From: Ignacio Casta=F1o [mailto:cas...@ya...]
> Sent: 27 May 2003 17:37
> To: gam...@li...
> Subject: Re: [GD-General] serial numbers=20
>=20
>=20
> J C Lawrence wrote:
> > Typical forms I've seen are a one-way hash ala MD5 of the=20
> public data,
> > along with a secret.  The resultant string (often with=20
> another secret)
> > is then digitally signed with the resultant string,=20
> sometimes with a CRC
> > or other padding data appended..  The application then verifies the
> > signature to check that the key is of valid form, and the=20
> central site
> > can check that the key is legit.
>=20
> Thanks, I was looking for something like that so, but I still have a
> problem. I create a message using the secret and the public data, and
> generate the key aplying MD5 to it, so when the user logs in,=20
> he provides
> the previous key and the public data. I know the secret, so I=20
> can recompute
> the key and validate the key that the user provided.
>=20
> MD5 is not trivially reversible, so this seems to work.=20
> However, if two
> users have the same name, the keys will also be the same, and=20
> some products
> don't requiere an username, so in that case I would have a single =
key!
>=20
> How can I solve that? I'd like to add a random part to the=20
> encoded message,
> but then I don't know how to validate it...
>=20
> Thanks in advance,
>=20
>=20
> Ignacio Casta=F1o
> cas...@ya...
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D557
>=20

Re: [GD-General] serial numbers

[<cas...@ya...>]

J C Lawrence wrote:
> Typical forms I've seen are a one-way hash ala MD5 of the public data,
> along with a secret.  The resultant string (often with another secret)
> is then digitally signed with the resultant string, sometimes with a CRC
> or other padding data appended..  The application then verifies the
> signature to check that the key is of valid form, and the central site
> can check that the key is legit.

Thanks, I was looking for something like that so, but I still have a
problem. I create a message using the secret and the public data, and
generate the key aplying MD5 to it, so when the user logs in, he provides
the previous key and the public data. I know the secret, so I can recompute
the key and validate the key that the user provided.

MD5 is not trivially reversible, so this seems to work. However, if two
users have the same name, the keys will also be the same, and some products
don't requiere an username, so in that case I would have a single key!

How can I solve that? I'd like to add a random part to the encoded message,
but then I don't know how to validate it...

Thanks in advance,


Ignacio Castaño
cas...@ya...

Re: [GD-General] serial numbers

[J C L. <cl...@ka...>]

On Tue, 27 May 2003 01:25:20 +0200 
iso  <iso-8859-1> wrote:

> I'd like to know which algoritms are usually used to generate and
> validate the keys. They keys should look like random, and I would like
> to include the product and user name in a non-obvious way. So that,
> given the product and the user, I should be able to validate the given
> key.

Typical forms I've seen are a one-way hash ala MD5 of the public data,
along with a secret.  The resultant string (often with another secret)
is then digitally signed with the resultant string, sometimes with a CRC
or other padding data appended..  The application then verifies the
signature to check that the key is of valid form, and the central site
can check that the key is legit.  

Other variants have (some of) the public data encoded in easily
reversible fashion in the string so that entering the key in the app
"magically" causes other fields to be populated.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
cl...@ka...               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

Re: [GD-General] serial numbers

[Ben C. <be...@gu...>]

On Tuesday, May 27, 2003, 12:25:20 AM, someone wrote:

[snip]
> I'm sure there is a lot of information about this, and I know that this is
> probably related with encryption and checksum algorithms, but I cannot see
> the exact relation between the two.

 You want to generate a sequence (probably trivially obfuscated)
containing the username/registration number (as in order number, not
unlocking code) or whatever, and then sign it using one of the various
public-key crypto algorithms. That way, you use the private key to
generate the signature, and the application can *verify* the signature
is valid using the public key, but it is "very hard" (in a provable,
mathematical sense) to generate a new valid signature without the
private key. Pick a big enough key-size (for an app like this, where
generation/verification time isn't a big issue, go for a large number
>=512 bit or so, say), and it becomes basically impossible to break
the system without acquiring the private key "directly" (ie breaking
into your office or whatever) or devoting totally unrealistic amounts
of computation time to it. 

 Er... or inventing a quantum computer, of course, but if someone
manages that I imagine cracking shareware registration schemes will be
well down their list of "things to do"... <grin>

 I'd look up the various open-source crypto libraries that are
available - it's possible to "roll your own" cryptography code, but
it's very easy to make subtle mistakes that can leave you open to
vulnerabilities.

-- 
Ben Carter - Neko Technologies - be...@gu...
http://www.neko-tech.com/ - http://www.absoluteterror.com/
---------------------------------PGP Key available on request---
"Broken mirror, a million shades of light,
 the old echo fades away. 
 But just you and I can find the answer, 
 and then we can run to the end of the world."
                                - Small of two pieces, Xenogears

Re: [GD-General] serial numbers

[<cas...@ya...>]

Thanks Jeff,

That link contains some useful points, but I'm looking for more technical
info.

I'd like to know which algoritms are usually used to generate and validate
the keys. They keys should look like random, and I would like to include the
product and user name in a non-obvious way. So that, given the product and
the user, I should be able to validate the given key.

I'm sure there is a lot of information about this, and I know that this is
probably related with encryption and checksum algorithms, but I cannot see
the exact relation between the two.

Any hints would be appreciated.


Ignacio Castaño
cas...@ya...


Jeff Thompson wrote:
> There was a good post on this subject on the Unsanity.org blog site. It
> has some Mac OS X specific comments in it, but is still a generally
> useful thread. You can read the thread here:
> http://www.unsanity.org/archives/000101.php
>
> Enjoy,

Re: [GD-General] serial numbers

[Jeff T. <myt...@ma...>]

There was a good post on this subject on the Unsanity.org blog site. It=20=

has some Mac OS X specific comments in it, but is still a generally=20
useful thread. You can read the thread here:=20
http://www.unsanity.org/archives/000101.php

Enjoy,

Jeff

Jeff Thompson
CTO, CodeTek Studios, Inc.


On Monday, May 26, 2003, at 11:07 AM, Ignacio Casta=F1o wrote:

> Hi,
> I'm looking for information about how to generate and validate serial=20=

> numers
> for a product that I want to sell. Could somebody point me any=20
> references on
> the subject?
>
> Thanks in advance,
>
>
> Ignacio Casta=F1o
> cas...@ya...
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D557

[GD-General] serial numbers

[<cas...@ya...>]

Hi,
I'm looking for information about how to generate and validate serial numers
for a product that I want to sell. Could somebody point me any references on
the subject?

Thanks in advance,


Ignacio Castaño
cas...@ya...

RE: [GD-General] remove unused functions

[Laurent G. <lg...@pa...>]

If you use MSVC 7, had you try to set Property|C/C++|Optimization|Global
Optimizations to Yes ? Look at LTCG in the documentation... Even if it's
much more an optimization option, it's actually remove all unused function
(even in our case)...

> -----Message d'origine-----
> De : gam...@li...
> [mailto:gam...@li...]De la part de
> Corrinne Yu
> Envoye : lundi 19 mai 2003 20:58
> A : gam...@li...
> Objet : [GD-General] remove unused functions
>
>
> The game engine and game code base has gotten very very big. And it is
> about time to clean things up and improve its structure and
> documentation.
>
> One thing I would like to do to it is to start removing un-used
> functions. I tried to use MSDev to remove un-referenced functions as a
> start but didn't find any. It turns out quite a few of the "un-used"
> functions are "referenced" (and thus can't be that easily
> automatically
> determined) but I know from how the game and engine code is
> supposed to
> run that they won't ever be called.
>
> They are not exactly unreachable code either, so doing the unreachable
> code thing also doesn't work.
>
> I truly "dread" :D the idea to have to manually step through all the
> code and manually cull out every single un-used function by
> hand (it is
> a lot of code to wade through!). I wonder what tools exist inside of
> MSDev (or simple easy to use small external tools) that can help me in
> my highly un fun task of cleaning up my code base, specifically in the
> task of removing "un-used" functions.
>
> Thank you for your experience in this task, and your suggestions.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>