Another way of specifying an IP address in Cocoa apps
May 28, '03 09:16:00AM • Contributed by: trekan

The Cocoa framework indeed has a lot of peculiar features. For example, you don't have to write IP addresses like everyone else does. Every segment of an IP address is a number between 0 and 255. (You could also say that they are a byte each). This can be translated into a number. So if you take the IP address of macosxhints.com, 207.44.210.206, and do this calculation:

207*256*256*256
+ 44*256*256
+ 210*256
+ 206

You get 3,475,821,262. Now if you enter that number (without the commas -- 3475821262) into a Cocoa based browser (Firebird and Safari will do, Internet Explorer won't as it's a Carbon app), you will be at the macosxhints.com homepage. It seems to work in Cocoa based apps. I tried it with Safari, Firebird, and several CLI apps like traceroute, ping, telnet and ftp.

Practical? Maybe, but mostly as a gimmick. Of course, it can save you some typing. Anyone have any ideas for optimum usage?

Another way of specifying an IP address in Cocoa apps
Authored by: jeb on May 28, '03 12:33:56PM

This isn't specific to Cocoa apps. I used to test this as an exploit to get around CyberNanny and similar software that blocked sites by name and x.x.x.x IP. They almost never blocked the denary IP. My method was a little different. I would turn each segment into binary, concatenate them, then convert that large string into a single denary number.

Another way of specifying an IP address in Cocoa apps
Authored by: notmatt on May 28, '03 12:39:32PM

IP address are just 32-bits of information, the "segments" are just for readability, and don't exist anywhere except for when they're displayed, so in that sense, using a 32-bit number for them makes sense.

However, I don't think this is a Cocoa feature; I remember this working just fine on windows IE browsers, and it was noted as a security risk, since you could get URLs like the following:

http://www.cnn.com@3475821262

which looked relatively innocuous to the unseasoned user, and could be used to spoof someone into downloading something nasty. I'm not entirely certain, but I actually think that it's one of the standard representations of an address, but I'd rather not wade through RFCs to confirm my suspicion. Anyone know for sure?

Another way of specifying an IP address in Cocoa apps
Authored by: greed on May 29, '03 11:17:39AM

If you're looking up RFCs, you'll want to go waaaaay back to the "class-based" addressing schemes. Remember class A, B and C addresses?

Anyway, parsing an IP number this way is an artifact of the inet_aton (or the older inet_addr) routines. Any program which converts an IP address string to an actual IP address value will get that conversion trick. And the "0x" bit comes from the C strtol family of routines. (Try a leading "0" for octal.)

Some of us recall the old MacTCP control panel where you had to enter the "network" and "host" part separately, and you couldn't use dots within the name, so you'd have to do (for my network) "network 10", get out Calculator and work out 12 * 65536 + 0 * 256 + 37 for the host part. And then realize that you were actually using a subnet, so you'd done that all wrong and it should be "10 * 65536 + 12 * 256 + 0" for the network....

So what's really happening in inet_ntoa? (This is backed up with tests on my Linux host.)

So we usually use class C formatted IPs, even though we no longer use class-based routing. They're just easier to work with.

Try accessing Apple's site at 0x11.034114040. That'll tell you how versatile your parser is. It seems many browsers are now blocking "imaginative" IP encodings. which is too bad, as hex coding IP numbers is useful for network testing.

The practical upshot for programmers is that you CANNOT process IP addresses in text, you must convert to binary first. (You can convert back to a canonical text form if you like, I guess.)

Doesn't Work Behind a Proxy
Authored by: aogail on May 28, '03 01:10:07PM

I tried this with my university's proxy in use--no go. The proxy tried to resolve the address as it was. This may be because the proxy is configured to try to search its domain before reporting the domain wasn't found; I'm not sure. Either way, turning off the proxy caused this method to work.

Another idea is to use it for storing different values in cookies for a website. That could be practical for test purposes or if more than one person is using the computer.<BR>
I by the way played a bit more with it, and found out that you can use a single zero as a shortcut for localhost / 127.0.0.1, so now when I'm going to use on of the http-services on my mac, I just write 0 i Safari. Or 0:631 for the CUPS print service overview.

Then you can grab visitors IP addresses and figure out what country they are from with 98% accurate country recognition. This is much better than just doing DNS lookups for countries because of the many IP addresses that don't have reverse-mapped DNS.