🚀 go-pugleaf

"Eric Minso" <minso@altern.org> wrote in message
news:7db38e60.0308250121.6135ebc1@posting.google.com...
> Hello,

Hi,

> In which cases can you use relative addresses ?

When jump (call, jmp ,jcc, etc).

> In which cases must you use absolute addresses ?

When access data (mov eax, [mydata])

> This instruction :
> mov [ ebp + cst ], val
> (with 'ebp' initialised with loading address, and 'cst' initialised
> with offset) can solve the absolute addresses problem, so where is the
> trap ?

Usual program won't use such style because it will make the program
more complex to read and maintain and slower when running.
Such style is very popular in virus world, because they can't be relocated
by the system.

btw, Why do you hate absolute addresses? :-)


--
Koms Bomb

*****Pardon my poor English*****
---------------------
My TASM homepage, resource for assembly. Tools, articles, links.
http://komsbomb.ols-lab.com

"Koms Bomb" <KomsBombREMOVETHIS@hotmail.com> wrote in message 
> Usual program won't use such style because it will make the program
> more complex to read and maintain and slower when running.
> Such style is very popular in virus world, because they can't be relocated
> by the system.
> 
> btw, Why do you hate absolute addresses? :-)


Yes, the program I have to write really looks like a virus.

I am a trainee in a IT company, and my training subject is to write an
Windows EXE protection program. This program must encrypt the
executable's code section and add a decryption routine inside the
executable.

The first approach I tried was to make a kind of winzip
self-extractor. The main problem is that a temporary file is required
: it is not a very secure solution :-( The other main problem is that
it's always crashing :-((.

The virus-like approach seems to be the most interesting (and easy)
because the decryption job is done in memory and don't need a
temporary file. There is also some common virus sources available on
the internet, so a part of the job is already done :-)

The main problem is that it seems that assembly language is required
and I still have some troubles with absolute and relative addresses.
The other main problem is that I fear my program will be seen as a
virus by antiviruses.

Eric Minso wrote:

> Hello,
> 
> I would like to know a bit more about the use of absolute addresses
> and relative addresses.
> 
> I have read that Windows DLL have a relocation table : this table is

quite common, other dll models have those tables,too.
they are required because i86 cpu-s (and others) do not provide a sufficient
set of operations to efficiently supporting relocatable code w.o. those
tables (as for instance, the 680xx processors do).

> needed to correct each absolute addresse in the DLL file because you
> can't assume the memory location where DLL while be loaded. But, why
> don't only use relative addresses ? (because it's not possible, I
> guess)
> 
> In fact, my questions are :
> 
> In which cases can you use relative addresses ?

at any known, constant displacement, e.g. usually not w. different dll-s.

> In which cases must you use absolute addresses ?

memory mapped port access, memory ranges which are dedicated to some static
program, by convention, #the# video memory, etc...

> In which cases can you choose ? (and which choice is better ? (i.e.
> for speed...))

direct (abs) is faster - with x86-s. relocating required once, at startup,
thus even code which could be programmed w. reg and displacement might
become faster executing.

> 
> Tell me if I am wrong : you can use relative addresses only inside a
> code section, and each time you reference another section, you must
> use absolute addresses. Is it right ?

depends on execution model and on what your 'section' is.

> 
> A last question before leaving :-)
> 
> This instruction :
> mov [ ebp + cst ], val
> (with 'ebp' initialised with loading address, and 'cst' initialised
> with offset) can solve the absolute addresses problem, so where is the
> trap ?

right. but, number of available registers is the 'trap'.
i86 cpu-s have no pc-rel subroutine call which complicates the code and can
slow down a program, considerably

hp
-- 
>>> hp -at- lxhp -dot- in-berlin -dot- de <<<
linux,asm,forth http://www.lxhp.in-berlin.de

minso@altern.org (Eric Minso) wrote in message news:<7db38e60.0308250121.6135ebc1@posting.google.com>...
> Hello,
> 
> I would like to know a bit more about the use of absolute addresses
> and relative addresses.
> 
> I have read that Windows DLL have a relocation table : this table is
> needed to correct each absolute addresse in the DLL file because you
> can't assume the memory location where DLL while be loaded. But, why
> don't only use relative addresses ? (because it's not possible, I
> guess)

It is possible, but there are a couple of downsides;

1. the code is longer, as offsets need to be calculated into addresses
2. the code needs a base register to do this, which on a
register-starved machine like the x86 is a problem.

> 
> In fact, my questions are :
> 
> In which cases can you use relative addresses ?
> In which cases must you use absolute addresses ?
> In which cases can you choose ? (and which choice is better ? (i.e.
> for speed...))

As per Koms Bomb's reply in this thread

> 
> Tell me if I am wrong : you can use relative addresses only inside a
> code section, and each time you reference another section, you must
> use absolute addresses. Is it right ?

If the code is liked together from separate assemblies, yes. If it's
multiple sections in one assembly, not necessarily, but probably yes.

> 
> A last question before leaving :-)
> 
> This instruction :
> mov [ ebp + cst ], val
> (with 'ebp' initialised with loading address, and 'cst' initialised
> with offset) can solve the absolute addresses problem, so where is the
> trap ?

There isn't one, except your cst must be a register, as noted above.
Here's an example; let's say we have an address in eax that points to
an addresss we want to jump to.

   jmp [eax]

If it's to be relocatable then the pointer is an offset, and so is the
thing it points to, so

   mov eax, [eax+edi]
   add eax, edi
   jmp eax

Longer, needs edi as a base register and adds to the code complexity
(unless you're prepared to use macros extensively). Plus, if you get
an address back from some other code (like the OS) then you have to
   sub eax, edi 
to make it a relative offset too. 

> 
> Thank you !
> 
> Eric.

-- 
Regards
Alex McDonald

"Eric Minso" <minso@altern.org> wrote in message
news:7db38e60.0308260511.4b9a371@posting.google.com...
> "Koms Bomb" <KomsBombREMOVETHIS@hotmail.com> wrote in message
> > Usual program won't use such style because it will make the program
> > more complex to read and maintain and slower when running.
> > Such style is very popular in virus world, because they can't be
relocated
> > by the system.
> >
> > btw, Why do you hate absolute addresses? :-)
>
>
> Yes, the program I have to write really looks like a virus.
>
> I am a trainee in a IT company, and my training subject is to write an
> Windows EXE protection program. This program must encrypt the
> executable's code section and add a decryption routine inside the
> executable.
>

Why? Are they in the virus business? There's plenty of ways to protect their
intellectual property without writing a virus look-alike. Use a product that
doesn't look like a virus and that works -- try googling on "exe encryption"
for examples.

> The first approach I tried was to make a kind of winzip
> self-extractor. The main problem is that a temporary file is required
> : it is not a very secure solution :-( The other main problem is that
> it's always crashing :-((.
>
> The virus-like approach seems to be the most interesting (and easy)
> because the decryption job is done in memory and don't need a
> temporary file. There is also some common virus sources available on
> the internet, so a part of the job is already done :-)

Your company would be mad letting you write something based on a virus.

>
> The main problem is that it seems that assembly language is required
> and I still have some troubles with absolute and relative addresses.
> The other main problem is that I fear my program will be seen as a
> virus by antiviruses.
>

Even more sucking of teeth... if you use any of the widely available virus
sources, that's definitely true. If you've think you've got problems with
relative and absolute addresses, just think how it's going to be with the
police when they visit.

-- 
Regards
Alex McDonald

"Eric Minso" <minso@altern.org> wrote in message
news:7db38e60.0308260511.4b9a371@posting.google.com...

> The main problem is that it seems that assembly language is required
> and I still have some troubles with absolute and relative addresses.

No trouble.
call @@1
@@1:
pop ebp
Then you can use ebp and offset @@1 to do you relative address, then
you needn't absolute address any more.
As you said, there are a lot of virus source code in the internet, you can
learn how they use above code to play relative address.

> The other main problem is that I fear my program will be seen as a
> virus by antiviruses.

Yup. If you redirect the entry point out of the code segment, some
antivirus monitor will complain loudly when the user run the 'protected'
program. Maybe you can learn some EPO technic from the viruses,
but if so, maybe we should call your program as a 'virus', though it can't
replicate itself :-)

To do your mission, I suggest you read the UPX source code and see
how it works, I believe it can help you much. UPX is a real compress
program, no AV s/w will regard it as a virus :-). Like UPX, you should
re-orgnize the PE file rather than append a piece of code to file.

Above is my experience, I hope it will help you.


--
Koms Bomb

*****Pardon my poor English*****
---------------------
My TASM homepage, resource for assembly. Tools, articles, links.
http://komsbomb.ols-lab.com

"hp" <phpr@snafu.de> wrote in message
news:bifme4$fh$1@news.eusc.inter.net...

> > I have read that Windows DLL have a relocation table : this table is
>
> quite common, other dll models have those tables,too.
> they are required because i86 cpu-s (and others) do not provide a
sufficient
> set of operations to efficiently supporting relocatable code w.o. those
> tables (as for instance, the 680xx processors do).

Which 680xx instructions support this  mechanism?

Jeff wrote:

> 
> "hp" <phpr@snafu.de> wrote in message
> news:bifme4$fh$1@news.eusc.inter.net...
> 
>> > I have read that Windows DLL have a relocation table : this table is
>>
>> quite common, other dll models have those tables,too.
>> they are required because i86 cpu-s (and others) do not provide a
> sufficient
>> set of operations to efficiently supporting relocatable code w.o. those
>> tables (as for instance, the 680xx processors do).
> 
> Which 680xx instructions support this  mechanism?

right. you'd put me back to reality...:

all op-s which access memory have a PC-relative referencing mode plus, BSR
which is a PC-rel subroutine call which is not limited by disp. figure.

thus no need to any absolute reference but memory mapped i/o (no 'port's
exist) or special purpose addresses which are known by convention.

some kind of a starter program (e.g. linux 'execve') would always need to
'know' the entry point by it's true (whatever access mode) address, but the
program itself won't need a single one absolute reference.

besides, talking about a program's own memory; ref to others' or to external
library code would be different. though the 680xx cpu-s have more gp regs,
which makes rel. ref to the 'outer world' easier but not different wrt i86.

and, detailed analysis of (imho, fairly poor) run-time efficiency is another
point which would belong to another discussion, though.

regards,
        hp

-- 
>>> (hp)at(lxhp)dot(in-berlin)dot(de) <<<
linux,asm,forth http.//www.lxhp.in-berlin.de

Koms Bomb wrote:

> "Eric Minso" <minso@altern.org> wrote in message
> news:7db38e60.0308260511.4b9a371@posting.google.com...
> 
>> The main problem is that it seems that assembly language is required
>> and I still have some troubles with absolute and relative addresses.
> 
> No trouble.
> call @@1
> @@1:
> pop ebp
> Then you can use ebp and offset @@1 to do you relative address, then
> you needn't absolute address any more.
> As you said, there are a lot of virus source code in the internet, you can
> learn how they use above code to play relative address.

the above example is the common referencing method in relocatable code as
compiled by linux GCC which is certainly not to be mis-interpreted as a
'virus'. I use it with my 'lib4th' dll, too, and never run into trouble.

I should think that this method is common practice (since several decades).

a more efficient variant (cache 'friendly', faster), at&t syntax:
; ---

getref: movl (esp),ebx  ; att: "mov dwords source, destn"
        ret

relref: call getref
regref: lea coderef-regref(ebx),ecx     ; e.g, ref to label <coderef>
        ...

; ----

hp

-- 
>>> hp : lxhp in-berlin de <<<
linux,asm,forth http://www.lxhp.in-berlin.de/index-lx.html

"Alex McDonald" <alex_mcd@btopenworld.com> wrote in message news:
> > Yes, the program I have to write really looks like a virus.
> >
> > I am a trainee in a IT company, and my training subject is to write an
> > Windows EXE protection program. This program must encrypt the
> > executable's code section and add a decryption routine inside the
> > executable.
> >
> 
> Why? Are they in the virus business? There's plenty of ways to protect their
> intellectual property without writing a virus look-alike. Use a product that
> doesn't look like a virus and that works -- try googling on "exe encryption"
> for examples.

No, they are not in the virus business.
They just want to develop themselve their protection program (and own
the source code). I looked for examples on the internet, but most of
them aren't free.


> > The first approach I tried was to make a kind of winzip
> > self-extractor. The main problem is that a temporary file is required
> > : it is not a very secure solution :-( The other main problem is that
> > it's always crashing :-((.
> >
> > The virus-like approach seems to be the most interesting (and easy)
> > because the decryption job is done in memory and don't need a
> > temporary file. There is also some common virus sources available on
> > the internet, so a part of the job is already done :-)
> 
> Your company would be mad letting you write something based on a virus.

My boss said that it is a way that should be explored.
I am just a trainee :-)


> > The main problem is that it seems that assembly language is required
> > and I still have some troubles with absolute and relative addresses.
> > The other main problem is that I fear my program will be seen as a
> > virus by antiviruses.
> >
> 
> Even more sucking of teeth... if you use any of the widely available virus
> sources, that's definitely true. If you've think you've got problems with
> relative and absolute addresses, just think how it's going to be with the
> police when they visit.

Why ? I do nothing illegal ! I am NOT developing a new virus. I am
looking for a way to protect an EXE file. When I looked for examples
on the internet, the only examples I found were virus-related.

Now, if you have any other idea for protecting executables, I will be
happy to have it.

"Eric Minso" <minso@altern.org> wrote in message
news:7db38e60.0308270023.1d3f4cf@posting.google.com...
> "Alex McDonald" <alex_mcd@btopenworld.com> wrote in message news:
> > > Yes, the program I have to write really looks like a virus.
> > >
> > > I am a trainee in a IT company, and my training subject is to write an
> > > Windows EXE protection program. This program must encrypt the
> > > executable's code section and add a decryption routine inside the
> > > executable.
> > >
> >
> > Why? Are they in the virus business? There's plenty of ways to protect
their
> > intellectual property without writing a virus look-alike. Use a product
that
> > doesn't look like a virus and that works -- try googling on "exe
encryption"
> > for examples.
>
> No, they are not in the virus business.
> They just want to develop themselve their protection program (and own
> the source code).

What advantage does this bring them?

> I looked for examples on the internet, but most of
> them aren't free.
>
>
> > > The first approach I tried was to make a kind of winzip
> > > self-extractor. The main problem is that a temporary file is required
> > > : it is not a very secure solution :-( The other main problem is that
> > > it's always crashing :-((.
> > >
> > > The virus-like approach seems to be the most interesting (and easy)
> > > because the decryption job is done in memory and don't need a
> > > temporary file. There is also some common virus sources available on
> > > the internet, so a part of the job is already done :-)
> >
> > Your company would be mad letting you write something based on a virus.
>
> My boss said that it is a way that should be explored.
> I am just a trainee :-)

Owning a handgun is illegal in the UK; it's no defence to suggest you're
just taking it apart to make a pencil holder. Ask for another project.

>
>
> > > The main problem is that it seems that assembly language is required
> > > and I still have some troubles with absolute and relative addresses.
> > > The other main problem is that I fear my program will be seen as a
> > > virus by antiviruses.
> > >
> >
> > Even more sucking of teeth... if you use any of the widely available
virus
> > sources, that's definitely true. If you've think you've got problems
with
> > relative and absolute addresses, just think how it's going to be with
the
> > police when they visit.
>
> Why ? I do nothing illegal ! I am NOT developing a new virus.

I disagree.

> I am
> looking for a way to protect an EXE file. When I looked for examples
> on the internet, the only examples I found were virus-related.

That's because you _are_ writing a new virus.

>
> Now, if you have any other idea for protecting executables, I will be
> happy to have it.
>

I know how to; I'm not posting the answer. Take a course at the University
of Calgary; then if you're lucky only the University and your boss will get
sued when your company issues your code.
http://antivirus.about.com/library/weekly/aa052303b.htm

-- 
Regards
Alex McDonald

> Now, if you have any other idea for protecting executables, I will
> be happy to have it.

well.. something comes to mind... i was reading about the UPS
two-dimentional barcode, and they said something about all the data in the
barcode is completely recoverable, even if over half the pattern is torn off
or worn away... how about something similar for exe's...  not a barcode...
but... a way of restoring exe's when something has changed their size and
crc32...

i dunno... maybe that'd be an even greater task.. (and take up more space...
of course the recovery program and recovery data could be stored on a
central location... possibly storing the pattern info on a CD-RW, and using
a normal CD-ROM to access it would be **almost** perfect security from virii
and their ilk.

(i know i'm way out of my own field now.. so i'll just hush and let that
idea settle in the swamps and float away)

Bx.C, "Shiragaseinen"

On 27 Aug 2003 01:23:22 -0700, minso@altern.org (Eric Minso) wrote:

<snip>
>Why ? I do nothing illegal ! I am NOT developing a new virus. I am
>looking for a way to protect an EXE file. When I looked for examples
>on the internet, the only examples I found were virus-related.
>
>Now, if you have any other idea for protecting executables, I will be
>happy to have it.

In the long run, there is no way.  It someone wants to crack a
protected program bad enough, they will.  In the short run, there are
several systems available that use dongles to make life difficult for
would be crackers.  Aladdin and Rainbow come to mind.  Properly used,
they can make it so difficult, that only the most dedicated cracker
will persist.  Improperly used, they are worthless.  However, any
system of protection that has the key stored in the EXE, as any self
decrypting EXE would have to, is just pointless.  All you have to do,
is to step thru the program with a good debugger.

-- 
Arargh308 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the garbage from the reply address.

"Alex McDonald" <alex_mcd@btopenworld.com> wrote in message news:
> > No, they are not in the virus business.
> > They just want to develop themselve their protection program (and own
> > the source code).
> 
> What advantage does this bring them?

That's simple : owning a source code allows you to modify it as you
want, when you want.



> > My boss said that it is a way that should be explored.
> > I am just a trainee :-)
> 
> Owning a handgun is illegal in the UK; it's no defence to suggest you're
> just taking it apart to make a pencil holder. Ask for another project.

It is illegal to create and release new viruses.

What is a virus ? A program that duplicates itself and infests other
computers in order to do nasty tasks without acceptance of the user.

I'm not creating a virus.
I will not release a virus.

Is it also illegal in the UK to know how work handguns ?


> > Why ? I do nothing illegal ! I am NOT developing a new virus.
> 
> I disagree.

I don't understand why.
Look at the definition of a virus.


> > I am
> > looking for a way to protect an EXE file. When I looked for examples
> > on the internet, the only examples I found were virus-related.
> 
> That's because you _are_ writing a new virus.

I disagree.
Look at the definition of a virus.


> > Now, if you have any other idea for protecting executables, I will be
> > happy to have it.
> >
> 
> I know how to; I'm not posting the answer.

So I will have to continue in the same way.


> Take a course at the University
> of Calgary; then if you're lucky only the University and your boss will get
> sued when your company issues your code.
> http://antivirus.about.com/library/weekly/aa052303b.htm

Sued ?
About which crime please ?

"Eric Minso" <minso@altern.org> wrote in message
news:7db38e60.0308280508.6205dd69@posting.google.com...
> "Alex McDonald" <alex_mcd@btopenworld.com> wrote in message news:
> > > No, they are not in the virus business.
> > > They just want to develop themselve their protection program (and own
> > > the source code).
> >
> > What advantage does this bring them?
>
> That's simple : owning a source code allows you to modify it as you
> want, when you want.
>

But your code is still vulnerable to hackers with debuggers. Protecting your
intellectual property needs to be done without using this incredibly
dangerous development technique.

> > > My boss said that it is a way that should be explored.
> > > I am just a trainee :-)
> >
> > Owning a handgun is illegal in the UK; it's no defence to suggest you're
> > just taking it apart to make a pencil holder. Ask for another project.
>
> It is illegal to create and release new viruses.
>
> What is a virus ? A program that duplicates itself and infests other
> computers in order to do nasty tasks without acceptance of the user.

Wrong. Some of the most succesful are propagated by people like us, through
email and general unhygenic file-swapping habits. Self-duplication has got
nothing to do with it. How about Nachi -- hey, it tried to fix things! Still
a virus though.

>
> I'm not creating a virus.
> I will not release a virus.
>
> Is it also illegal in the UK to know how work handguns ?
>
>
> > > Why ? I do nothing illegal ! I am NOT developing a new virus.
> >
> > I disagree.
>
> I don't understand why.
> Look at the definition of a virus.
>
>
> > > I am
> > > looking for a way to protect an EXE file. When I looked for examples
> > > on the internet, the only examples I found were virus-related.
> >
> > That's because you _are_ writing a new virus.
>
> I disagree.
> Look at the definition of a virus.
>
>
> > > Now, if you have any other idea for protecting executables, I will be
> > > happy to have it.
> > >
> >
> > I know how to; I'm not posting the answer.
>
>
> > Take a course at the University
> > of Calgary; then if you're lucky only the University and your boss will
get
> > sued when your company issues your code.
> > http://antivirus.about.com/library/weekly/aa052303b.htm
>
> Sued ?
> About which crime please ?
>

I know you think you're not writing a virus, but you're certainly going
about it like you are.

Look, your boss suggests, or you go off on your own bat, & pick up some
junky bits of code off a virus web site or ftp server. Then you modify it
and then spread it around with your commercial products. You're having
trouble with relative/absolute addressing; I defy you to understand what
some viruses get up to, and the incredible lengths virus writers go to in
making their code difficult to spot by virus scanners, which makes it
difficult to read. How do you know what you've done? Leave _anything_ that
claims to be a virus alone. And if I was your bosses' boss, I'd fire you and
him _right now_ for even allowing you to visit these sites, far less
suggesting it. Knowing how infectious some viruses can be and the
maliciousness of these dead-heads, you'll probably end up infecting your
entire company in a couple of hours after downloading some "virus-writing"
software, and the rest of us get infected by you a few days later. And your
customers will sue the pants off you if you drop some of the malicious crap
that's out there on them on your latest product CDs. Don't go there.

Read the faqs on alt.comp.virus at
http://www.faqs.org/faqs/computer-virus/alt-faq/.

"Some of the grounds on which virus writing or distribution may be
found to be illegal (obviously I'm not stating that all these grounds
will apply at all times in all states or countries!) include:
...
* Incitement (e.g. making available viruses, virus code, information
  on writing viruses, and virus engines)
..."

So I didn't, and you shouldn't either.

One thing I will give you; you asked first. I've been burned by viruses far
too often, both privately and commercially.
Now you know (know how I feel, anyhow), perhaps you'll reconsider. End of
rant.

-- 
Regards
Alex McDonald

> I've been burned by viruses far too often, both privately
> and commercially. Now you know (know how I feel, anyhow),
> perhaps you'll reconsider. End of rant.

you accused him, you scolded him, you arrested him, you fired him, you sued 
him... and now you go and stop after i bought a bag of marshmallows for the 
witch burning? :p

regards,
phil

sinewave wrote:
> 
>> I've been burned by viruses far too often, both privately
>> and commercially. Now you know (know how I feel, anyhow),
>> perhaps you'll reconsider. End of rant.
> 
> 
> you accused him, you scolded him, you arrested him, you fired him, you 
> sued him... and now you go and stop after i bought a bag of marshmallows 
> for the witch burning? :p

Well, perhaps you'll find a use for those marshmallows yet.  People who 
write viruses are idiots who don't have any idea how to competently 
program.  Unforunately, just like the idiots on the highway who kill 
other people due to their own stupidity, virus writers could ultimately 
do the same thing:  http://continuitycentral.com/news0500.htm

Ed

"Alex McDonald" <alex_mcd@btopenworld.com> wrote in message 
> But your code is still vulnerable to hackers with debuggers. Protecting your
> intellectual property needs to be done without using this incredibly
> dangerous development technique.
> 
> [...]
>
> Wrong. Some of the most succesful are propagated by people like us, through
> email and general unhygenic file-swapping habits. Self-duplication has got
> nothing to do with it. How about Nachi -- hey, it tried to fix things! Still
> a virus though.
> 
> > Sued ?
> > About which crime please ?
> >
> 
> I know you think you're not writing a virus, but you're certainly going
> about it like you are.
> 
> Look, your boss suggests, or you go off on your own bat, & pick up some
> junky bits of code off a virus web site or ftp server. Then you modify it
> and then spread it around with your commercial products. You're having
> trouble with relative/absolute addressing; I defy you to understand what
> some viruses get up to, and the incredible lengths virus writers go to in
> making their code difficult to spot by virus scanners, which makes it
> difficult to read. How do you know what you've done? Leave _anything_ that
> claims to be a virus alone.


You didn't understand me.

Do you really think I am crazy enough to compile source code I don't
understand ?

Do you really think I will stupidly copy-paste their code inside my
application ?

Sorry.


What I'm trying to do is to understand how an application can add a
"patch code" to another application.

I _never_ compile untrusted source code.
I _always_ _write_ each line of my code.
I _always_ _understand_ each line of my code.

Are you still anxious ?
Are you still believing I will stupidly and accidentally release a
virus ?

Ed Beroset <beroset@mindspring.com> wrote in message news:
> Well, perhaps you'll find a use for those marshmallows yet.  People who 
> write viruses are idiots who don't have any idea how to competently 
> program.  Unforunately, just like the idiots on the highway who kill 
> other people due to their own stupidity, virus writers could ultimately 
> do the same thing:  http://continuitycentral.com/news0500.htm


Why are they stupid enough to connect a nuclear power plant to the internet ?
Think about what could do a terrorist.
And I guess their computers are running on Microsoft Windows...

"Eric Minso" <minso@altern.org> wrote in message
news:7db38e60.0308290140.1817fff2@posting.google.com...

===snipped

>
> Are you still anxious ?
> Are you still believing I will stupidly and accidentally release a
> virus ?
>

Stupidly, no. Accidentally, possibly. Just don't start by downloading virus
source. There. I've eaten all my marshmallows.

I've given your original question some thought (you may have forgotten it in
all this, I certainly did), so here are a few alternatives you may wish to
consider.

If you have some method in your code that you want to keep secret, that's
novel and of value to your company, then consider patenting it. (There will
be those that think this is not the right route -- free beer etc -- but it's
a commercially sound technique, and I would defend your freedom to your
secret.)

If you want to make it more difficult for people to run your products
illegally, consider

o hardware dongles
o some form of key certificate/password on encrypted _data_ (could be an
important EXE that's held in encrypted form)
o distribute as crippleware -- don't give them the bit that prints, for
instance, until they've bought
o a CD dongle variant -- issue CDs with a deliberate I/O error at a given
point, check for it; most CD copying software can't copy CDs that generate
I/O errors.
o another "dongle-with-password"  -- generate "fingerprints" from the boxes
the software is installed on, issue keys that unlock just on those boxes
o giving the software away and charging for support
o talking to audit/licence management software vendors and ensuring they can
detect your product from their audit products
o all of the above simultaneously.

None are 100% foolproof, but stops most of the common forms of abuse. I
would also suggest joining FAST (Federation Against Software Theft) though I
don't know if it operates in France.

-- 
Regards
Alex McDonald

>>What is a virus ? A program that duplicates itself and infests other
>>computers in order to do nasty tasks without acceptance of the user.
> 
> Wrong. Some of the most succesful are propagated by people like us, through
> email and general unhygenic file-swapping habits. Self-duplication has got
> nothing to do with it. How about Nachi -- hey, it tried to fix things! Still
> a virus though.

You're both wrong. A virus is a program that infects other programs. It 
doesn't have to do anything else, but most do. Then there are programs 
that propagate themselves by other means, copying themselves from one 
machine to another. Those are worms. Then there is the kind that people 
propagate unintentionally because they think they are benign programs. 
Those are trojans. Then there is Outlook Express, but we're all familiar 
with that and don't accidentally use it anymore.

Bjarni

> I _never_ compile untrusted source code.
> I _always_ _write_ each line of my code.
> I _always_ _understand_ each line of my code.

I used to have that mentality too, then I realized that it would take me
forever to write my own operating system, graphical interface, application
framework, etc., etc.  If you're ever going to be part of any significant
software development project, you're going to have to accept on faith that
the pieces/parts you're using work reliably.  Well, most of the time.  ;)

On 27 Aug 2003 01:23:22 -0700, minso@altern.org (Eric Minso) wrote:

>No, they are not in the virus business.
>They just want to develop themselve their protection program (and own
>the source code). I looked for examples on the internet, but most of
>them aren't free.

Just FYI, most modern virus scanners include some level of heuristics,
which includes checking a virus for coding style. If you are producing
a product for commercial sales, you run the risk of having AV flag
your product, if erroneously. That can cause problems for your
customers.

Sponge
Sponge's Anti-Spyware Source
www.geocities.com/yosponge

On Sat, 30 Aug 2003 02:58:09 +0000, Bjarni Juliusson wrote:

>>>What is a virus ? A program that duplicates itself and infests other
>>>computers in order to do nasty tasks without acceptance of the user.
>> 
>> Wrong. Some of the most succesful are propagated by people like us, through
>> email and general unhygenic file-swapping habits. Self-duplication has got
>> nothing to do with it. How about Nachi -- hey, it tried to fix things! Still
>> a virus though.
> 
> You're both wrong. A virus is a program that infects other programs. It 
> doesn't have to do anything else, but most do. Then there are programs 
> that propagate themselves by other means, copying themselves from one 
> machine to another. Those are worms. Then there is the kind that people 
> propagate unintentionally because they think they are benign programs. 
> Those are trojans. Then there is Outlook Express, but we're all familiar 
> with that and don't accidentally use it anymore.

LOL ;=)

Well, ther is something else with the last one. There is no
optimalisation done to it, so it can not be one of the former ones,
because the writers go to a great length to otimize their code, and they
maintain their work, by writing _better_ versions of it. But that goes
for all products of that company.

-- 
Herman Grootaers

minso@altern.org (Eric Minso) wrote in message 
[...]
> Now, if you have any other idea for protecting executables, I will be
> happy to have it.

 If you want to protect against code modifications, then how about runtime
 checking? You embed md5 hash checking code all over your application, and
 the program just terminates itself if it finds modified code. Of course,
 you have to duplicate this code, so it can not be removed by modifying
 the code at only one place. This is breakable, but it's very hard to do
 it. You can check all constant sections (code and read only data) with
 this technology. It's done during execution, so patching the executable
 code (to restore crippled features or to eliminate protection) is very
 hard. You will need an application, that can identify the data locations
 and patch your compiled executable with the hash codes, because the code
 can only be computed _after_ the linking is done.

 For code readability protection, there is no real cure. If a code runs,
 then it can be traced and disassembled manually. So this technology is
 good for stopping or slowing piracy, but it can't stop reverse engineering.

   Viktor

In fact, I don't have the source code of executables I want to
protect.


The company where I do my training period is a computer manufacturer :
they assemble computers and install standard configurations (Windows
XP + some softwares). They also give a CD-ROM with many application
that the user can install.

In order to lower the computer cost, the sofwares available on the
CD-ROM are locked and the customer do not pay the licence for them. A
serial number allows him to unlock only three or four softwares that
he can choose.

The interest for the customer is that he installs only softwares he
wants.

A few time ago, some software editors have claimed that the protection
system is too easy to hack and asked to the company a better
protection for their softwares.

So I was asked to study a way to protect these executables.
Unfortunately, I have only access to the executables - I can't
recompile the softwares to protect.

Eric Minso wrote:
> Ed Beroset wrote:
> > Well, perhaps you'll find a use for those marshmallows yet.
People who
> > write viruses are idiots who don't have any idea how to
competently
> > program.  Unforunately, just like the idiots on the highway who
kill
> > other people due to their own stupidity, virus writers could
ultimately
> > do the same thing:  http://continuitycentral.com/news0500.htm
>
> Why are they stupid enough to connect a nuclear power plant to the
internet ?
> Think about what could do a terrorist.
> And I guess their computers are running on Microsoft Windows...

Indeed; The stupidity of the human race seems to know absolutely no
bounds...Einstein was right (paraphrased: "The only two things which I
believe are infinite are human stupidity and the universe...and, to be
honest, I'm not so sure that the universe is infinite" ;)...

It shouldn't be connected to anything...and if you really, really need
networking for some reason then use your own secure system, rather
than attach it to the one that any old Joe or Joanna can get access
to...usually, I'd presume that no control system is under the control
of anything that's connected to anything outside the facility...but
then, I'd expect that they'd have the sense not to have the internet
at all, so I'm not so sure about that anymore...

Beth :)

Eric Minso wrote:
> You didn't understand me.
>
> Do you really think I am crazy enough to compile source code I don't
> understand ?
>
> Do you really think I will stupidly copy-paste their code inside my
> application ?
>
> Sorry.
>
> What I'm trying to do is to understand how an application can add a
> "patch code" to another application.
>
> I _never_ compile untrusted source code.
> I _always_ _write_ each line of my code.
> I _always_ _understand_ each line of my code.
>
> Are you still anxious ?
> Are you still believing I will stupidly and accidentally release a
> virus ?

You still have to be _very careful_...virus writers are in the
business of duping people into doing stupid things...they are
extremely good at it and go to great lengths to fool and disguise
their intentions...a datafile or data in a program might look innocent
enough that you don't bother disassembling what you're supposing is
just some graphics data or whatever...and, oops, you missed that bit
where they exercised the slight of hand...just like you miss a
magician doing a card trick...

One piece of data slipped on the stack and a "call sp" instruction
(note, easily disguised as, say, a "call ax" instruction with an "xchg
ax, sp" miles and miles beforehand, which you easily
overlooked)...and, hey presto, the otherwise innocent-looking code is
now executing instructions hidden in filenames or carefully selected
data that looks like an innocent ASCII string but is actually valid
instruction code that does nasty things...really, it literally only
takes a single instruction or a single DWORD of disguised data to lose
complete control...and there's many, many ways to disguise these
things...

You _really_ have to know what _every single line_ does before you
execute it...and, simply, as there's a chance you could miss something
then the safest option is simply don't even go there...

The point here is, basically, it's a dangerous activity which you
don't, in fact, need to do...you could put on a bullet-proof vest to
prove that it works...but, oh dear, if it doesn't or you put it on
wrongly then you could end up dead...a totally stupid thing to do when
you could set-up a dummy to wear the vest and shoot that, then measure
the impact and work out whether you'd be dead or not had you been
wearing it...and if there's a big hole and the bullet has passed
straight through then you can be quite sure that it was very sensible
to use a dummy and not yourself for the tests...

On top of all this, the notion of "protection" is, I'm afraid,
unachievable, anyway...if it's software then it's utterly
crackable...for example, you might think having the executable pack
and encrypt your code is a good measure to take...but, just run the
code on an emulator like Bochs and then freeze the program at the
right point and then copy the unpacked, unencrypted code elsewhere for
examination...it could take you weeks to perfect this and they'll have
avoided your protections completely _within minutes_ and all using
nice, simple automated tools readily available...any protections
depending on instructions being executed won't work when they either
aren't executing the code (you can just read the bytes out of the EXE
as a data file and examine them without running a single item of code)
or they execute it on an emulator - which isn't the true machine - and
instruct it to tell them if the program tries to pull a fast one...

Whatever you attempt there's always a reverse process that'll crack
it...heck, these people can crack open _hardware_ and reverse engineer
silicon slivers...if hardware can't stand a chance against these
people then software is not even worth the effort...

Really, the only "protection" software has is the Berne Convention,
copyright law, Intellectual Property laws and software piracy
laws...and these people abide by none of those rules, anyway, as they
are criminals who are fine with the notion of breaking the law and
simply don't care...

Unsatisfactory? Yes...but welcome to the world...every lock can be
cracked...every measure you take to protect your property can be
circumvented...if someone wants to break into your house and they are
utterly determined then they eventually will...and with software, you
actually distribute that "house" to other's machines so they have as
much time as they like to crack into it...you're always absent and
away from this "house" that exists in every copy of your program...

Hence, you're contemplating a dangerous activity in order to do
something that, basically, won't work, anyway...understand why
everyone has concerns to advise you to another course of action...like
the bullet-proof vest, we _DON'T_ want the situation of seeing you
walking around with a big bullet hole in you...the satisfaction of
being able to say "I told you so" holds none of its usual smugness in
that situation...

Beth :)

minso@altern.org (Eric Minso) wrote in message news:<7db38e60.0309020817.6e397ccd@posting.google.com>...
> In fact, I don't have the source code of executables I want to
> protect.
> 
> 
> The company where I do my training period is a computer manufacturer :
> they assemble computers and install standard configurations (Windows
> XP + some softwares). They also give a CD-ROM with many application
> that the user can install.
> 
> In order to lower the computer cost, the sofwares available on the
> CD-ROM are locked and the customer do not pay the licence for them. A
> serial number allows him to unlock only three or four softwares that
> he can choose.
> 
> The interest for the customer is that he installs only softwares he
> wants.
> 
> A few time ago, some software editors have claimed that the protection
> system is too easy to hack and asked to the company a better
> protection for their softwares.
> 
> So I was asked to study a way to protect these executables.
> Unfortunately, I have only access to the executables - I can't
> recompile the softwares to protect.

Are you making this up as you go along? For sure, somebody in your
company isn't thinking straight.

Let's say you'd succeeded in writing your original idea. Each user
would need to be given a "key" to allow decryption and loading of the
program by your program. So they copy your CD and the key, give it to
their friends, and you're back where you are right now. Or am I
missing something here?

What %age of purchasers come back to buy extra software? If it's not
significant, then my favoured solution for your problem is not to ship
the software on the CD in the first place. Send them the author's CD
when they order it, and save the company CD production/handling costs,
hassle from software authors etc.

Or, what system is your company currently using? How are people
hacking it? Can it reasonably be beefed up?

Or you encrypt the software on the CD using a strong key; there are
plenty of descriptions of DES encryption algorithms on the web. Give
the user another key that is "unscrambled" to the decryption key. Base
it on the date; allow, say, 5 days for the key to be valid. Then the
key is useless to anyone else outside that 5 day window.

Now you could put an I/O error on the CD as well; that makes it more
difficult to copy the CD, and the "unscrambler" program can check for
that too. Joe Average now needs a valid key, the original CD and needs
to install in 5 days. Even then, he could still install it on a 100
PCs in that period. So you could introduce a "machine key" so it only
works on his PC... and so on.

Of course, once the software's installed on a PC it could be copied
off. But that's true of every piece of software I've ever seen that
doesn't have some form of extra check, such as a dongle (and even they
can be copied). That form of protection is the responsibility of the
software author, not your company.

You'll never stop software theft, all you can do is make it more
difficult, but at a price. There's a balance between the cost of
deterrence and the loss you think you're incurring. Work that out
first, write code last.

-- 
Regards
Alex McDonald

Beth wrote:
> Eric Minso wrote:
> 
>>Ed Beroset wrote:
>> 
> People who
> 
>>>write viruses are idiots who don't have any idea how to
> 
> competently
> 
>>>program.  Unforunately, just like the idiots on the highway who
> 
> kill
> 
>>>other people due to their own stupidity, virus writers could
> 
> ultimately
> 
>>>do the same thing:  http://continuitycentral.com/news0500.htm
>>
>>Why are they stupid enough to connect a nuclear power plant to the
> 
> internet ?
> 
>>Think about what could do a terrorist.
>>And I guess their computers are running on Microsoft Windows...
> 
> 
> Indeed; The stupidity of the human race seems to know absolutely no
> bounds...
[...]
> It shouldn't be connected to anything...

Yes, that's obvious.

As is the fact that the virus writing idiots had no idea that this might 
have been one consequence.  Virus writers are irresponsible and 
incompetent exactly *because* they either think of these consequences 
and do it anyway or never think of them in the first place.

That's the point, which seems to have been missed.

Ed

"Beth" <BethStone21@hotmail.NOSPICEDHAM.com> wrote in message news:<fZi5b.138$qL6.113704@newsfep1-win.server.ntli.net>...
>
> You still have to be _very careful_...virus writers are in the
> business of duping people into doing stupid things...
> [.....]
> the bullet-proof vest, we _DON'T_ want the situation of seeing you
> walking around with a big bullet hole in you...the satisfaction of
> being able to say "I told you so" holds none of its usual smugness in
> that situation...
> 
> Beth :)


Thank you for your long answer :-)

You can be sure I always have been very careful :)

I just read their source to see what they do, what they read, what
they write, and once I understand, I rewrite it in my own way.

When I first talked about viruses, many people has reacted, but don't
forget it is one possibility between several ones.

At the origin, I wanted to know how programs (of which, the viruses)
could "infect" an executable. The reason is beacuse I don't have the
source of the executables to protect.

I'm not trying to write the total protection, I know that a good
hacker will always find a way to crack the software, but I want to
have a protection.

The company where I do my training period is a computer manufacturer :
they assemble computers and install standard configurations (Windows
XP + some softwares). They also give a CD-ROM with many application
that the user can install.

In order to lower the computer cost, the sofwares available on the
CD-ROM are locked and the customer do not pay the licence for them. A
serial number allows him to unlock only three or four softwares that
he can choose.

The interest for the customer is that he installs only softwares he
wants.

A few time ago, some software editors have claimed that the protection
system is too easy to hack and asked to the company a better
protection for their softwares.

So I was asked to study a way to protect these executables.


Eric.

On 3 Sep 2003 09:37:46 -0700, minso@altern.org (Eric Minso) wrote:
<snip>
>A few time ago, some software editors have claimed that the protection
>system is too easy to hack and asked to the company a better
>protection for their softwares.
>
>So I was asked to study a way to protect these executables.
>

What sort of protection is being used now?

I think this is an interesting problem.  I don't know how the
typical "exe encryption" programs work, but I see two 
general approaches:

1)  Treat the final exe, including its PE header, as simple data.
A stub loader will decrypt it into memory and invoke some
Windows API function to run it as if from a file.  (I assume
such function exists, but haven't checked.)  This would put
the relocation burden on the API, but I would think it would
be vulnerable to crackers who would only have to watch
for that API function in their debugger, and grab the memory
image.

2) You could do the PE relocation as part of your
decryptor, and jump to the start address.  The cracker
won't have an easy target for his debugger.  But you
will have the whole burden of the relocation.  You
may need special consideration of the fact that
Windows sees your loader/decryptor and the final exe
as one program, which it will load to 400000h like
normal programs.  To simplify that, put your code 
after the (encrypted) exe and change the PE start
point to your code, after saving the true start point
which you can jump to when ready.  (Just like a virus!)

Yes, any scheme can be cracked with determination.
But some of us lock our cars and houses when we
leave them, betting on the crooks taking the path
of least resistance and looking for easier pickings
elsewhere.



Bob Masta
dqatechATdaqartaDOTcom
 
            D A Q A R T A
Data AcQuisition And Real-Time Analysis
 Shareware from Interstellar Research
          www.daqarta.com

Eric Minso wrote:
> Beth wrote:
> > You still have to be _very careful_...virus writers are in the
> > business of duping people into doing stupid things...
> > [.....]
> > the bullet-proof vest, we _DON'T_ want the situation of seeing you
> > walking around with a big bullet hole in you...the satisfaction of
> > being able to say "I told you so" holds none of its usual smugness
in
> > that situation...
>
> Thank you for your long answer :-)
[ snip ]
> I'm not trying to write the total protection, I know that a good
> hacker will always find a way to crack the software, but I want to
> have a protection.
[ snip ]
> In order to lower the computer cost, the sofwares available on the
> CD-ROM are locked and the customer do not pay the licence for them.
A
> serial number allows him to unlock only three or four softwares that
> he can choose.
>
> The interest for the customer is that he installs only softwares he
> wants.
>
> A few time ago, some software editors have claimed that the
protection
> system is too easy to hack and asked to the company a better
> protection for their softwares.
>
> So I was asked to study a way to protect these executables.

Right; And you don't have the source code too?

Well, as Bob has mentioned, one method immediately springs to
mind...treat the executable as a datafile and encrypt that...then you
write a "chassis" kind of thing that's an executable which just has a
decryptor routine...you then link in the encrypted data with this
"chassis" frame so that it decrypts the executable...you can allocate
the memory, decrypt the executable into that (relocating, if necessary
:) and then jumping into the decrypted code...the "key" that's used in
the decryptor can be a "serial code" or whatever, handed out to the
customer when they pay for what they want...thus, you can only unlock
it when you know the serial code...and you _don't_ go leaving the
"key" that unlocks the program inside the decryptor itself...that's a
little too easy to unlock...just like you don't go leaving your car
keys in the ignition and the door wide open when you walk away from a
car...

Also, you can't really stop a determined cracker...instead, the best
you can do is just make cracking your program so intolerably annoying
to crack open, that they just can't be bothered to try...here's one
really mad idea...only decrypt a small section of the program at one
time...say, 64KB "chunks"...install an exception handler that catches
illegal memory accesses and if the program tries to access something
outside its current "chunk", it'll trigger an exception which your
program can use to decrypt the other chunk...the oldest chunks
delibrately have their data wiped over with some "blank" page before
being deallocated and made invalid again...

And, overall, your decryptor program does not allow more than two or
three "chunks" to be resident in memory at the same time...this helps
make it more awkward because the hacker can't just run your program in
a debugger and wait for it all to be decrypted and then save the
decrypted program straight from memory into another file (thereby,
by-passing your protection in one easy step with their debugger
:)...the whole program is never in memory in one go, so it'd have to
be jigsaw pieced together by trying to get the program to do a little
bit of everything to bring each "chunk" into memory...

The price for that, though, is that it'll have a constant performance
penalty because of the need to always decrypt new "chunks" all the
time...bigger chunks make this happen less often and improve
performance but make it easier to piece together the parts of the
program...smaller chunks have a worse performance penalty but there's
so many jigsaw pieces to put together, it should help to put off any
would-be crackers with the thought of all that hard work in front of
them :)

Also, your exception handler can grab onto any debugging "int 3" or
single-stepping exceptions and delibrately mess those up (a so-called
"anti-debugging" trick...so, if the cracker is trying to run this
under a debugger - only debuggers need "int 3" or single-stepping -
then your program delibrately freaks out and does stupid, nonsensical
things, so as to totally and utterly confuse any debugger or anyone
using the debugger as to what's actually going on...they'll try
"attach" and then, suddenly, your program just goes totally weird and
becomes unreadable and forces the debugger to hang...again, as always,
this stuff can be worked around but it's designed to annoy the hell
out of any cracker trying so that they just decide to give up trying
:)...another one is to put in some self-modifying code that effects
the instructions it's just about to execute...that is, assemble in a
"NOP" or something but then overwrite that with the real
instructions...simple disassemblers won't be able to deal with this
and will see "NOP" rather than the real instruction and will then be
"out of synch" with all the instructions afterwards, disassembling
them to the wrong opcodes :)...

You could even get real silly about this and the decryptor unpacks yet
another decryptor (which uses a different method to the first one) and
inside that is the real executable...so, like one of those Russian
dolls, the cracker breaks open your first decryptor, thinking s/he's
broken your protections, only to find that there's yet another layer -
which encrypts using a different algorithm, so they'll have to start
their cracking all over again from the start - inside that...practical
matters would limit things but imagine it being 10, 15 or 20 layers
deep (and every layer is also doing the "never hold the entire
executable in memory at the same time" trick too :)...as we all know,
you can't stop someone who's determined...the trick instead is to put
up so many obstacles in the cracker's way that they really, really,
really need to be determined to even attempt it...you make it such
hassle that the cracker thinks "oh, I give up...this other software
from someone else is far easier to crack, I'll do that"...

Although, that said, one slight problem is that the better the job you
do, the more you'll actually attract crackers...remember, it's an
"ego" and "I'm better than all the other crackers" thing for many of
them...hence, if you have the most impenetrable protections - you own
"Fort Knox" - then this can actually _attract_ crackers...informal
"competitions" between them: Who can crack open all 21 "Russian doll"
layers first? That sort of thing...also, the fact that there's so many
protections may have some crackers thinking "Wow, they are going to
some lengths to protect it! What are they hiding in there?"...that is,
you could actually generate some mystery and their natural curiosity
does the rest...after all, who puts 27 layers of locks and alarms
around their house? Yes, exactly...someone who's got something very
valuable they want to protect from thieves...even if you haven't got
anything that's really all that greatly valuable, having tons and tons
of protections can _make_ them think this, anyway...after all, until
it's cracked open, they don't really ever know what's inside...

So, in a bizzare sense, NOT having too many protections is a
_psychologically-based_ protection in itself..."too easy" only
attracts the "lamers"...so, aiming it at "not too little" but _also_
"not too much" is about right...you don't want it so easy that anyone
and everyone can do it just by reading some "type in this serial code"
file on a website...but, at the same time, if you make this the most
protected piece of code in history then, in fact, they'll be starting
up "cracking competitions" to be the first to crack open your
program...it'll become the new "cracker's benchmark": "huh, if you
can't crack Eric's protections then you're just a sad lamer and not a
cracking guru!"...

Really, though, the only protections that even begin to work are
_physically_ based...for example, dongles or that the "key" to decrypt
the executable is _physically_ kept away from the executable until
it's paid for (though this second one has some implementation
problems...you'd want each copy to have a unique "key" or all it takes
is for one cracker to pay for a legitimate key and then pass that key
onto every other customer...but, also, separately encrypting and
linking every copy is not all that conducive to the usual
mass-production methods used to burn lots of CDs...but one "half-way
house" idea is to create, say, ten or twenty different serial codes so
that there's only a 1 in 10 or 1 in 20 chance that two randomly chosen
copies will share the same serial code...except, of course, until all
twenty codes are discovered...as noted, no such thing as uncrackable
protection...but just so long as it's not "too easy" and makes the
cracker work very hard to get anywhere, that'll put off all but the
most determined (who are the ones you can _never_ stop whatever you
try)...

In the end, the only "protection" that ever works is simply never to
have anything that anyone else wants to steal...obviously, you don't
have a choice in this case but it's about the only "protection" that
actually works...buy a really crap car with rust and bits falling off
and a 50/50 chance that it won't start, that backfires when it does
start, etc....and, heck, leave the door wide open and the keys in the
ignition with a big sign reading "steal me!"...and it'll still be
there when you come back, as even joy riders won't see much "joy" in
stealing an old rust bucket that barely moves...unfortunately, neither
will you find much "joy" in owning it either but, hey, at least
no-one's going to steal it, eh? :)

Beth :)

no_spam@aol.com (Bob Masta) wrote in message news:

> <snip>
> 1)  Treat the final exe, including its PE header, as simple data.
> A stub loader will decrypt it into memory and invoke some
> Windows API function to run it as if from a file.  (I assume
> such function exists, but haven't checked.)  This would put
> the relocation burden on the API, but I would think it would
> be vulnerable to crackers who would only have to watch
> for that API function in their debugger, and grab the memory
> image.

I first tried this approach.
Unfortunately, I didn't succeed in starting this program from the memory.
And using a temporary file is unthinkable.


> 2) You could do the PE relocation as part of your
> decryptor, and jump to the start address.  The cracker
> won't have an easy target for his debugger.  But you
> will have the whole burden of the relocation.  You
> may need special consideration of the fact that
> Windows sees your loader/decryptor and the final exe
> as one program, which it will load to 400000h like
> normal programs.  To simplify that, put your code 
> after the (encrypted) exe and change the PE start
> point to your code, after saving the true start point
> which you can jump to when ready.  (Just like a virus!)

That's what I am trying to do.

Alex McDonald wrote:
> Eric Minso wrote:
> > In fact, I don't have the source code of executables I want to
> > protect.
> >
> > The company where I do my training period is a computer
manufacturer :
> > they assemble computers and install standard configurations
(Windows
> > XP + some softwares). They also give a CD-ROM with many
application
> > that the user can install.
> >
> > In order to lower the computer cost, the sofwares available on the
> > CD-ROM are locked and the customer do not pay the licence for
them. A
> > serial number allows him to unlock only three or four softwares
that
> > he can choose.
> >
> > The interest for the customer is that he installs only softwares
he
> > wants.
> >
> > A few time ago, some software editors have claimed that the
protection
> > system is too easy to hack and asked to the company a better
> > protection for their softwares.
> >
> > So I was asked to study a way to protect these executables.
> > Unfortunately, I have only access to the executables - I can't
> > recompile the softwares to protect.
>
> Are you making this up as you go along? For sure, somebody in your
> company isn't thinking straight.
>
> Let's say you'd succeeded in writing your original idea. Each user
> would need to be given a "key" to allow decryption and loading of
the
> program by your program. So they copy your CD and the key, give it
to
> their friends, and you're back where you are right now. Or am I
> missing something here?
>
> What %age of purchasers come back to buy extra software? If it's not
> significant, then my favoured solution for your problem is not to
ship
> the software on the CD in the first place. Send them the author's CD
> when they order it, and save the company CD production/handling
costs,
> hassle from software authors etc.
>
> Or, what system is your company currently using? How are people
> hacking it? Can it reasonably be beefed up?
>
> Or you encrypt the software on the CD using a strong key; there are
> plenty of descriptions of DES encryption algorithms on the web. Give
> the user another key that is "unscrambled" to the decryption key.
Base
> it on the date; allow, say, 5 days for the key to be valid. Then the
> key is useless to anyone else outside that 5 day window.
>
> Now you could put an I/O error on the CD as well; that makes it more
> difficult to copy the CD, and the "unscrambler" program can check
for
> that too. Joe Average now needs a valid key, the original CD and
needs
> to install in 5 days. Even then, he could still install it on a 100
> PCs in that period. So you could introduce a "machine key" so it
only
> works on his PC... and so on.
>
> Of course, once the software's installed on a PC it could be copied
> off. But that's true of every piece of software I've ever seen that
> doesn't have some form of extra check, such as a dongle (and even
they
> can be copied). That form of protection is the responsibility of the
> software author, not your company.
>
> You'll never stop software theft, all you can do is make it more
> difficult, but at a price. There's a balance between the cost of
> deterrence and the loss you think you're incurring. Work that out
> first, write code last.

I agree with all your observations and comments here, Alex...

Just I came up with a mad software piracy prevention idea the other
day...the idea is pretty simple...encode the customer's details -
including credit card number - into the executable...no, the
executable itself does NOT ever decode it or crack it open so there's
no way to reverse engineer how this code is stored or even where it
might be stored...the only people who can read it need a special
utility program that'll be able to see this "watermark"...the final
ingredient is to prominently make clear in BOLD TEXT and suitable
legalese that the executable contains _YOUR_ sensitive
information...so, it's in your _OWN_ interests not to copy it or let
unauthorised people at your copy...the legalese makes clear that in
running the software you accept responsibility in keeping the software
safe from piracy and that _should_ your copy be found on a Warez site
then, legally, you're culpable...

Not sure, though, that this scheme would actually be legal...although,
I don't really see why not as you're not handing someone's private
details to anyone but the individual themselves..._IF_ that individual
then copies it up onto Warez sites, that's not your doing, that's
their doing and the consequences that they're handing out their own
credit card information is upon their own heads...

Of course, you, as the software producer, have all these details and
the corresponding "watermark" codes in your customer database...thus,
when a Warez site shows up your software, you run the "watermark"
utility, find out the guilty party and then start your legal
proceedings against them...it was made perfectly clear all over the
place that the software had been "watermarked" like this and, as the
software producer, you did not send any sensitive, private information
to _anyone but the actual owner of that information (who sent it to
you to buy the software)_...goodness knows if this would actually pass
the test of the courts...but as long as the first time does, they all
will (legal precedent and all that :)...

The idea is to turn the whole thing on its head...rather than the
software producer being on the defensive all the time, you use the
customer's information to put them on the defensive that they'll NOT
pirate...

Morally, there is the slight issue that, in a sense, this could be
thought of as "blackmail" (look after my software on your computer or
else...! ;) but fully responsible users will suffer no problem or
penalty...you are only "blackmailing" them to keep within the bounds
of law, which is a social obligation and duty on them, anyway...you
can hardly complain: "they are unfairly making me comply with the law
by sending my information, that I gave to them, back to me in an
encoded form that no-one else but them can read, anyway!!"...like,
yeah, where's the problem with that? ;)

Mind you, I've only just thought of this and I've probably missed
something crucial...like some Civil Liberty or law not permitting this
kind of conduct...but, otherwise, it's a pretty sneaky way of stopping
piracy, eh?

Also, along the same lines, something else that could save a heck of a
lot of problems with viruses and running processes and stuff is a
similar "source" field, filled out by the OS indicating what program /
URL started up something or where it was downloaded from...a "file
history" attached to a file...hence, if something claiming to be a
Windows component has a history that doesn't come from
"WindowsUpdate.com" but some random IP address that whois's to
somewhere in Denmark or Sweden then say hello to Mr.Trojan Horse...if
one program tries to launch another legitimate program then the
"source" field is specified with the program / command line / registry
entry that launched it...so, at the very least, even if you were to
get stung, at least you'd have the information to disable / delete the
thing soonest possible...and, also, Email to Microsoft / McAfee and
those sort of people to help them discover the source of the problem
for them to take suitable actions (well, if they are just handed the
information about where something is coming from or how it launches
then, at the very least, it saves them all that time they must spend
working it out themselves...and if MS insist on "patches" rather than
good design, then, accepting that, we could at least get these
"patches" ASAP...mind you, the flaw in that plan is MS
themselves...they don't care sufficiently to make the effort, however
encouraged...well, not unless you attach a few million dollars to
it...they're just soulless mercenaries, after all, and always have
been ;)...

Beth :)

On Sun, 7 Sep 2003 00:36:04 +0100, "Beth"
<BethStone21@hotmail.NOSPICEDHAM.com> wrote:

>Just I came up with a mad software piracy prevention idea the other
>day...the idea is pretty simple...encode the customer's details -
>including credit card number - into the executable...no, the
>executable itself does NOT ever decode it or crack it open so there's
>no way to reverse engineer how this code is stored or even where it
>might be stored...the only people who can read it need a special
>utility program that'll be able to see this "watermark"...the final
>ingredient is to prominently make clear in BOLD TEXT and suitable
>legalese that the executable contains _YOUR_ sensitive
>information...so, it's in your _OWN_ interests not to copy it or let
>unauthorised people at your copy...the legalese makes clear that in
>running the software you accept responsibility in keeping the software
>safe from piracy and that _should_ your copy be found on a Warez site
>then, legally, you're culpable...

<snip>

A similar but tamer method I've used is to encrypt the user's name 
along with the registration key file.  When the software starts up,
the splash screen says "Registered to Joseph Schmoe" along
with the registration number.  The idea is that this will discourage
ordinary users from simply passing their keys around.  The key
encryption and validation must be good enough to prevent casual
crackers from figuring out how to create their own "valid" keys.

Of course, all this assumes that somebody wants the software
pretty bad in the first place.  
Haven't figured that one out yet... ;-)



Bob Masta
dqatechATdaqartaDOTcom
 
            D A Q A R T A
Data AcQuisition And Real-Time Analysis
 Shareware from Interstellar Research
          www.daqarta.com

Bob Masta wrote:
[snip]

> Of course, all this assumes that somebody wants the software
> pretty bad in the first place.  
> Haven't figured that one out yet... ;-)

[snip]

Indeed, I posted a few days ago asking the original poster whom he
was defending against and how well funded they are.  No response.  I
cannot avoid the suspicion that this whole thing is just a manager's
ploy to get a programmer out of his way for a while.

Terry.

Terrence Enger <tenger@iSeries-guru.com>
> Indeed, I posted a few days ago asking the original poster whom he
> was defending against and how well funded they are.  No response.  I
> cannot avoid the suspicion that this whole thing is just a manager's
> ploy to get a programmer out of his way for a while.
> 
> Terry.


If you're talking about me, I use Google Groups to read the post and I
can't see yours.

Eric.

Eric Minso wrote:

> Terrence Enger <tenger@iSeries-guru.com>
> 
>>Indeed, I posted a few days ago asking the original poster whom he
>>was defending against and how well funded they are.  No response.  I
>>cannot avoid the suspicion that this whole thing is just a manager's
>>ploy to get a programmer out of his way for a while.
>>
>>Terry.
>>
> 
> 
> If you're talking about me, I use Google Groups to read the post and I
> can't see yours.
> 
> Eric.
> 
> 


Okay, this time to all the groups ...

Please, what are you protecting the EXE against?  Whom against? How
well funded are they?

Terry.

Bob Masta wrote:
> Beth wrote:
> >Just I came up with a mad software piracy prevention idea the other
> >day...the idea is pretty simple...encode the customer's details -
> >including credit card number - into the executable...no, the
> >executable itself does NOT ever decode it or crack it open so
there's
> >no way to reverse engineer how this code is stored or even where it
> >might be stored...the only people who can read it need a special
> >utility program that'll be able to see this "watermark"...the final
> >ingredient is to prominently make clear in BOLD TEXT and suitable
> >legalese that the executable contains _YOUR_ sensitive
> >information...so, it's in your _OWN_ interests not to copy it or
let
> >unauthorised people at your copy...the legalese makes clear that in
> >running the software you accept responsibility in keeping the
software
> >safe from piracy and that _should_ your copy be found on a Warez
site
> >then, legally, you're culpable...
>
> <snip>
> A similar but tamer method I've used is to encrypt the user's name
> along with the registration key file.  When the software starts up,
> the splash screen says "Registered to Joseph Schmoe" along
> with the registration number.  The idea is that this will discourage
> ordinary users from simply passing their keys around.  The key
> encryption and validation must be good enough to prevent casual
> crackers from figuring out how to create their own "valid" keys.
>
> Of course, all this assumes that somebody wants the software
> pretty bad in the first place.
> Haven't figured that one out yet... ;-)

Yeah...but there's no "perfect solution", unfortunately...this just
helps get "better than even odds" in your favour...

And, actually, if the stats on piracy are to be believed then the
majority _is_ actually just people making copies for their
friends...the professional stuff is, basically, practically impossible
to defeat...they'll always find some sort of a way, if they are
determined to look hard enough...but, going by the stats on this
stuff, if it only defeats "casual piracy" rather than the professional
stuff, that's still a major, major win because that's apparently what
the majority is...

I won't say you'd recover the majority of your profits because, in
many cases, if they can't get it for free with piracy then many people
simply won't bother and won't instead be buying your product...but
it's the old statistical thing...if it only catches 10% then for
software that's used a lot that can add up to a substantial sum to
make it worth the effort...

Beth :)

Eric Minso wrote:
> Bob Masta wrote:
> > <snip>
> > 1)  Treat the final exe, including its PE header, as simple data.
> > A stub loader will decrypt it into memory and invoke some
> > Windows API function to run it as if from a file.  (I assume
> > such function exists, but haven't checked.)  This would put
> > the relocation burden on the API, but I would think it would
> > be vulnerable to crackers who would only have to watch
> > for that API function in their debugger, and grab the memory
> > image.
>
> I first tried this approach.
> Unfortunately, I didn't succeed in starting this program from the
memory.
> And using a temporary file is unthinkable.

You'll have to look into it, as I never actually used it to know how
well it actually works...but, under Windows, there is a switch thing
that can be passed to "CreateProcess" which requests that the
executable is executed from the swap file (used for running things
from read-only devices like CD-ROMs :)...

Although, why wasn't this working, I'm not sure...dynamically allocate
some memory in the address space of the main program, unpack into that
and then just "JMP" or "CALL" to this memory...that really should
work...

> > 2) You could do the PE relocation as part of your
> > decryptor, and jump to the start address.  The cracker
> > won't have an easy target for his debugger.  But you
> > will have the whole burden of the relocation.  You
> > may need special consideration of the fact that
> > Windows sees your loader/decryptor and the final exe
> > as one program, which it will load to 400000h like
> > normal programs.  To simplify that, put your code
> > after the (encrypted) exe and change the PE start
> > point to your code, after saving the true start point
> > which you can jump to when ready.  (Just like a virus!)
>
> That's what I am trying to do.

Well, is it working or not?

Beth :)

Terrence Enger <tenger@iSeries-guru.com> wrote in message 
> Okay, this time to all the groups ...
> 
> Please, what are you protecting the EXE against?  Whom against? How
> well funded are they?
> 
> Terry.


As I explained in a previous post, the protection is designed to
forbid the end user from using more than 3 programs between several
available ones. Look at that post for more information.