-
Notifications
You must be signed in to change notification settings - Fork 1.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
Extensionargs #1424
Extensionargs #1424
Conversation
I can see two solutions:
I'm in favor of the second option sine we'll have to do it eventually. We could put a warning in the UI when loading the extensions and seeing the manifest doesn't contain what we expect, and link to the docs so people can update.
I'm working on a side project that is basically bootstrap templates for extensions. This will solve that issue, as all people would need to do is clone a repo and put their code in the templated files. Argument parsers will be in there. I'll try to review as soon as I can, I've been busy this year :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some conflicts to resolve before I can test this one (since I merged the other PR).
Signed-off-by: C_Sto <[email protected]>
Should be good now - reminder that sliver/client/command/extensions/load.go Line 493 in dfaadfb
This can be changed by adjusting the check in the code ref'd above to just apply the bof arg packing logic to all extensions (including those that only take a single string), but it will break old extensions that expect a 'dumb' string. |
Edit: actually I think we can break things here and force the usage of the BOF argument packing/unpacking even for single string arguments. There's only two or three DLL extensions in the armory anyway, and I haven't seen a ton of non-bof extensions out there. Once I'm done with the Sliver SDK, developers will be able to include the parser code in their code base and be done with it. |
Card
Ace of Spades
Details
Adjusts DLL extensions to use the same argument API as COFF/BOF extensions. This will rely on #1397 (and is based on it), but the changes to the client are pretty minimal, so could be rebased fairly easily. Check the diff from 4421ec1 to see the actual changes. Alternatively, close this PR and I can add the argument changes to #1397 to keep it all together (but I figured that an API change like this would probably warrant some public discussion).
Would like feedback on how to handle 'legacy' extensions that use a single argument - currently any extension that takes a single string argument per the manifest is in 'legacy' mode, and the string does not have a length prefix in the data stream. This might complicate things if people are developing extensions and not looking at the docs that should shout about making sure you do/don't expect length prefixes. Alternatively, we can scrap the legacy mode and just force usage of the BOF arg packer.
It may also be worth publishing a sliverextensionutils package somewhere that has the equivalent of the beacon.h headers to make extension development less tedious. I've included the slivercompat.go I used to verify this PR below. This might be a good opportunity to make the callback routines a bit more mature as well (eg, including the ability to send data back as a download/loot and/or just generally more asynclyfied).
slivercompat.go
usage might look like below:
exampleext.go
extension.json