Spoofing Leopard’s MAC address
posted in the early evening by Constantinos. Filed under Code, OS X, TerminalThis post was originally published in 2008
The tips and techniques explained may be outdated.
There are many legitimate reasons why someone would want to spoof a system’s MAC address. In my case, my University binds our network ports to a specific computer’s MAC address, and only allows you to reset that address once a week. My problems start when I want to switch my two computers for whatever reason, and connect my smaller iBook to the wall (let’s say I want to keep a web server online, but wish to take my MacBook Pro on the road).
In Tiger, it was very easy to spoof a MAC address:
sudo ifconfig en0 ether 00:00:00:00:00:00 |
where en0 is the network interface you wish to change the MAC address of, and 00:00:00:00:00:00 is the target MAC address. With Leopard, that line no longer works. No matter how much I searched, I couldn’t find a solid alternative. Turns out, it’s extremely simple:
sudo ifconfig en0 lladdr 00:00:00:00:00:00 |
That’s it!
Note: This has been tested under 10.5.1 with both en0 and en1, and at least for the wired interface it works as advertised.
1. Comment by jon
on 29 Mar 2009 @ 10:39 am
nothing works
2. Comment by ConMac
on 3 Apr 2009 @ 5:56 am
Using an Unibody MacBook 2.4 GHz running 10.6, I though that I was never going to get it to work. The key is that your Airport MUST BE ON, AND MUST NOT BE CONNECTED TO A NETWORK. This allows you to use the normal sudo ifconfig en1 lladdr [MAC] successfully!
3. Comment by Deviacium
on 24 Apr 2009 @ 8:13 am
Mac Address is easily spoofed on _wireless_ networks (i assume – considered _wireless_ by the OS – more later). For airport try
sudo ifconfig en1 ether aa:bb:cc:dd:ee:ff
sudo ifconfig en1 lladdr aa:bb:cc:dd:ee:ff
if this doesn’t work try this:
/System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport -z
/sbin/ifconfig en1 lladdr 00:00:AA:8b:51:15
/System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport –mac=00:00:AA:8b:51:15
/sbin/ifconfig en1 down
/sbin/ifconfig en1 up
/System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport -s
/System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport -a
/System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport -a
Should work for any mac.
And wired interfaces simply do not allow to change mac (or whatever – it says nothing, just doesn’t change address).
Concerning wireless and wired interfaces. I got usb wi-fi dongle from d-link – and it is considered _wired_ interface. So i cannot change my mac on it.
Still searching solution.
4. Comment by Bruno McStick
on 2 May 2009 @ 10:59 pm
Hi guys
I’m on ethernet (not wireless – just a wired linksys router) and am still unable to spoof my mac’s address under OS X 10.5.6.
It gives me the option to put in my p/w but after I do this the standard terminal line reappears, and when I enter the code to check the current mac addres it just re-shows my original ‘real’ address.
Any hints or tips would be really appreciated as I’ve tried following the above to an extent but am now just totally lost!
5. Comment by nelfisch
on 17 May 2009 @ 7:20 am
Hej
im trying to run this methos on my macbook unibody 2,0 ghz with leopard 10.5.6.
but it wont work, i tryed even all of ur suggestions.
any more solutions?
p.s: i wanna change the mac adresse of my aiport(wireless)
mysteriös
6. Comment by switch
on 22 Jun 2009 @ 4:10 pm
works with osx10.5.7 on latest “all silver” macbook pro. On both en0 and en1 (wired and wireless). The network interfaces have to be disconnected but switched on at the time of mac spoofing 😉
7. Comment by incessantmace
on 21 Jul 2009 @ 4:10 pm
The issue here is the 802.11 standard and vendor implementation.
Firstly there are two types of Radio chipsets being manufactured today.
Hardware based and Software based.
This distinction is very important to note as managing the bulk of 802.11 traffic on your machine can be done in either software (depending on your wireless chipset) or hardware (again chipset dependent). When I say software I mean the OSX kernel may be responsible for some of the interface and traffic management and sometimes only in certain situations. Its a very complex issue to explain without launching in to the 802.11 standard in depth. I’ll try to summarize below:
The 802.11 standard is complicated. Very complicated. Just consider for a moment that 802.11 is a layer two protocol that has its own built-in-retransmission and fragmentation support (not even mentioning the optional power-savings mode). Pushing all this complexity down into layer two has created some design issues that have never come up before in commodity networking hardware-namely, where to draw the line between hardware and driver and where to draw the line between driver and OS proper. Where these lines are drawn has very real impact on what you can persuade a chipset to do that it might not otherwise do. (ie: change your mac address or spoof a packet for injection etc)
When your operating system wants to send an Ethernet packet, the kernel forms a simple 14-byte Ethernet header, prepends it to the layer three packet (IP in most cases) and hands it off to the Ethernet hardware to put it on the wire. In the worst case scenario, the Ethernet card causes a collision (or two), backs off randomly, and transmits until it succeeds.
Now what happens when your operating system wants to send out an 802.11 data packet? Well, the kernel might create the 802.11 header itself, pass it off to the card along with the payload, and forget about it. But what happens then? A lot. There are 126 pages of state transition diagrams inside the 1999 revision of the 802.11 standard describing exactly what should happen if you’re curious, but here are a few highlights.
First, the card/driver needs to ensure that the media is not physically busy at the time the sender wishes to transmit. This is the easy part and is called a clear channel assessment in the standard.
Second, the card/driver also is responsible for keeping track of various other state information related to media access control. One example is to make sure that it doesn’t step over another client’s Clear To Send (CTS) window. Once the card has decided it’s okay to transmit, it needs to switch the radio into transmit mode (recall the cards are half-duplex) and send the packet. Immediately after transmission, the card switches back into receive mode. If the card/driver does not receive an acknowledgment (ACK), then it needs to back off and retransmit. There are other factors it must consider as well (Request To Send (RTS) thresholds, fragmentation, and so on) but this should get the point across.
The question remains, however: who is responsible for all that overhead related to media access control, the driver (software) or the chipset (hardware)? If the answer is software, then you might be able to bypass as much of the protocol as you would like and transmit arbitrarily crafted packets (forged deauthentication packets, for example). If the answer is hardware, you are generally at the mercy of the chipset as to what you may or may not transmit(this includes having the ability to do a simple mac address change). If all you want to do is get a card into monitor mode, this may not be such a big deal. As soon as you want to start injecting packets (and many new techniques that take advantage of this are surfacing), it becomes very important. If the chipset itself (hardware) is responsible for generating control or management packets, it might not let you send them yourself.
In summary then. When you tell an Ethernet card to send a packet, you are telling it to send the packet. It’s not going to examine the packet to see if it likes what you are trying to send, and it’s not going to wait around very long to transmit. When you tell a wireless card to transmit, you are suggesting it start transmitting at its soonest possible convenience, assuming it agrees with your payload.
This extends to any form of interface management as well. When you tell your ethernet card to change its mac address you’re merely suggesting it. If it feels like it, depending on what kind of radio chipset is in your macbook pro and who’s responsible for interface management and other low end functionality, you will either be successful at changing your mac address or you won’t. Its down to the type of radio chipset in your macbook pro and the driver/hardware management boundary.
With your wired ethernet card these problems don’t exist. It is managed entirely in software through the osx driver. When you tell it to change its mac address you are ‘TELLING’ it. Its not a suggestion. It must conform. Its a trivial matter to change wired mac address and an entirely different matter altogther on the wifi side.
This explains why you keep getting varying results that make little sense and have no pattern. Its got nothing to do with your version of osx and everything to do with your radio chipset.
I hope that clears it up somewhat.
8. Comment by Wayfarer
on 21 Aug 2009 @ 7:11 pm
For some reason, I cannot get this to work on 10.5.8 on the newest firmware for everything. I have a new Macbook Pro, 17″, that came out summer 2009. Anyone have any thoughts?
9. Comment by foundit
on 23 Aug 2009 @ 10:38 am
download changemac 1.6. Liitle gui that changes it on a button click. My imac is only changing the en0 but not en1(wireless) my friends is the other way round. Worth a try.
10. Comment by koaps
on 1 Sep 2009 @ 6:37 pm
i tried it on my powerbook g4 with 10.4 and I was able to change en0(wired) with no issues, but en1(wireless) will not change.
I tried everything listed here and nothing works.
11. Comment by changemymac
on 21 Nov 2009 @ 4:21 am
changemac 1.6 does not work with 10.5.8 and a MacBookPro 5,1. I ran the app and checked with wireshark.. No dice on the mac add change… any suggestions???
12. Comment by Nopstnz8
on 28 Feb 2010 @ 9:59 am
Thanks a ton. This seems to work very well in Snow Leopard. I am testing it at my University, and after initiating the command, it logged me out of Cisco, which I then successfully logged back in, and terminal also verified I had the MAC address 00:00:00:00:00:00
Thanks again.
13. Comment by Lithiumion
on 2 Nov 2010 @ 8:10 am
@ incessantmace
This was a great way to explain something that is deeply complex. Bravo!
14. Comment by Dave
on 20 Jul 2011 @ 5:42 am
I was able to get this to work for both wifi and ethernet. The most important step is that you must be completely disconnected from your network. For ethernet, this involves disconnecting the cable. For wifi, you can try a complicated method outlined at http://d-downunder.blogspot.com/
The difficult thing with wifi is that if you have the password saved in your keychain, it will automatically reconnect to the network, which you don’t want.
An easier way to disconnect from wifi, as highlighted by Deviacium is simply to type sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport -z
It is awkward that this command is hidden deep inside PrivateFrameworks, but at least it works.
Once you are disconnected from the network, simply type the following (replace 00:11:22:33:44:55 with the MAC address of your choice):
To change the ethernet MAC address, type:
ifconfig en0 lladdr 00:11:22:33:44:55
OR
To change the wifi MAC address, type:
ifconfig en1 lladdr 00:11:22:33:44:55
To confirm that the MAC address has been changed, type ifconfig en0 for ethernet, or ifconfig en1 for wifi.
These steps worked perfectly on a 2009 core 2 duo MacBook Pro running Snow Leopard.