Apologies, it looks like the probe suggestion was cut off now that I re-read it.
Probe TCP NSConnection_rootProxy q|\xd0\xcf\x50\xc0\x00\x00\x00\x7b\x00\x00\x00\x00\x02\x01\x06\x10\x10\x02\xc0\x0d\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x53\x04\xed\xfe\x1f\x0e\x01\x01\x01\x01\x01\x0dNSInvocation\x00\x00\x01\x01\x01\x10NSDistantObject\x00\x00\x00\x01\x01\x01\x01\x02\x01\x01\x10keyedRootObject\x00\x01\x01\x04\x40\x40\x3a\x00\x01\x40\x01\x00\x00| -HN PGP CC7C 7F5A On Fri, Oct 11, 2024 at 9:58 PM Harrison Neal <hn...@whatdidibreak.com> wrote: > Good day, > > It appears that nmap doesn't currently recognize TCP-bound NSConnection ( > https://developer.apple.com/documentation/foundation/nsconnection ). > > Example server code: > > NSConnection *a = [NSConnection connectionWithReceivePort:[[NSSocketPort > alloc] init] sendPort:nil]; > [a setRootObject:[[NSObject alloc] init]]; > [a runInNewThread]; > [NSThread sleepForTimeInterval:300.0f]; > > Example client code: > > NSLog(@"%@\n", [[NSConnection connectionWithReceivePort:nil > sendPort:[[NSSocketPort alloc] initRemoteWithTCPPort:remoteport > host:@"remotehost"]] > rootProxy]); > > Possible probe based on first client packet: > Probe TCP NSConnection_rootProxy > q|\xd0\xcf\x50\xc0\x00\x00\x00\x7b\x00\x00\x00\x00\x02\x01\x06\x10\x10\x02\xc0\x0d\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x53\x04\xed\xfe\> > > Across multiple runs I found little variation in clients' initial > packets. The data byte at offset 0x13 (assuming the first byte has offset > 0x0) appeared variable in the client. > > SF-Port49157-TCP:V=7.94SVN%I=2%D=10/11%Time=6709CDA7%P=x86_64-pc-linux-gnu > SF:%r(NSConnection_rootProxy,D0,"\xd0\xcfP\xc0\0\0\0\xd0\0\0\0\0\x02\x01\x > SF:06\x10\x10\x02\xc0\x05\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\x01\0\0\0\x98bplis > SF:t00\xd5\x01\x02\x03\x04\x05\x06\t\n\x0b\rRrpRidSseqSexcSret\xd1\x07\x08 > SF:R\$n\t\x12\x0e/\xfe\xce\x10\x01\xd1\x07\x08\t\xd1\x0e\x0fR\$g\xa1\x10\x > SF:d3\x11\x12\x13\x14\n\x15S\$cnQiQt_\x10\x0fNSDistantObject\x10\0\x08\x13 > SF:\x16\x19\x1d!%\(\+,1367:=\?FJLN`\0\0\0\0\0\0\x01\x01\0\0\0\0\0\0\0\x16\ > SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0b\0\0\0\x01\0\0\0\x080001KeYd"); > > Some similarities between this and the existing match for DEVONthink > dcoument management [sic]. My original thought was to target bplist00 for > a match because it would avoid getting confused by a server echoing the > client's initial packet and it appears to be a known and researched topic > per Google. Maybe a match pattern like bplist00.+NSDistantObject could > work here without negatively impacting the DEVONthink match? I > personally would be hesitant to try matching on too much of the server's > first response, not knowing exactly what those bytes mean, and not knowing > how variations in the server code (e.g., > https://developer-mdn.apple.com/library/archive/documentation/Cocoa/Conceptual/DistrObjects/Tasks/delegate.html > ) could affect the server's first response. > > SF-Port49154-TCP:V=7.94SVN%I=2%D=10/11%Time=6709D113%P=x86_64-pc-linux-gnu > SF:%r(NSConnection_rootProxy,D0,"\xd0\xcfP\xc0\0\0\0\xd0\0\0\0\0\x02\x01\x > SF:06\x10\x10\x02\xc0\x02\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\x01\0\0\0\x98bplis > SF:t00\xd5\x01\x02\x03\x04\x05\x06\t\n\x0b\rRrpRidSseqSexcSret\xd1\x07\x08 > SF:R\$n\t\x12\x0e/\xfe\xce\x10\x01\xd1\x07\x08\t\xd1\x0e\x0fR\$g\xa1\x10\x > SF:d3\x11\x12\x13\x14\n\x15S\$cnQiQt_\x10\x0fNSDistantObject\x10\0\x08\x13 > SF:\x16\x19\x1d!%\(\+,1367:=\?FJLN`\0\0\0\0\0\0\x01\x01\0\0\0\0\0\0\0\x16\ > SF:0\0\0\0\0\0\0\0\0\0\0\0\0\0\0b\0\0\0\x01\0\0\0\x080001KeYd"); > > The targets were running Sonoma. I can't speak to how different things > would be on different MacOS versions, but NSConnection's deprecation would > suggest it may not be too much of a moving target. > > -HN > PGP CC7C 7F5A >
_______________________________________________ Sent through the dev mailing list https://nmap.org/mailman/listinfo/dev Archived at https://seclists.org/nmap-dev/
