So how do games work?

[Pixar Film Rock]

I'm a newbie, bear with me here.
It has one .exe file, is this where all the instruction is stored?
Everything else is just data like textures, maps, etc? How do these
crackers hack the .exe so that you don't need cds in the drive to play these
games? And there are also DLL files which have methods/functions too,
right?

[Daniel O'Connell]

"Pixar Film Rock" <pi***@film.com > wrote in message
news:bs******** ****@ID-198839.news.uni-berlin.de...

I'm a newbie, bear with me here.
It has one .exe file, is this where all the instruction is stored?
Possibly all user written code is in hte exe, although I'd never undertake a
large project in such a monolithic manner. Everything else is just data like textures, maps, etc? Perhaps, it depends on the game. Data has to be stored somehow, its possible
to store it inline with the exe, but that isn't ideal in most cases. How do these
crackers hack the .exe so that you don't need cds in the drive to play these games? CD checks tendto do a few basic things: require files off the drive, check
thedisc at a low level for specific features, etc. A cracker would simply
remove or modify the code so it doesn't bother with the disc. And there are also DLL files which have methods/functions too,
right? Well, to be totally straight, the game certainly calls atleast some system
libraries, however for user code, it depends entirely on the authors. You
can use dll's\libs, or you can use a monolithic executable.

[Pixar Film Rock]

So they decompile and have the source code to the whole game? That doesn't
sound right.


"Daniel O'Connell" <[e-mail]> wrote in message
news:eT******** ******@TK2MSFTN GP10.phx.gbl...

"Pixar Film Rock" <pi***@film.com > wrote in message
news:bs******** ****@ID-198839.news.uni-berlin.de...

I'm a newbie, bear with me here.
It has one .exe file, is this where all the instruction is stored?
Possibly all user written code is in hte exe, although I'd never undertake

a large project in such a monolithic manner.

Everything else is just data like textures, maps, etc? Perhaps, it depends on the game. Data has to be stored somehow, its

possible to store it inline with the exe, but that isn't ideal in most cases.

How do these
crackers hack the .exe so that you don't need cds in the drive to play

these

games?

CD checks tendto do a few basic things: require files off the drive, check
thedisc at a low level for specific features, etc. A cracker would simply
remove or modify the code so it doesn't bother with the disc.

And there are also DLL files which have methods/functions too,
right?

Well, to be totally straight, the game certainly calls atleast some system
libraries, however for user code, it depends entirely on the authors. You
can use dll's\libs, or you can use a monolithic executable.

[Daniel O'Connell]

"Pixar Film Rock" <pi***@film.com > wrote in message
news:bs******** ****@ID-198839.news.uni-berlin.de...

So they decompile and have the source code to the whole game? That doesn't sound right.
Well, not generally decompile, although in some cases that may be the chosen
path. Most protection schemes leave a pattern(a specific function call(or
set there of), or whatever) and can seemingly be removed with automated
tools, and all executables can be disassembled and debugged. Anyone with a
decent knowledge of x86 assembly can crack basic protections, someone with
advanced knowledge can crack harder ones.
Imagine a method like this:
bool IsLicenseValid( );

assume it uses assembly something akin to(very basic, its been awhile):
;do some stuff
;return false if not valid.
mov ax,0 ;we'll assume the method retuns its value via ax, and 0 is false
ret

all a crack would have to do is change it to
mov ax,1

and the IsLicenseValid function is circumvented. It is generally more
complicated in real life, but that is a simple explination.

A good protection scheme can do little but make it difficult to get around,
it is never possible to make it unbreakable. It is the same with IP
protection. A good reverse engineer will pull your IP right out of the x86
assmebly(and crackers do, its how they produce keygens), they don't need the
source code. When you ship your executable you ship your technology, you
cannot prevent people from examining it, simply make it more difficult to
figure out. Thats where managed obfustication comes in, although as a
general rule I don't think its always worth it. A dedicated attacker will
break the obfustication just as he will break x86 assembly, pseudo
assembly(if your mad enough to run your app via your own VM), or any other
scheme you can dream up. When it comes down to it, developers can't win, we
can only delay.


"Daniel O'Connell" <[e-mail]> wrote in message
news:eT******** ******@TK2MSFTN GP10.phx.gbl...

"Pixar Film Rock" <pi***@film.com > wrote in message
news:bs******** ****@ID-198839.news.uni-berlin.de...

I'm a newbie, bear with me here.
It has one .exe file, is this where all the instruction is stored?
Possibly all user written code is in hte exe, although I'd never undertake a

large project in such a monolithic manner.

Everything else is just data like textures, maps, etc?

Perhaps, it depends on the game. Data has to be stored somehow, its

possible

to store it inline with the exe, but that isn't ideal in most cases.

How do these
crackers hack the .exe so that you don't need cds in the drive to play

these

games?

CD checks tendto do a few basic things: require files off the drive,

check thedisc at a low level for specific features, etc. A cracker would simply remove or modify the code so it doesn't bother with the disc.

And there are also DLL files which have methods/functions too,
right?

Well, to be totally straight, the game certainly calls atleast some system libraries, however for user code, it depends entirely on the authors. You can use dll's\libs, or you can use a monolithic executable.

[Rick Strahl [MVP]]

Hi Daniel,

So how do you get around the issue of a signed EXE that supposedly can't be
tampered with? I understand that you can change the binary sohow, but you
still need to change the final EXE - how would you get around that?

Or are you saying pull everything out into IL first, make the change then
rebuild to a new Exe? Seems like something as big as monulithic game it'd be
real hard to get all the IL out in a form that it would just rebuild?

Sorry, ignorant on this topic too, but I am curious for reasons that are
similar. I've built a simple reg key scheme into my apps, which for a simple
way of doing things seems to work well. However, if one can go in and tweak
the IL it would be relatively easy to get around it.

I'm not too worried about it, but interesting discussion...

thanks,
+++ Rick ---

--

Rick Strahl
West Wind Technologies
http://www.west-wind.com/
http://www.west-wind.com/webblog/
----------------------------------
Making waves on the Web
"Daniel O'Connell" <[e-mail]> wrote in message
news:OW******** ******@TK2MSFTN GP12.phx.gbl...

"Pixar Film Rock" <pi***@film.com > wrote in message
news:bs******** ****@ID-198839.news.uni-berlin.de...

So they decompile and have the source code to the whole game? That doesn't

sound right.

Well, not generally decompile, although in some cases that may be the

chosen path. Most protection schemes leave a pattern(a specific function call(or
set there of), or whatever) and can seemingly be removed with automated
tools, and all executables can be disassembled and debugged. Anyone with a
decent knowledge of x86 assembly can crack basic protections, someone with
advanced knowledge can crack harder ones.
Imagine a method like this:
bool IsLicenseValid( );

assume it uses assembly something akin to(very basic, its been awhile):
;do some stuff
;return false if not valid.
mov ax,0 ;we'll assume the method retuns its value via ax, and 0 is false
ret

all a crack would have to do is change it to
mov ax,1

and the IsLicenseValid function is circumvented. It is generally more
complicated in real life, but that is a simple explination.

A good protection scheme can do little but make it difficult to get around, it is never possible to make it unbreakable. It is the same with IP
protection. A good reverse engineer will pull your IP right out of the x86
assmebly(and crackers do, its how they produce keygens), they don't need the source code. When you ship your executable you ship your technology, you
cannot prevent people from examining it, simply make it more difficult to
figure out. Thats where managed obfustication comes in, although as a
general rule I don't think its always worth it. A dedicated attacker will
break the obfustication just as he will break x86 assembly, pseudo
assembly(if your mad enough to run your app via your own VM), or any other
scheme you can dream up. When it comes down to it, developers can't win, we can only delay.

"Daniel O'Connell" <[e-mail]> wrote in message
news:eT******** ******@TK2MSFTN GP10.phx.gbl...

"Pixar Film Rock" <pi***@film.com > wrote in message
news:bs******** ****@ID-198839.news.uni-berlin.de...
> I'm a newbie, bear with me here.
> It has one .exe file, is this where all the instruction is stored?

Possibly all user written code is in hte exe, although I'd never undertake

a

large project in such a monolithic manner.
> Everything else is just data like textures, maps, etc?
Perhaps, it depends on the game. Data has to be stored somehow, its

possible

to store it inline with the exe, but that isn't ideal in most cases.
> How do these
> crackers hack the .exe so that you don't need cds in the drive to play these
> games?
CD checks tendto do a few basic things: require files off the drive,

check thedisc at a low level for specific features, etc. A cracker would simply remove or modify the code so it doesn't bother with the disc.
> And there are also DLL files which have methods/functions too,
> right?
Well, to be totally straight, the game certainly calls atleast some system libraries, however for user code, it depends entirely on the authors. You can use dll's\libs, or you can use a monolithic executable.
>
>

[Daniel O'Connell]

"Rick Strahl [MVP]" <ri********@hot mail.com> wrote in message
news:up******** ******@TK2MSFTN GP09.phx.gbl...

Hi Daniel,

So how do you get around the issue of a signed EXE that supposedly can't be tampered with? I understand that you can change the binary sohow, but you
still need to change the final EXE - how would you get around that? A signed exe(assuming you mean strongly named assemblies) basically just
allows you to verify that it hasn't been modified, it does not keep people
from performing modifications. A crack would change the signature and make
it easier to verify that a crack(or unsupported patch) has been applied but
does nothing to stop it.
Or are you saying pull everything out into IL first, make the change then
rebuild to a new Exe? Seems like something as big as monulithic game it'd be real hard to get all the IL out in a form that it would just rebuild?
That is one benifit, even if the entire game is decompiled(whic h is possible
in .NET, as it is with java), the result is an entire rebuild of the source,
dependent assemblies and all. It results with a large patch(every binary
file would have to be patched in several places), but doesn't stop anyone
from producing such a patch.

Sorry, ignorant on this topic too, but I am curious for reasons that are
similar. I've built a simple reg key scheme into my apps, which for a simple way of doing things seems to work well. However, if one can go in and tweak the IL it would be relatively easy to get around it.

I'm not too worried about it, but interesting discussion...
In reality, anyone who intends to crack your program isn't going to pull out
ildasm, arkinio, or reflector and remove the check, they are going to hop
onto a crack search site and find a patch. In my opinion, a protection
scheme only needs to be as strong as needed for the target market. Most
schemes need only keep breaking copyright as more work than the app costs.
In the end, the people who are going to buy it will buy it, those that will
crack it are going to crack it, no protection scheme in the world is going
to change that. Its the middle fringe we have to be concerned with, people
not honest enough to not steal but too lazy to go to great extents to steal
it. Its a bigger market that one would initally think.

All in all, your reg method hsould be fine assuming its not a 50mill a
license app, ;)
thanks,
+++ Rick ---

--

Rick Strahl
West Wind Technologies
http://www.west-wind.com/
http://www.west-wind.com/webblog/
----------------------------------
Making waves on the Web
"Daniel O'Connell" <[e-mail]> wrote in message
news:OW******** ******@TK2MSFTN GP12.phx.gbl...

"Pixar Film Rock" <pi***@film.com > wrote in message
news:bs******** ****@ID-198839.news.uni-berlin.de...

So they decompile and have the source code to the whole game? That

doesn't

sound right.

Well, not generally decompile, although in some cases that may be the

chosen

path. Most protection schemes leave a pattern(a specific function call(or

set there of), or whatever) and can seemingly be removed with automated
tools, and all executables can be disassembled and debugged. Anyone with a decent knowledge of x86 assembly can crack basic protections, someone with advanced knowledge can crack harder ones.
Imagine a method like this:
bool IsLicenseValid( );

assume it uses assembly something akin to(very basic, its been awhile):
;do some stuff
;return false if not valid.
mov ax,0 ;we'll assume the method retuns its value via ax, and 0 is false ret

all a crack would have to do is change it to
mov ax,1

and the IsLicenseValid function is circumvented. It is generally more
complicated in real life, but that is a simple explination.

A good protection scheme can do little but make it difficult to get

around,

it is never possible to make it unbreakable. It is the same with IP
protection. A good reverse engineer will pull your IP right out of the x86 assmebly(and crackers do, its how they produce keygens), they don't need

the

source code. When you ship your executable you ship your technology, you
cannot prevent people from examining it, simply make it more difficult to figure out. Thats where managed obfustication comes in, although as a
general rule I don't think its always worth it. A dedicated attacker will break the obfustication just as he will break x86 assembly, pseudo
assembly(if your mad enough to run your app via your own VM), or any other scheme you can dream up. When it comes down to it, developers can't win,

we

can only delay.

"Daniel O'Connell" <[e-mail]> wrote in message
news:eT******** ******@TK2MSFTN GP10.phx.gbl...
>
> "Pixar Film Rock" <pi***@film.com > wrote in message
> news:bs******** ****@ID-198839.news.uni-berlin.de...
> > I'm a newbie, bear with me here.
> > It has one .exe file, is this where all the instruction is stored?
>
> Possibly all user written code is in hte exe, although I'd never

undertake

a
> large project in such a monolithic manner.
> > Everything else is just data like textures, maps, etc?
> Perhaps, it depends on the game. Data has to be stored somehow, its
possible
> to store it inline with the exe, but that isn't ideal in most cases.
> > How do these
> > crackers hack the .exe so that you don't need cds in the drive to play > these
> > games?
> CD checks tendto do a few basic things: require files off the drive,

check

> thedisc at a low level for specific features, etc. A cracker would

simply

> remove or modify the code so it doesn't bother with the disc.
> > And there are also DLL files which have methods/functions too,
> > right?
> Well, to be totally straight, the game certainly calls atleast some

system

> libraries, however for user code, it depends entirely on the

authors. You

> can use dll's\libs, or you can use a monolithic executable.
> >
> >
>
>

[Dmitriy Lapshin [C# / .NET MVP]]

Hi Rick,

I fully agree with Daniel and that's what I've been taught on my university
lectures on IT security - the price of the protection scheme should never
exceed the estimated loss resulting from breaking the scheme.

BTW: There's microsoft.publi c.dotnet.securi ty newsgroup, should we move our
discussion there?

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://x-unity.miik.com.ua/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

"Rick Strahl [MVP]" <ri********@hot mail.com> wrote in message
news:up******** ******@TK2MSFTN GP09.phx.gbl...

Hi Daniel,

So how do you get around the issue of a signed EXE that supposedly can't be tampered with? I understand that you can change the binary sohow, but you
still need to change the final EXE - how would you get around that?

Or are you saying pull everything out into IL first, make the change then
rebuild to a new Exe? Seems like something as big as monulithic game it'd be real hard to get all the IL out in a form that it would just rebuild?

Sorry, ignorant on this topic too, but I am curious for reasons that are
similar. I've built a simple reg key scheme into my apps, which for a simple way of doing things seems to work well. However, if one can go in and tweak the IL it would be relatively easy to get around it.

I'm not too worried about it, but interesting discussion...

thanks,
+++ Rick ---

--

Rick Strahl
West Wind Technologies
http://www.west-wind.com/
http://www.west-wind.com/webblog/
----------------------------------
Making waves on the Web
"Daniel O'Connell" <[e-mail]> wrote in message
news:OW******** ******@TK2MSFTN GP12.phx.gbl...

"Pixar Film Rock" <pi***@film.com > wrote in message
news:bs******** ****@ID-198839.news.uni-berlin.de...

So they decompile and have the source code to the whole game? That

doesn't

sound right.

Well, not generally decompile, although in some cases that may be the

chosen

path. Most protection schemes leave a pattern(a specific function call(or

set there of), or whatever) and can seemingly be removed with automated
tools, and all executables can be disassembled and debugged. Anyone with a decent knowledge of x86 assembly can crack basic protections, someone with advanced knowledge can crack harder ones.
Imagine a method like this:
bool IsLicenseValid( );

assume it uses assembly something akin to(very basic, its been awhile):
;do some stuff
;return false if not valid.
mov ax,0 ;we'll assume the method retuns its value via ax, and 0 is false ret

all a crack would have to do is change it to
mov ax,1

and the IsLicenseValid function is circumvented. It is generally more
complicated in real life, but that is a simple explination.

A good protection scheme can do little but make it difficult to get

around,

it is never possible to make it unbreakable. It is the same with IP
protection. A good reverse engineer will pull your IP right out of the x86 assmebly(and crackers do, its how they produce keygens), they don't need

the

source code. When you ship your executable you ship your technology, you
cannot prevent people from examining it, simply make it more difficult to figure out. Thats where managed obfustication comes in, although as a
general rule I don't think its always worth it. A dedicated attacker will break the obfustication just as he will break x86 assembly, pseudo
assembly(if your mad enough to run your app via your own VM), or any other scheme you can dream up. When it comes down to it, developers can't win,

we

can only delay.

"Daniel O'Connell" <[e-mail]> wrote in message
news:eT******** ******@TK2MSFTN GP10.phx.gbl...
>
> "Pixar Film Rock" <pi***@film.com > wrote in message
> news:bs******** ****@ID-198839.news.uni-berlin.de...
> > I'm a newbie, bear with me here.
> > It has one .exe file, is this where all the instruction is stored?
>
> Possibly all user written code is in hte exe, although I'd never

undertake

a
> large project in such a monolithic manner.
> > Everything else is just data like textures, maps, etc?
> Perhaps, it depends on the game. Data has to be stored somehow, its
possible
> to store it inline with the exe, but that isn't ideal in most cases.
> > How do these
> > crackers hack the .exe so that you don't need cds in the drive to play > these
> > games?
> CD checks tendto do a few basic things: require files off the drive,

check

> thedisc at a low level for specific features, etc. A cracker would

simply

> remove or modify the code so it doesn't bother with the disc.
> > And there are also DLL files which have methods/functions too,
> > right?
> Well, to be totally straight, the game certainly calls atleast some

system

> libraries, however for user code, it depends entirely on the

authors. You

> can use dll's\libs, or you can use a monolithic executable.
> >
> >
>
>

[Daniel O'Connell]

"Dmitriy Lapshin [C# / .NET MVP]" <x-****@no-spam-please.hotpop.c om> wrote
in message news:uZ******** ******@TK2MSFTN GP10.phx.gbl...

Hi Rick,

I fully agree with Daniel and that's what I've been taught on my university lectures on IT security - the price of the protection scheme should never
exceed the estimated loss resulting from breaking the scheme.

Sadly, MS's activation feature breaks that rule IMHO. The cost to the end
user(and likely the cost to MS itself) is increased while probably not
providing any real reduction in piracy.
BTW: There's microsoft.publi c.dotnet.securi ty newsgroup, should we move our discussion there? It would probably be more appropriate, but not worth the energy if this
discussion is starting to wind down.
--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://x-unity.miik.com.ua/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

"Rick Strahl [MVP]" <ri********@hot mail.com> wrote in message
news:up******** ******@TK2MSFTN GP09.phx.gbl...

Hi Daniel,

So how do you get around the issue of a signed EXE that supposedly can't be

tampered with? I understand that you can change the binary sohow, but you

still need to change the final EXE - how would you get around that?

Or are you saying pull everything out into IL first, make the change then rebuild to a new Exe? Seems like something as big as monulithic game it'd be

real hard to get all the IL out in a form that it would just rebuild?

Sorry, ignorant on this topic too, but I am curious for reasons that are
similar. I've built a simple reg key scheme into my apps, which for a simple

way of doing things seems to work well. However, if one can go in and

tweak

the IL it would be relatively easy to get around it.

I'm not too worried about it, but interesting discussion...

thanks,
+++ Rick ---

--

Rick Strahl
West Wind Technologies
http://www.west-wind.com/
http://www.west-wind.com/webblog/
----------------------------------
Making waves on the Web
"Daniel O'Connell" <[e-mail]> wrote in message
news:OW******** ******@TK2MSFTN GP12.phx.gbl...

"Pixar Film Rock" <pi***@film.com > wrote in message
news:bs******** ****@ID-198839.news.uni-berlin.de...
> So they decompile and have the source code to the whole game? That
doesn't
> sound right.

Well, not generally decompile, although in some cases that may be the

chosen

path. Most protection schemes leave a pattern(a specific function

call(or set there of), or whatever) and can seemingly be removed with automated tools, and all executables can be disassembled and debugged. Anyone with a

decent knowledge of x86 assembly can crack basic protections, someone with advanced knowledge can crack harder ones.
Imagine a method like this:
bool IsLicenseValid( );

assume it uses assembly something akin to(very basic, its been

awhile): ;do some stuff
;return false if not valid.
mov ax,0 ;we'll assume the method retuns its value via ax, and 0 is

false ret

all a crack would have to do is change it to
mov ax,1

and the IsLicenseValid function is circumvented. It is generally more
complicated in real life, but that is a simple explination.

A good protection scheme can do little but make it difficult to get

around,

it is never possible to make it unbreakable. It is the same with IP
protection. A good reverse engineer will pull your IP right out of the x86 assmebly(and crackers do, its how they produce keygens), they don't need the

source code. When you ship your executable you ship your technology,

you cannot prevent people from examining it, simply make it more difficult to figure out. Thats where managed obfustication comes in, although as a
general rule I don't think its always worth it. A dedicated attacker will break the obfustication just as he will break x86 assembly, pseudo
assembly(if your mad enough to run your app via your own VM), or any other scheme you can dream up. When it comes down to it, developers can't win, we

can only delay.

>
>
>
>
> "Daniel O'Connell" <[e-mail]> wrote in message
> news:eT******** ******@TK2MSFTN GP10.phx.gbl...
> >
> > "Pixar Film Rock" <pi***@film.com > wrote in message
> > news:bs******** ****@ID-198839.news.uni-berlin.de...
> > > I'm a newbie, bear with me here.
> > > It has one .exe file, is this where all the instruction is

stored? > >
> > Possibly all user written code is in hte exe, although I'd never
undertake
> a
> > large project in such a monolithic manner.
> > > Everything else is just data like textures, maps, etc?
> > Perhaps, it depends on the game. Data has to be stored somehow, its > possible
> > to store it inline with the exe, but that isn't ideal in most cases. > > > How do these
> > > crackers hack the .exe so that you don't need cds in the drive to

play

> > these
> > > games?
> > CD checks tendto do a few basic things: require files off the

drive, check
> > thedisc at a low level for specific features, etc. A cracker would
simply
> > remove or modify the code so it doesn't bother with the disc.
> > > And there are also DLL files which have methods/functions too,
> > > right?
> > Well, to be totally straight, the game certainly calls atleast some system
> > libraries, however for user code, it depends entirely on the

authors. You
> > can use dll's\libs, or you can use a monolithic executable.
> > >
> > >
> >
> >
>
>