From c4237f60b03fd071deb25152d0a45667397e790b Mon Sep 17 00:00:00 2001 From: ron Date: Wed, 6 Jan 2010 03:10:27 +0000 Subject: [PATCH] Updated smb-psexec to finally work on Windows XP, after countless months of it eating away at me. The issue turned out to be an innocuous field in the SMB header, 'process id', which is generally used for connection multiplexing. Apparently, not setting it causes a bug in Windows to surface (I assume it's a bug, anyways) that returns a weird failure code. I found this thanks to Kristof Boeynaems doing some research for me, and then me trying random things to make my packets look more like metasploit's. --- nselib/smb.lua | 2 +- scripts/smb-psexec.nse | 4 ++++ 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/nselib/smb.lua b/nselib/smb.lua index d4e753624..83b9c9e65 100644 --- a/nselib/smb.lua +++ b/nselib/smb.lua @@ -719,7 +719,7 @@ local function smb_encode_header(smb, command) 0, -- extra (signature) 0, -- extra (unused) smb['tid'], -- tid - 0, -- pid + 12345, -- pid smb['uid'], -- uid 0 -- mid ) diff --git a/scripts/smb-psexec.nse b/scripts/smb-psexec.nse index 84b96ff81..84a4f1757 100644 --- a/scripts/smb-psexec.nse +++ b/scripts/smb-psexec.nse @@ -468,6 +468,10 @@ end function cleanup(host, config) local status, err + -- Add a delay here. For some reason, calling this function too quickly causes SMB to close the connection, + -- but even a tiny delay makes that issue go away. + stdnse.sleep(.01) + -- If the user doesn't want to clean up, don't if(nmap.registry.args.nocleanup == '1' or nmap.registry.args.nocleanup == "true") then return