New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows Deployment Services (x86) #2511
Conversation
Compatible with both x86 and x64 systems. Tidy up the module...
Also tidyup indents and use predefined UUID syntax.
Related to #1420 |
So, sometimes I get this:
I think there are a couple over-eager rescues in here. Also, I often end up with a bunch of open connections. When the module ends, I'm still left with:
Normally, hanging connections like this get handled with Here's a more normal run:
and now I have another connection:
Going to see what I can do to detangle this. |
It feels like when you open the DCERPC connection to WDS, if you never close it, that WDS server is out of the unattend.xml-serving business. |
This is on my Wink2k3 machine, btw. |
By the way, the + rescue isn't consistent. Here's a good run, after restarting WDS:
|
So, it looks like for each arch, you need to set up the handle, get the file, and then tear down the handle. |
Sometimes, the returned data (dcerpc.last_response.stub_data) gets chopped off. Hmm. Here's an inspect:
|
So, when it works, after this next commit, I often get this:
However, I often get incompletes, and it looks like the socket read is cutting off between packets. Here comes a pull request; I'm thinking we need to be slower on the RPC read in order to actually pick up the data, then close out the connection. It feels like, on Win2k3, that we're running into a locking situation on the WDS server. |
See Meatballs1#28 |
Note that all of my problems may just boil down to my crummy 32-bit server. @Meatballs1 may have never seen these protocol snafus in 64-bit land, and this PR #2511 does indeed solve the fundamental cross-compat issues. If I don't get any feedback on this in the next hour or so, I'll land this, and we can tinker with Meatballs1#28 in the meantime. |
Regardless of Meatballs1#28, this PR and 50b1dd9 could be landed right now to just deal with the 32-bit RPC transfer syntax and avoid the NoMethodError on nil. |
So, I'm still racing DCERPC, looks like, but now my sessions are at least closing cleanly. I'll land this now to get around those problems.
|
@todb-r7
There's really no point supporting NDR64 syntax as x64 systems will talk NDR32 without issue. So dropped back to the default syntax and corrected the module. Also performed various tidyup tasks after ~12 months more MSF dev experience.
Should play nicely with 2k3 x86 -> 2k8 x64 and I assume 2k12...