On Sun, 04 Jul 2004 08:43:04 +0200
Manfred Nowak <svv1999@hotmail.com> wrote:

> Arcane Jill wrote:
> 
> > I hate programs that do that.
> It is legal to hate programs :-)
> 
> 
> > And in any case it's a waste of time
> Maybe. However, the biggest waste of time is playing --- have you ever looked around? And if you tolerate playing, then please let me play with a binding mechanism :-)
> 
> 
> > - I've never yet found a copy-prevention strategy that someone else hasn't figured a way around.
> My intent is not a copy protection scheme, but a usage protection scheme.

what is the diff. between an copy protection and an usage protection?
you mean you can not prevent copying - right how should you prevent someone
to copy bytes - so you prevent usage?

> It is clearly possible to mimic the MAC that is necessary for a particular program, but ever heard of a network, that is able to function properly if there is a MAC so that for all machines in the network there is an interface that has this MAC? Hint: if so, then what is the MAC good for?
> 
> It is clearly possible to hexedit branches out of an executable, but the effort to find this branches is tremendous and I believe, that everyone who is capable of doing so, has enough common sense to know, that this is a severe intrusion into a private property. To further disencourage a person of doing hexediting I believe that it suffices to give notice to that person, that the usage controlling branches are distributed over the code in several places, where the places and the method of the usage control is choosen machinally and randomly, therebye forcing the hexediting person to examine every branch of the program to be sure to find all usage controlling branches.

This does NOT work. Lets take linux as example:
- how to find the place in the bin. where it reads the MAC?
  Ohh an real hard job that could take some minutes (but only because
  the disassembler might be slow) ;) you need to find an place with
  something like:

	push    0
	push    2
	push    2
	call    socket

	push		; an ifreq struct
	push    0x8927	; SIOCGIFHWADDR
	push		; the socket descriptor
	call    ioctl

(ok its not what gcc 3.x would produce but lets ignore this -
the 2nd ioctl argument can also be 0x8912 but lets also ignore this)
the most difficult part to find this is to type "[ls]trace" and grep
through the listing.

in your protection scheme it would be enough to find this code and change
it to move any number(MAC) into the ifreq struct.
Even worse ... you could write an own ioctl "lib" and preload it to always
return the "needed" MAC.
And as already mentioned you could simply change the mac.

So your idea to distribute all copy protection branches over the whole bin.
has the problem that you need to get the MAC somewhere. And it it not hard
to find, you dont need to look at an single asm line - you only need
[sl]trace. So if i wanted to break your protection - why not simply change
the socket/ioctl call?
There is something missing - an checksum. But if the checksum is in the
binary it is useless. So what you maybe want is an alien controlled tcg/tcpa
computer. (with an little green alien with an railgun in the computer that
kills you if you use your brain in the wrong way)

I dont know much about the windows world with copy protections but i am sure
it will never work.(as long as there is no alien in the computer)
Maybe software wants to be free.

And i dont think that the use of ifconfig can be forbidden.

Sebastian

<sigh>

Was simply trying to be helpful Manfred; since you'd been away I'd forgotten that one shouldn't bother ...

<double sigh>



"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:cc85td$2tji$1@digitaldaemon.com...
> Kris wrote:
>
> > Easiest way in Win32
> [...]
>
> This is not a solution:
>
> 1. D is not intended to run on Win32-Systems solely. If so, one could restrict oneself to use one of the system commands to get the MAC. In fact currently D is restricted only to a type of CPU.
>
> 2. In the comparison table of D the row "Direct Acces to Hardware" is flagged with "Yes" for D. If getting the MAC is not possible with D, provided that the executable of the intended D programm is to run on that specific type of CPU, which D is currently restricted to, then the comparison table for D is plain wrong.
>
> -Manfred

Kris wrote:

[...]
> <double sigh>
:-) Your help is appreciated very much! Please forgive, when my words sound too harsh. I am honestly trying to establish good relations but the years on duty of fingerpointing and stiring in the open wounds of develepors have left scars on my wording.

-Manfred

Manfred Nowak wrote:
> Kris wrote:
> 
> 
>>Easiest way in Win32
> 
> [...]
> 
> This is not a solution:

I'm not convinced it's a problem. :)

> 1. D is not intended to run on Win32-Systems solely. If so, one could
> restrict oneself to use one of the system commands to get the MAC. In
> fact currently D is restricted only to a type of CPU.

GDC runs on OSX, last I checked.

> 2. In the comparison table of D the row "Direct Acces to Hardware" is
> flagged with "Yes" for D. If getting the MAC is not possible with D,
> provided that the executable of the intended D programm is to run on that
> specific type of CPU, which D is currently restricted to, then the
> comparison table for D is plain wrong.

D has 'direct access to hardware' in that it can, in the absense of a resource-managing OS (as is the case with a kernel written in D), touch the hardware.

Any other definition for the term renders it meaningless, as modern operating systems (rightly) block attempts to use the hardware without going through the proper channels. (the API that the operating system provides)

 -- andy

Sebastian Czech wrote:

[...]
> Maybe software wants to be free.
Yeah! Great word! And you are right: if there is only one way to get the MAC, then the intended usage protection is only a sandstorm in a water bottle, because that betrayer of dumb machines will be able to find the relevant pieces of code. However, am I allowed to believe, that you did not catch my idea in whole? I said "give notice to". Thereby I mean, that the usage protection itself may be a fake! That betrayer of dumb machines may find pieces of code that seem relevant to him, but if she/he does not detect if there are valid branches to that code any change may be in vain, because that pieces of code will never be used. I do not have any problems to betray a betrayer of dumb machines.

One more: ever heard of self modifying programs? How do you want to make a grep over them?


> And i dont think that the use of ifconfig can be forbidden.
Upps. Is ifconfig able to prepare a machine to send one MAC when a call is for an internal service and another MAC fpr an external service?

-Manfred

Andy Friesen wrote:

[...]
> D has 'direct access to hardware' in that it can, in the absense of a resource-managing OS (as is the case with a kernel written in D), touch the hardware.
[...]

Yeah! That is a core burning argument.

-manfred

On Sun, 04 Jul 2004 22:14:26 +0200
Manfred Nowak <svv1999@hotmail.com> wrote:

> Sebastian Czech wrote:
> 
> [...]
> > Maybe software wants to be free.
> Yeah! Great word! And you are right: if there is only one way to get the MAC, then the intended usage protection is only a sandstorm in a water bottle, because that betrayer of dumb machines will be able to find the relevant pieces of code. However, am I allowed to believe, that you did not catch my idea in whole? I said "give notice to". Thereby I mean, that the usage protection itself may be a fake! That betrayer of dumb machines may find pieces of code that seem relevant to him, but if she/he does not detect if there are valid branches to that code any change may be in vain, because that pieces of code will never be used. I do not have any problems to betray a betrayer of dumb machines.

yes maybe you are right and i do not really understand what you are talking about. i only had some ideas how to detect your MAC code (on linux)... sorry i have no idea on how to read an MAC under win16/32, atari os, lips machines, c64, dos or what ever. (you are allowed to call me ignorant)but i know that the number of ways to read the MAC under linux (unix) is limited. (as long as it is limited i can generate function-fingerprints and you are lost (because with an fingerprint i could find them in ~0 time))

> One more: ever heard of self modifying programs? How do you want to make a grep over them?

this is nothing you mentioned in your 1st posting - i only responded to your posting - not again every possible solution. Ok - how to identify self modifying code - sorry i can again speak only about unix (oos retro unix clones written in c - like linux...) how do you want to prevent me to debug my kernel or insert debug prints into my kernel (which displays every kernel call (like ioctl, socket or everything else???)) btw. it still does not protect you from using preloaded libs... (yes i know that it does not work under win32 but i dont care)

> > And i dont think that the use of ifconfig can be forbidden.
> Upps. Is ifconfig able to prepare a machine to send one MAC when a call is for an internal service and another MAC fpr an external service?

sorry maybe there is an language barrage -> i dont understand the question - if you have an fundamental (1st. ever working) copy protection send me an working elf/linux bin. (protected with your code - and the right to disasm it... and i will try to break it)

btw. if you found the working copy (or in you words usage) protection
solution - why dont you sell it? i am sure you could make billions of $.
best wishes for this - but i am not very optimistic that it works.
but maybe you can surprise me - i really hope so.

> -Manfred

Sebastian

Sebastian Czech wrote:

[...]
> this is nothing you mentioned in your 1st posting
You are right. First I only intended to prevent spreading of alpha and prealpha versions of my played out programs and the answers in this thread, yours included and very appreciated, inspired me to think further. Your well thought out arguments brought me to counter arguments and as it looks like, we can settle this thread.

One more remark: I do not see a clear obstacle, that hinders the mechanisms that are used from outside to attack machines insides to be used inside for a protection against the attacks from outside, i.e. why are viuses, trojans and the like unthinkable as a protection scheme? The same efforts that are taken now to prevent infections of the sane state of useful software can be used to attack the sane state of attacking software and turn it into an insane state by using their own methods, i.e. turning it inable to infect any useful software anymore.

If software wants to be free, I really like this wording of yours, then it
may also want to fight for its freedom by means of war against
other software, which wants to make a slave out of it. :-)

> how do you want to prevent me to debug my kernel or insert debug prints into my kernel
[...]
> using preloaded libs
[...]
Are you noticing, where you are going to? (rofl: where do you want to go
today?) Are you turning yourself into a cloak around the CPU,
vanishing when power is shut down?

All of your remaining arguments are equvivalent to integrate that "usage protected" software into the machine for which it is not targeted. Thereby turning your multipurpose machine into an emulation of the original target machine. That _is_ usage protection, or copy protection if you do like that wording more: how do you want to convince a court, that by some accident your machine started to be an emulation of another machine? Useles for any other thing than to run a usage/copy protected peace of software for which you do not have any possessive rights?

How do you want to convince others, that they have to convert their machines into emulators of a specific machine also?

How do you want to hack your kernel to be able to handle the different MACs needed by the threads of your multiuser multithreaded OS?

I strongly believe, that the effort to use and at the same time _hide_ this usage of such usage protected software on any other than the target machine by far exceeds the effort that has to be invested into the executable. And this effort is not able to be copied as well.

[...]
> why dont you sell it?
[...]
Why should I? Maybe software wants to be free? :-)

-Manfred

"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:cc85td$2tji$1@digitaldaemon.com...
> 2. In the comparison table of D the row "Direct Acces to Hardware" is flagged with "Yes" for D. If getting the MAC is not possible with D, provided that the executable of the intended D programm is to run on that specific type of CPU, which D is currently restricted to, then the comparison table for D is plain wrong.

D the language allows direct access to hardware. However, on many operating systems like Win32, this access is blocked, but that is not a problem with the language.