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

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

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

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
> 
> 
> 

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

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

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

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

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

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