www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Getting the MAC

reply Manfred Nowak <svv1999 hotmail.com> writes:
Hi,

I want to bind the executable of a D-program to a specific machine.

Specifically I want to bind the executable to MAC of the network card.

Beside remarks that java is not capable to do that :-), because the MAc is
one layer down than java can reach, I have found some examples on the net,
especially one in C++. But I cannot convert it to D because I cannot find
the netbios-call, which is necassary.

What am I doing wrong?

-Manfred
Jul 02 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cc31pk$154s$1 digitaldaemon.com>, Manfred Nowak says...

Hi,

I want to bind the executable of a D-program to a specific machine.


I hate programs that do that. And in any case it's a waste of time - I've never
yet found a copy-prevention strategy that someone else hasn't figured a way
around.

Arcane Jill
Jul 02 2004
next sibling parent Scott Michel <scottm aero.org> writes:
Arcane Jill wrote:

 In article <cc31pk$154s$1 digitaldaemon.com>, Manfred Nowak says...
 I hate programs that do that. And in any case it's a waste of time - I've never
 yet found a copy-prevention strategy that someone else hasn't figured a way
 around.


It's not a complete waste of time, actually. In the peer-to-peer realm, 
one often wants to create a unique peer ID, which is usually done by 
running the (primary) IP address, MAC, and time-of-day through SHA1 or 
MD5. Granted getting a GUID is probably faster, but sometimes these 
Linux folks have their way of doing things, come hell or high water.


-scooter
Jul 02 2004
prev sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
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.

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.  

Not to hexedit out all usage control branches and using the executable on
a machine missing an interface containing the right MAC guarantees
executions that randomly generate wrong results of randomly choosen
severeness.

Finally, because I do not sell programs anymore, I would recognize it as
an honour if somebody treats himself as unable to reproduce the thoughts
behind an executable for programming his own version, but only able to
betray a dumb machine by using much more power than I have invested into
the original executable.

In the country I live in there is a law, that if someone produces an
object out of materials she/he does not own and the produced object has
much more value than the used materials, then the owner of the materials
looses the right to get those materials back. I consider a hexedited
version as mentioned above as a sure case of the application of this law :-)

-Manfred
Jul 03 2004
parent reply Sebastian Czech <sebastian.czech arcor.de> writes:
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
Jul 04 2004
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
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
Jul 04 2004
parent reply Sebastian Czech <sebastian.czech arcor.de> writes:
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
Jul 04 2004
parent Manfred Nowak <svv1999 hotmail.com> writes:
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
Jul 06 2004
prev sibling parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
Yeeeeuch!

Easiest way in Win32 is to extract the MAC from the results of createGuid()
~ the last 12 chars represents the primary MAC address. Otherwise, the next
easiest is via iphlpapi.lib which I just couldn't find anywhere the other
day ...

- Kris


"Manfred Nowak" <svv1999 hotmail.com> wrote in message
news:cc31pk$154s$1 digitaldaemon.com...

 Hi,

 I want to bind the executable of a D-program to a specific machine.

 Specifically I want to bind the executable to MAC of the network card.

 Beside remarks that java is not capable to do that :-), because the MAc is
 one layer down than java can reach, I have found some examples on the net,
 especially one in C++. But I cannot convert it to D because I cannot find
 the netbios-call, which is necassary.

 What am I doing wrong?

 -Manfred
Jul 02 2004
next sibling parent Daniel Horn <hellcatv hotmail.com> writes:
Why bother: Most modern network cards let you change the mac address at 
a whim.  My ISP blocked my MAC address for a while (they denied this on 
the phone) so I just had the bootup script change my macaddress to some 
combination of 0xbadfood55555555 or what not.
you do that with ifconfig I believe :-)
man ifconfig turned up:
hw class address
               Set  the hardware address of this interface

The only person copy protection hurts is the legitimate buyer, not the 
common thief: the common thief will already have hex edited that out of 
the exe: the buyer will have to modify his boot-up scripts to change his 
enet address.

Kris wrote:

 Yeeeeuch!
 
 Easiest way in Win32 is to extract the MAC from the results of createGuid()
 ~ the last 12 chars represents the primary MAC address. Otherwise, the next
 easiest is via iphlpapi.lib which I just couldn't find anywhere the other
 day ...
 
 - Kris
 
 
 "Manfred Nowak" <svv1999 hotmail.com> wrote in message
 news:cc31pk$154s$1 digitaldaemon.com...
 

Hi,

I want to bind the executable of a D-program to a specific machine.

Specifically I want to bind the executable to MAC of the network card.

Beside remarks that java is not capable to do that :-), because the MAc is
one layer down than java can reach, I have found some examples on the net,
especially one in C++. But I cannot convert it to D because I cannot find
the netbios-call, which is necassary.

What am I doing wrong?

-Manfred
Jul 02 2004
prev sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
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
Jul 03 2004
next sibling parent reply Sam McCall <tunah.d tunah.net> writes:
Manfred Nowak wrote:


 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.


"Direct access to hardware" doesn't mean "nice high level APIs to 
manipulate all hardware". You can always use inline asm.
Sam
Jul 03 2004
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Sam McCall wrote:

[...]

 You can always use inline asm.


In case you mean especially me, your statement is not true :-)

However: where is the proof that direct access of _any_ hardware is
possible with current inline asm, especially hardware, that is produced
for the usage under a 64-bit OS. Where is an example that _all_ features
of some randomly choosen currently existing hardware are accessible via an
executable generated from a D-program by a D-compiler?

-Manfred
Jul 04 2004
parent Sam McCall <tunah.d tunah.net> writes:
Manfred Nowak wrote:


 Sam McCall wrote:
 
 [...]
 

You can always use inline asm.


 
 In case you mean especially me, your statement is not true :-)


Haha... me neither ;-).
I just meant that this was the sort of thing meant by direct hardware 
access, rather than high level interfaces.


 However: where is the proof that direct access of _any_ hardware is
 possible with current inline asm, especially hardware, that is produced
 for the usage under a 64-bit OS.


I don't think DMD currently supports 64-bit archs, so I assume you're 
talking about GDC (inline asm is implementation defined IIRC), which 
presumably allows some appropriate 64 bit assembly language.
Any program can be disassembled, so assuming that the hardware can be 
accessed from some user-mode program, just disassemble it, wrap the asm 
in D, and there you go! A constructive proof, no less! :P


Sam
Jul 04 2004
prev sibling next sibling parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
<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
Jul 04 2004
parent Manfred Nowak <svv1999 hotmail.com> writes:
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
Jul 04 2004
prev sibling next sibling parent reply Andy Friesen <andy ikagames.com> writes:
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
Jul 04 2004
parent Manfred Nowak <svv1999 hotmail.com> writes:
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
Jul 04 2004
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"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.
Jul 08 2004