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
More shellcode golf #3078
More shellcode golf #3078
Conversation
Tested bind_tcp_rc4, reverse_tcp_dns and reverse_https.
Note that PrependMigrate and uses of block_api will have to get updated as part of this as well |
Something weird is going on with this. It looks like |
Comparing the nasm listing with the shellcode confirms your suspicion (when ignoring jump offsets and things I changed myself):
Both the retry loop and the exit code in case of a failure seem to be missing from the binary shellcode. [Actually, I ran both binary shellcodes through |
@jlee-r7 I know we haven't been enforcing that the comments next to shellcode match the bytes, but this seem like something we should check in specs: Have metasm compile the supposed source for the shellcode and verify we get the shellcode back out that matches what is in the module. What do you think? I have a method of loading and testing modules that works on master as we used it in Pro. |
@limhoff-r7 Unfortunately, our shellcode source uses some nasm-isms that make it incompatible with metasm (specifically, the |
If the %include is just a simple "paste included file here" like cpp's #include, then we could just convert the file to have erb preprocessing and have erb do the include for us and in a separate mode spit out the %include directive for use with nasm. |
Marking delayed since this will require investigation by @schierlm ( binary not matching sources ). Worst case, we can keep this around for the next time we revisit the blockapi shellcode and try to incorporate these changes then. |
Not sure what I should investigate here. @jlee-r7 pointed out that some singles actually get bigger after the patches, and I pointed out that this is because the current binaries do not match the source (they do not include the retry feature). When comparing the size of the binaries regenerated with current sources, they do get smaller as they should. Last discussion with @jlee-r7 in IRC (a few months ago) resulted in that it is pointless for me to update the pull request with regenerated binaries due to Rapid7's policy of not accepting community contributions in binary form. He wanted to have a look at it and regenerate binaries when he finds time to do so. So I agree that this pull request is delayed; however, creating a human deadlock in waiting for each other indefinitely will surely not resolve it :) [why cannot I highlight @hdmoore-r7 here? Oh, it's @hmoore-r7 :) ] |
@schierlm Thanks for the context! It sounds like someone on the Rapid7 side needs to review the shellcode source and then rebuild and test the payloads. One open item in the comment stream above:
Any chance you looked into this or discussed this with @jlee-r7 as well? I can take on this PR from a source review, build, and test standpoint. |
Re: Making metasm handle the shellcode build ( @limhoff-r7 / @jlee-r7 ), the incompatibilities in the past include increased size for some operations compared to nasm, so there is more work to do than just implementing |
I had a quick look at places where block_api is copied in, but I think they can easily be found by grepping, see https://github.com/rapid7/metasploit-framework/search?utf8=%E2%9C%93&q=%22fs+edx+48%22&type=Code - @jlee-r7 do you agree, or does it miss some? If you prefer, I can add them to this pull request (more or less copy&pasting the changes to block_api). However, I currently don't have a working msf dev environment (my windows dev environment "died" when you did the meterpreter-bins gem change a few months ago and I did not have time to setup something new yet), so the changes would be 100% untested, so I don't know if it is so valuable. Also, I don't believe they have to get updated, although it is of course best if more places can benefit from the new smaller code (and probably even some AV signatures get out-of-date as a side effect) :) |
@schierlm Thanks! I think I can grab it from here. I will create a new PR with your source code commits cherry-picked and my commits to the block_api and binary blobs. At that point, @jlee-r7 or another developer can land it once we have verified that all of the modified payloads and stubs still work correctly. This the branch I am working from: |
Superceded by #4391 |
Save a few more bytes (as described in my comments to https://community.rapid7.com/community/metasploit/blog/2014/02/14/shellcode-golf):
Note: