-
Notifications
You must be signed in to change notification settings - Fork 14.1k
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
Implement payload size caching, speeding up framework loads #4894
Conversation
I presume you're writing an automated test to compare the cached value to the real one for all the non-dynamic payloads and make sure its not stale? Maybe msftidy could be updated to notice this? |
That said, it worked well - the is_dynamic_size? check seemed like it might false-negative, e.g. if a payload rounded a string length to multiples of 32 or something, but I didn't find any actual counter-examples. |
The regex needs a little work - there is some whitespace drifting
|
Does this seem like a reasonable update? When we remove the previous value, we need to remove the whole line.
Result is a little prettier:
|
Fixing this and some other open issues in an imminent update. Still missing specs too. |
The previous commit should fail the build, as ./tools/update_payload_cached_sizes.rb has not been run across the modules. |
Builds fail because datastore defaults like LHOST change based on the system they are running on. This has been a problem for a while, so fixing it will be a nice improvement all around. |
The previous commits handle cases where the datastore defaults to something based on the host, but it doesn't solve the real problem, which is that the generate() call during startup needs a default datastore that represents the largest-size output. I will file a separate ticket for that soon, in the meantime, this is good to land. |
Sounds good. Solving for the maximum size will be interesting. For instance, the max LHOST for the reverse_http stagers above would actually be [0000:0000:0000:0000:0000:0000:0000:0000], since they work for ipv6 too. Some metadata for max parameter lengths would be nice, since currently that info currently hard to introspect, e.g. reverse_tcp_dns.rb's exception when LHOST > 63. |
Avoid the hit of regenerating all of the static-size payloads when loading the framework. This will facilitate conversion of payloads to use metasm later.
@bcook-r7 Thanks! Definitely agree, we need to do more work on byte-size prediction for payloads. We have only seen this result in bugs in corner cases (options bring a payload + encoder just over the line), but definitely worth solving. |
Changes Unknown when pulling 618fbf0 on hdm:feature/payload-cached-size into * on rapid7:master*. |
Quick and dirty benchmark:
Generate the cache:
Verify the cache:
Bask in the glory:
Spec coverage is still a TODO and will handle build-time verification of cached sizes.
This change would let us move to Metasm payload generators without a startup-time performance penalty.