Nmap Development mailing list archives
Re: afp-serverinfo.nse script
From: David Fifield <david () bamsoftware com>
Date: Thu, 25 Feb 2010 12:24:10 -0700
On Mon, Feb 15, 2010 at 09:23:03PM -0700, David Fifield wrote:
On Wed, Feb 10, 2010 at 04:46:01PM -0600, Andrew Orr wrote:Good catch, thanks Matt. UTF8 Server Name and Server Signature are both optional fields, I've updated the script to check if those are included. If you run the updated script on that same machine it shouldn't output the utf8 server name anymore. I also fixed the null byte bug more properly and fixed a typo.-- a null byte is added to the end of server_name if it doesn't end on an -- even boundary, so we check for that and skip it if necessary if bit.mod(pos, 2) == 0 then -- null byte detected! GET'M! pos = pos + 1 -- zap! end Can you attach a packet capture or something of this phenomenon? This way of handling it seems suspicious to me. -- For some reason which doesn't reveal itself to me, all the offsets are off. -- This was the source of much frustration when debugging and I'm simply -- fixing them here until I figure out why this is. offsets.machine_type = offsets.machine_type + 1 offsets.afp_version_count = offsets.afp_version_count + 1 offsets.uam_count = offsets.uam_count + 1 -- offsets.volume_icon_and_mask <-- this is deprecated so we don't bother -- not sure why but the offsets get even more off at this point offsets.server_signature = offsets.server_signature + 2 -- and go back down again o.O offsets.network_addresses_count = offsets.network_addresses_count + 1 offsets.directory_names_count = offsets.directory_names_count + 1 -- and back up! offsets.utf8_server_name = offsets.utf8_server_name + 2 This makes me nervous too. I'd like you to paste in hex packet contents of a packet showing these characteristics, and what the values are that you're reading. Off by one is easy to explain, because Lua strings are 1-indexed, but it shouldn't change to 2 like that.
I think the server_signature offset by 2 is a mistake. I looked at a packet capture and the offset is exactly what it should be. 0000000: 0103 0001 0000 0000 0000 0130 0000 0000 ...........0.... 0000010: 001c 0027 0044 0000 8ffb 086d 6163 2d6d ...'.D.....mac-m 0000020: 696e 6900 0079 0089 00b5 0126 0a4d 6163 ini..y.....&.Mac 0000030: 6d69 6e69 322c 3104 0641 4650 332e 3306 mini2,1..AFP3.3. 0000040: 4146 5033 2e32 0641 4650 332e 3106 4146 AFP3.2.AFP3.1.AF 0000050: 5058 3033 0509 4448 4341 5354 3132 3804 PX03..DHCAST128. 0000060: 4448 5832 0652 6563 6f6e 310d 436c 6965 DHX2.Recon1.Clie 0000070: 6e74 204b 7262 2076 320f 4e6f 2055 7365 nt Krb v2.No Use 0000080: 7220 4175 7468 656e 7400 0000 0000 0010 r Authent....... 0000090: 0080 0000 16cb aed4 ac03 0802 c0a8 00be ................ 00000a0: 0224 1407 fe80 0000 0000 0000 0216 cbff .$.............. 00000b0: feae d4ac 0224 0f04 3139 322e 3136 382e .....$..192.168. 00000c0: 302e 3139 3001 6f61 6670 7365 7276 6572 0.190.oafpserver 00000d0: 2f4c 4b44 433a 5348 4131 2e30 3245 4244 /LKDC:SHA1.02EBD 00000e0: 4243 4641 4246 3343 3232 3244 3646 4539 BCFABF3C222D6FE9 00000f0: 4645 3444 3930 3838 3933 3536 3833 3837 FE4D908893568387 0000100: 3635 3440 4c4b 4443 3a53 4841 312e 3032 654@LKDC:SHA1.02 0000110: 4542 4442 4346 4142 4633 4332 3232 4436 EBDBCFABF3C222D6 0000120: 4645 3946 4534 4439 3038 3839 3335 3638 FE9FE4D908893568 0000130: 3338 3736 3534 0008 6d61 632d 6d69 6e69 387654..mac-mini 0000140: 0a . The server signature offset is the 0079 in the 00000020 line. Looking the 16 bytes starting at byte 0x89 (because the offsets are based 0n a point 16 bytes past the beginning of the packet), we find the server signature 000000000000100080000016cbaed4ac. As for the UTF-8 server name, I think the reason for that is that the field has a two-byte length, different from the other string. By offseting by 2 instead of 1, you're only getting the low-order byte, which happens to work when the length is less than 256. This page (http://developer.apple.com/mac/library/documentation/Networking/Conceptual/AFP/Concepts/Concepts.html) says: An AFP pathname is formatted as a Pascal string (one length byte followed by the number of characters specified by the length byte) or a UTF-8 string (a four-byte text encoding hint followed by two length bytes followed by the number of characters specified by the length bytes). This doesn't have the four-byte encoding hint, but it corroborates the two-byte length. One point of ambiguity is that they say it is a count of characters, which in UTF-8 may be different from the count of bytes. It would seem to make more sense to use the length of the encoded UTF-8 byte string, but who knows? I wouldn't worry about this unless it starts breaking. You've got the wrong byte order in server flags: SERVERFLAGS_BITMAP = { SuperClient = 0x80, UUIDs = 0x04, UTF8ServerName = 0x02, OpenDirectory = 0x01, Reconnect = 0x8000, ServerNotifications = 0x4000, TCPoverIP = 0x2000, ServerSignature = 0x1000, ServerMessages = 0x800, NoPasswordSaving = 0x400, ChangeablePasswords = 0x200, CopyFile = 0x100 } Compare this to the order from the Wireshark dissector: http://anonsvn.wireshark.org/wireshark/trunk/epan/dissectors/packet-afp.h. #define AFPSRVRINFO_COPY (1<<0) /* supports copyfile */ #define AFPSRVRINFO_PASSWD (1<<1) /* supports change password */ #define AFPSRVRINFO_NOSAVEPASSWD (1<<2) /* don't allow save password */ #define AFPSRVRINFO_SRVMSGS (1<<3) /* supports server messages */ #define AFPSRVRINFO_SRVSIGNATURE (1<<4) /* supports server signature */ #define AFPSRVRINFO_TCPIP (1<<5) /* supports tcpip */ #define AFPSRVRINFO_SRVNOTIFY (1<<6) /* supports server notifications */ #define AFPSRVRINFO_SRVRECONNECT (1<<7) /* supports reconnect */ #define AFPSRVRINFO_SRVDIRECTORY (1<<8) /* supports directory services */ #define AFPSRVRINFO_SRVUTF8 (1<<9) /* supports UTF8 names AFP 3.1 */ #define AFPSRVRINFO_UUID (1<<10) /* supports UUIDs AFP 3.2 */ #define AFPSRVRINFO_EXT_SLEEP (1<<11) /* supports extended sleep, AFP 3.3 */ #define AFPSRVRINFO_FASTBOZO (1<<15) /* fast copying */ If you make these changes, namely removing the +2 offsets, handling a two-byte UTF-8 server name length, and fixing the flag bits, then I'm ready to accept your changes. David Fifield _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- afp-serverinfo.nse script Andrew Orr (Feb 09)
- Re: afp-serverinfo.nse script Matt Selsky (Feb 09)
- Re: afp-serverinfo.nse script Andrew Orr (Feb 10)
- Re: afp-serverinfo.nse script Matt Selsky (Feb 10)
- Re: afp-serverinfo.nse script Andrew Orr (Feb 10)
- Re: afp-serverinfo.nse script David Fifield (Feb 15)
- Re: afp-serverinfo.nse script David Fifield (Feb 15)
- Re: afp-serverinfo.nse script David Fifield (Feb 25)
- Re: afp-serverinfo.nse script Andrew Orr (Feb 10)
- Re: afp-serverinfo.nse script Matt Selsky (Feb 09)
- Re: afp-serverinfo.nse script -- new AFP library Patrik Karlsson (Mar 29)
- Re: afp-serverinfo.nse script -- new AFP library David Fifield (Mar 29)
- Re: afp-serverinfo.nse script -- new AFP library Patrik Karlsson (Mar 29)
- Re: afp-serverinfo.nse script -- new AFP library David Fifield (Mar 30)
- Re: afp-serverinfo.nse script -- new AFP library Patrik Karlsson (Mar 30)
- Re: afp-serverinfo.nse script -- new AFP library David Fifield (Mar 30)