Hi All,

I search the net to find a way to detect if the MAC address spoofed by any spoofing tools like SMAC and others. But, I didn't find any approch. So, please help me because I would like to use the MAC address as a hardware ID to my software protection.

Thanks in advance,

KSA

You can't prevent someone from having their system report a false MAC address to your software.

So, what's your suggestion about the best hardware ID information that my protection will based on. I tryed the drive hardware serial number but it fails with RAID systems (I used DiskId32, It's ok with IDE and SCSI).

Howdy,

How many people do you think actually know how to spoof a MAC address?

I would venture not many. Then again there are other ways to do what you want to do.
Just remember, nothing can be 100% so you need to weigh which method will yeld the lowest amount of theft.

Simple enough?

Woodmann

Protections tied to the hardware are not very popular with users for a variety of reasons.

Actually I'd like to challenge that. There must be some way to determine whether the MAC provided by APIs (which can be hooked etc to return an "untruth" is different to the physical MAC. My thoughts would be along the lines of routing and arp cache/tables, because those absolutely rely on truth.

If you ping then query a remote host's arp table, you will be able to match your IP to your "real" MAC as seen by the remote host. Conversely if you do the reverse of an arp poison attack, whereby you broadcast out the IP of the local machine plus the MAC returned by the APIs, if the returned MAC is not "the truth" then you've poisoned your own arp cache, thus destroying the routing on your subnet, which should be possible to test by sending out some ICMP.

I haven't thought it through in detail, but the fact that MACs can be validated remotely through arp requests does appear lend itself to MAC "truthiness" detection.

Acknowledge that this is way OT for what the poster seems to want to achieve. I'd also point out that SMAC (never used it) appears to actually change the MAC address stored on the card. This isn't spoofing, it's legitimate and allowed, and an actual change to the NIC. As such it's undetectable because there's nothing to detect. It's like reflashing a DVD player from region 1 to region 2. The DVD player doesn't have a "spoofed region", it really is region 2.

Does the OP understand the use of MAC addresses and their allocation?

No, they can't be validated remotely.

MAC addresses can be changed very easily. On Windows there are a number of tools to do it (and it's just a simple registry edit - you don't need these tools).
http://www.google.co.uk/search?q=change+mac+address+tool
It's a simple registry edit and the ability to change the MAC address is a documented feature:
http://msdn2.microsoft.com/en-US/library/bb625339.aspx

Most other OS's have some simple way of accomplishing the same. On Linux you can use the common configuration tools such as ipconfig. eg..

ipconfig $interface hw ether $newmacaddress

The changed MAC will then be the MAC that any remote hosts sees with any network chatter including ARP.

Actually, I developed an application to a company has more than 50 servers. I would like to lock my software to one server and disallowed them to install it to other servers. I already using the drive hardware serial number, but it fails with RAIDs. I tried the motherboard serial number, but also the servers returned the same serial number. So, I tried the MAC address, but I see it can be spoofed easily. From your point view, What is the best way to protect my software.

For servers i would choose Hostname, Product ID and CPU serial.

CPU Serial is a good idea. But, it's disabled by defalut for those servers.

If the servers are connected to a lan i would also check the other servers if they are running the application. If they do i would compare the serials (in hash+salt form) and if the serials are the same ban. Last option will be to add a dongle in the overall protection, some dongles also have network features.

Don't give it to anybody. Seriously.

Have you read +Fravia's "How to protect better"?

I agree with you, This is the best protection can be done.



Yes, I read it.


I'm planning to use a dongle as a hardware protection.

So, let us go back to my first question, Is their a way to detect if the MAC address of the server spoofed or not?

Thanks all of you for your's helpful answers.

I'm sure you know the answer, seeing as you have read all the posts in this thread...

Oh wait.

Best way to protect and still sell it, since not distributing it has already been covered?

Put a simple reg/validation check in the code and then sell it for a reasonable price so that the end user(s) won't be tempted to "crack" it.

If your customer truly is a corporation with 50+ servers then chances are very good they would rather buy additional copies of a program than invest the time and effort to circumvent validation.

If you've already sold them one copy at an outrageous price then maybe you should offer them additional copies at a discount...

Sorry, I think you misunderstood my post (perhaps because I went off on a tangent from the OP's question).

When I first read the original post, I thought the question was - "How can I prevent API hooking or other techniques preventing me from retrieving the actual MAC address of the NIC in the machine".

In other words the problem I was looking at was how to identify whether the MAC returned by <insert proper win32api call here>GetMACAddressOfTheNICInMyMachine()</insert> is the MAC address used by the hardware itself. Imagining a poor protection system that relies on the MAC address to validate the machine its installed on, this would be important as a simple bypass would be to return the good-boy MAC every time via a hook (or other appropriate technique).

So yes, your post is absolutely accurate - a MAC can be changed easily. But it's not the point I was trying to discuss, namely using standard networking (arp) to validate API returned info.

*edit* I've just read this post again and I still don't feel it's clearly explaining what I'm getting at. Never mind.

Hi Silver,

This is what I want. Is there a way to read the REAL MAC address (Hardware MAC address) even the current MAC address (fake one) spoofed by any spoofing tool like SMAC.

Thanks,

Clever ideas, Silver. I stand humbled

Staying on topic: the HDD serial number as returned by GetDiskVolumeInfo is trivial to spoof, there are a few programs floating around that will do it permanently.

See: http://www.soft32.com/download_94637.html for an example

(I have done the same myself on a few occasions to ... test stuff )

So in theory the MAC address and the HDD serial are both bad ideas to base protection on. If you wanted to go all out you could do this:

SHA2(MAC + HDDSERIAL + PRODUCTID)

Where ProductID is the windows buffer from the registry, and SHA2 is your favourite secure hashing algorythm. This would mean someone would need to spoof both mac address, hddserial and the windows productid which would probably break a lot of shit if all the computers were running on the same network (as you say they would be).

This would be far too annoying to replicate and could provide a fairly secure layer of protection, provided the binary itself is also protected against tampering

How about looking at this from the company's point-of-view:
What happens if the network adapter is changed? if the hd is changed or software gets migrated to another hd? if they upgrade their os?
Do they know that they're buying software that could become useless every time the server goes through some kind of refitting or maintenance?

My idea would be to buy the cheapest usb key or hd you can find and have your program check for that serial number instead. That makes a cheap instant dongle protection. Tell the company it contains some kind of "magic" or "invisible" secret license keyfile or something like that.

Even better idea would be: Don't work for a company that you know is going to scam you.
If they go as far as reversing your program to figure what to emulate or spoof, they're really motivated.

TiGa

In all software protection there is a trade off between security and useability.

In this case, sure the program will become unlicensed when the network card is changed, or HDD is changed.

But in a company server these are both fairly rare occurances and so long as the company are aware of these limitations, most are quite happy to make a call to retrieve the new serial number.

Its not such a burden as you may think. If a customer has to call the software company to gain a legit key once or twice a year its not a big deal...

The beauty of something like this is that is very straight-forward, customizable and scaleable to nearly any level.

I was about to say you hadn't read the replies in this thread, then I looked at that SMAC tool in more detail.



This FAQ answer is technical rubbish, but clearly it doesn't update the MAC in the EEPROM on the card, which is what I thought it did. What it appears to do is to register a virtual network card with the o/s, just like how VMWare or NLB works. Unfortunately the site doesn't fully explain what SMAC does, but clearly it must mess around with the routing to ensure all network traffic goes out the virtual card rather than the physical one (as far as Windows is concerned).

So actually you have a separate problem here - as far as everything except the SMAC driver is concerned, the SMAC network card is a real card. On that basis I bet the SMAC card requires its own IP address and doesn't share the IP of the physical card, as that would really screw things up.

So here's another suggestion. Why not send a packet out on the subnet broadcast address then check the ARP table for all the known MAC addresses. Compare each of those MAC addresses to the MAC addresses of all the network adapters in your machine. If you find 2 MAC addresses in the ARP table that match 2 network adapters in your machine, you've got something funny going on.

Here's the reason why. In a dual-homed PC (one with 2 network cards), each card will normally be addressed in different subnets. It's useless to address 2 cards in the same subnet as the routing will be screwed up. Sending a packet out to the broadcast address will cause every machine on the subnet to respond, which will populate your ARP table with the MACs of all the machines on the subnet.

Here's an example:

My machine, physical NIC, MAC: FF:FF:FF:FF:FF:01
My machine, fake SMAC adapter MAC: FF:FF:FF:FF:FF:02
Bob's machine, same bit of wire/subnet, MAC: FF:FF:FF:FF:FF:03
Dave's machine, same bit of wire/subnet, MAC: FF:FF:FF:FF:FF:04

Assume we're all addressed in 192.168.0.1 to 0.4, class C subnet.

I clear my ARP cache, then ping 192.168.0.255. I don't care which adapter this goes out of, but for argument's sake let's say it goes out my physical NIC, IP 192.168.0.1.

I'll get a response from 192.168.0.2, 0.3 and 0.4. That means in my ARP cache right now I have my two MAC addresses and the MAC addresses of Bob and Dave's machines. Because I got responses from Bob and Dave I know I'm connected to a bit of wire and I'm on a valid subnet.

So, in code, I'll scan through the ARP cache and check if the MAC addresses match any MAC addresses on my local machine. If more than one matches (in this case, 192.168.0.1 and 0.2), I have more than one adapter connected to the same subnet which pretty much guarantees something is funny.

This all falls down on 2 assumptions. First, that SMAC works how I think it does, and second that VMWare exhibits the exact same behaviour and so would fail this test.... I think there's another flaw in my logic somewhere but I can't quite spot it.

This is called the Disk Volume Serial Number and it's very easy to change. I talked about Drive Hardware Serial Number.



Thanks Silver for your detailed idea. But, It's still an idea.

Hi Silver, I didn't misunderstand your post above. It appears you're unaware of the functionality involved in changing a MAC address within Windows. I can explain how this works. See inline comments. There is no virtual adapter or any hacks like that. It's a function provided by Windows which the drivers of the NIC use. Some of them don't support it, most of them do though - some even enable it as a configuration option in the advanced configuration dialog of the driver.



The page below explains this in a little more technical detail, although I did link you to NdisRedNetworkAddress previously. It doesn't involve anything like messing with routing and virtual NICs. It uses NdisReadNetworkAddress
http://msdn2.microsoft.com/en-US/library/bb625339.aspx

Heres an explanation.
http://www.klcconsulting.net/Change_MAC_w2k.htm#how

"NdisReadNetworkAddress(...) is called by the network adapter driver to obtain a user specified MAC address in the registry. After the driver confirms that there's a valid MAC address specified in the registry key, the driver then programs the MAC address to its hardware registers to override the burn-in MAC address."




No it doesn't mate. Since the drivers of the NIC instruct it not to use it's built-in MAC but to use the software configured one you don't have this issue.



You will only ever see the software configured MAC address, the NIC simply won't send it's original MAC address. There also won't be an additional adapter added as the result of changing the MAC address, since it's a registry entry which enables the spoofing.




It doesn't work the way you think it does.



This one is made redundant by the first but FWIW VMWare doesn't work the way you think it does either.

Silver, further info:
NdisReadNetworkAddress - http://msdn2.microsoft.com/en-US/library/bb625339.aspx
How to do this without a tool like SMAC - http://www.klcconsulting.net/Change_MAC_w2k.htm#method2

Hope that helps mate.
Cheers.

There are also various motherboards' BIOS that let you change the MAC Address for the onboard NIC with a combination of keys. The NIC on these boards comes with an empty MAC/GUID.

Zeedo, great post, thank you. This was the bit I didn't realise was possible:



Without this feature I couldn't understand how you could pull a frame off the wire that was destined for a different MAC address without putting the card into promiscuous mode or using multicast MAC addressing (like NLB).

Is this a relatively new feature of NICs (eg, in the last 5 - 10 years), or has it always been standard? I'm not much of a networking person, and less so in recent years...

It's been around pretty much from the beginning. Creating and testing network devices would be a bit of a hassle without building in some sort of ability to control them like this.

Glad you found it useful mate.
Cheers.