iOS 10.3 and MAC-address

[akaDuality]

Is seems that iOS 10.2 has damaged something and MAC-resolving isn't working. Every IP has MAC like "02:00:00:00:00:00"

Do you have any idea how to fix it?

[mavris]

Hi, I didn't install the 10.2 beta yet. I will do a research and check how we should retrieve mac addresses on 10.2. I will let you know

[ndenlinger]

Apple has removed the ability to ready MAC Addresses from iOS completely. Even if the MAC Address could be pulled, you'll see what was defined above as "02:00:00:00:00:00". Apple replaced this functionality with a UUID on a per app basis, and a UUID for Advertiser Identifying. The only way I know of pulling a MAC Address is through an API Call from a Mobile Device Management Solution that has a tight relationship with Apple within an enterprise setting. I work in an enterprise environment on our Mobility Team, I've built a network diagnostic tool for our field environment only to find out that the only way for me to obtain the MAC address is through our MDM Solution.

[mavris]

I am wondering how big apps (eg. Fing) will overcome this issue.

[ndenlinger]

I agree. I know a lot of them have just dropped the feature all together, or opted to use a UUID which is given upon when a particular app is installed. Apple removed access to the MAC Address for privacy concerns as the MAC Address is a hardware specific ID. Even to access the SSID, SignalStrength and BSSID of a device's WiFi was difficult and quite the battle with Apple. I know in my network diagnostic tool I've dropped the feature until our MDM solution provides a more elegant means of obtaining the MAC Address for our enterprise environment.

[mavris]

@akaDuality Can you test Fing or any other network scanner on 10.2 and let us the outcome?

[akaDuality]

Fing has update that fixes it for iOS 10.2 and works pretty well. They said that they use some proprietary technology

[mavris]

Can you open a bug report at Apple with your findings? Last time I opened for MMLanScan and "ping" functionality in a background thread they were quite helpful and gave me tips that solved the issue.

[akaDuality]

I've opened radar with ID 29481116. Waiting for reply from Apple

[mavris]

Guys, do you use MacFinder for network scanner?

[akaDuality]

Is it from the gitHub? Yes, it doesn't work too

[mavris]

Sorry, I thought that this case was opened on MacFinder repo :) My bad. Yes, I am talking about MMLanScan.

[leonfu]

@mavris @akaDuality do you ever think about trying some other way such as taking some tricks from https://github.com/samdmarshall/SDMMobileDevice

[akaDuality]

@leonfu Is it about iOS-to-iOS communication, right?

[leonfu]

it's for mac-to-iOS with usbmuxd, so far no luck. @akaDuality Btw, I tried some ways like ARP request and raw socket packets, no progress

[monobono]

The app "Network Analyzer" shows MAC Addresses under iOS 10.2 as well.

[mavris]

If we could somehow get a tip how to implement it.. I have free time this week so I will look for alternatives

[mavris]

@leonfu Can you share your findings?

[leonfu]

@mavris I list what i have done

1. try raw socket failed with permission denied
2. try snmp call to gateway for routing table failed with nothing related return
3. try UDP socket failed with no link layer mac info in data callback

many solutions such as https://github.com/ThomasHabets/arping requires raw socket with root privileges :-(

[leonfu]

By using some sniffer tool to monitor "Fing" and "Network Analyzer Lite" apps, I found that both of them try to visit uPnP services located on the surrounding servers within the same WiFi network.

[mavris]

Is there any other open source library for UPNP discovery?

[sxyclint]

@leonfu I don't think it works successfully on iOS 10.2 because of uPnP. If you stop uPnP service, app works well too. It is possible that Apple cleared ARP cache or rewrited ARP result. I guess maybe they have found some methods to bypass and fetch result from the APR table.

[leonfu]

"iNet Network Scanner" also make it work with 10.2 now

As this app can set the scanning range, It's interesting that if scanning a small range at the first time it works but rescaning the same range will fail to get the mac address.

I guess in some way the app can get the mac before it's going to add to the arp cache table. But once it's already in the cache table, it fails as we know

[mavris]

How they manage to retrieve the MAC Address? What we miss here? I will try to test few apps and check what's going on. Hopefully, we will get a hint.

[leonfu]

it seems in 10.2, those apps can get the arp response some way when communicating with new ip (never pinged before no matter whether the IP can be reached or not)

[mavris]

I am using iOS Console to monitor the apps. I noticed that querying MAC Address with MacFinder lib produces this log which is the same as Fing(but not for Net Analyzer).

15/12/2016, 10:19:31 AM mDNSResponder[95]:  16: DNSServiceQueryRecord(3.215.168.192.in-addr.arpa., PTR) STOP PID[3344](MMLanScanDemo)
15/12/2016, 10:21:20 AM mDNSResponder[95]:  18: DNSServiceQueryRecord(1.215.168.192.in-addr.arpa., PTR) STOP PID[3247](fing)

Maybe they didn't remove the old code or the modified the existing somehow

[leonfu]

Yes, they keep the code for iOS 10.2- . After trying "iNet Network Scanner", I believe for 10.2+ it's not for sure that the mac address can be obtained for every time. https://itunes.apple.com/cn/app/inet-network-scanner/id340793353?l=en&mt=8

[ndenlinger]

So I visited iNet's website, two days ago (13th of December) they posted that the MAC Address feature doesn't work in 10.2. However, I'm on 10.2.1 Beta 1 and the MAC Address feature is still working. Maybe if the app gets updated, the codebase that they use for the MAC Address gets nullified? I sent them an email on how they achieved obtaining the IP Address to see if I or we can provide support to them in getting the MAC Address from the ARP Table.

[mavris]

@ndenlinger Why we need to know how they get the IP? I mean we can do that already. As @leonfu said they manage to get the MAC Address on 10.2. Let us know if they come back with tips

[ndenlinger]

Right, they do get the MAC Address on 10.2 and even 10.2.1 Beta, but my only question to them is; if they update their app...will that functionality break on 10.2+? iNet posted an update indicating that they are working hard to resolve that issue. So maybe they are developing the next feature, and discovered that in development that specific feature broke. Here's the link to their blog..

Actually I have an update while I was getting the link for you guys. They found a work around. They just posted earlier today that they found a fix and to update the app to 3.0.3, which is the version I'm running on 10.2.1 Beta 1.

Anyways, here is the link: http://www.bananaglue.de

Once I've received a response from them, if anything, I'll post that response here.

I'm also going to perform a NCAP to see if I can see anything from a networking perspective.

[ecumedesjours]

I've also tried many of the same things as leonfu. I wonder if it's nothing more than a special entitlement or a plist entry like "NSAppTransportSecurity"?

[ecumedesjours]

another possibility is to figure out at what point in the process the real mac addresses are being substituted for the bogus ones. For instance, the sysctl() call to get the arp table probably already passes the manipulated data. In that case, it should suffice to not use Apple's sysctl call but build one's own?

https://opensource.apple.com/source/system_cmds/system_cmds-175.2/sysctl.tproj/

---update---

turns out someone already did this (https://github.com/yarshure/sysctl_iOS)

---update---

nope - sandboxed

however: sysctl() also has these sister functions: sysctlbyname() and sysctlnametomib() - perhaps the output of those have not been tampered with?

[sreedeeppaul]

I have seen an Android implementation where they read from the file directly where the arp table is created in "/proc/net/arp". They directly read the table data from this file location.Can anyone suggest if we can find anything similar for iOS?

[mickeyl]

It looks like more than just Fing can read the MAC addresses (e.g. Net Analyzer). I wonder whether it might be the compilation against the latest SDK that enables that sandbox mode? Perhaps Fing and the other apps have been built against an older SDK hence get some kind of compatibility mode?

[arivas87]

I'm afraid SDK version is not the problem because I have seen apps compiled with older SDK working wrong.

[kasimok]

Hey guys, I found all this 'sysctl' way to get the mac address still works on the simulator. Any clue on this? What is the difference of simulator and real device?

[mavris]

It's a simulator and not emulator. So it's probably using macOS 'sysctl'.

[sushilkmishra]

@mavris Hi Mavris, how to get mac address in iOS 10.2.? have you any idea please suggest.

[mavris]

@sushilmishraios Hi, unfortunately, we didn't manage to find a workaround yet. If anyone has a tip where to look it would be nice.

[ecumedesjours]

hmm - what about changing certain vars in sysctl before calling it, for example turning on verbose mode (e.g. net.link.ether.inet.verbose)?

[mochasoft]

I have an observation:

If I ping all devices in the subnet from my iPhone, and read (sysctl(..PF_ROUTE..) the mac list is empty (worked before the iOS was updated). If I wait maybe 10 minutes on this hotel wifi, some Mac addresses show up in the list. It could indicate PF_ROUTE not just simple replace all elements with 0x2:00:....

[AeolusLau]

I got this problem too. Is there any clue now?

[mavris]

This is the official answer from Apple: "We hide MAC addresses from apps for privacy reasons. No application should be able to get MAC addresses for any purpose.". So I think no matter what solution we find they will hide the MAC Address on the next update.

[rorymckinnel]

The dialogue I have had with apple states the following: It is by design, and motivated by privacy concerns rdar://problem/28755242. Given that this was a deliberate change to impose a specific restriction for privacy reasons, any attempt to get around that restriction is likely to fail in the long term rdar://problem/29683195.

Annoyingly we can not see the content of these rdr problems as it is for apple employees only. There is no written statement anywhere else from what I can see. This would imply that although Fing et al can see MACs just now, that it is only a matter of time before the door is fully shut.

It also would seem that the statement on the removal of MAC address was missed from the release notes, hence why people found out the hard way. What I do not understand is why this was not done over a release by sending out a deprecation notice and allowing some discussion. A similar thing happened with SSID capture for Wi-Fi which was removed on privacy grounds but fortunately got put back.

IMHO, a better approach would have been to add an entitlement for applications which sign up to only using the MAC address for identifying LAN devices. A second mechanism could be added for the user to allow the application to correlate devices on the LAN on the understanding that these are not shared externally.

[ecumedesjours]

Agreed, entitlements are definitely the way to go. That way Apple's team can vet the use scenario before issuing the entitlement.

[mavris]

That's exactly what I was thinking. Entitlements. And if we are not allowed to get MAC Addresses why Fing & others are not rejected from App Store?

[ecumedesjours]

Following a TSI (Technical Support Incident) session, here is more clarification from Apple:

"There are no alternative methods supported by Apple, nor there are any special permissions or entitlements you can acquire in order to access MAC address information via the ARP table any more. I cannot comment on other developers’ apps, or how they may have gotten around these restrictions, but given the stance on privacy, any alternate solution you may find right now is likely to fail in the long run."

I see that there is now a bounty on Stack: http://stackoverflow.com/questions/41283688/mac-addresses-in-ios-10-2

[ndenlinger]

That's pretty upsetting. There are definitely some legitimate use cases. I can understand from their privacy, but at the same time there are use use cases in which the MAC Address would be needed. I fully support the idea of entitlements idea granted by Apple just like the network extension framework. I needed to build an enterprise application used for diagnosing an internal environment meant to detect what all was reachable, and the network conditions within that environment. It was quite the battle to finally had gotten approval for use of the NEHotspotHelper object, but seeing that entitlement as being the only way to obtain network info, I believe a similar process should be enabled by Apple.

I'm not exactly sure what all we can do to obtain the MAC Address in this instance, as Apple seems fully committed to patching any and all ways of obtaining the address that were exploited.

It'll be interesting to see if anyone comes up with a way in order to do so, and how quickly Apple patches that ability. I'm keeping a close eye on SO for any potential methods available that have been found to work.

[ecumedesjours]

There are a growing number of folks with the temporary workaround. Knowledge wants to be free, so eventually the solution will be shared :)

[ndenlinger]

Agreed.

My only concern is if this information is indeed made free and available to the general public community of developers, Apple will take note and debug/reverse engineer these new found methods. How would we share these solutions that could help prevent unwanted effects of making these sort of things public knowledge?

[ecumedesjours]

Valid concern - but I feel it is inevitable. Hopefully by the time Apple gets around to patching this latest workaround, they will also be ready to offer a legit means of accessing the arp table via entitlements, as many have been suggesting. In fact, I think posting the solution might actually accelerate the process of legitimization...