Base64url decoding support nopadding#6
Base64url decoding support nopadding#6steve-embling wants to merge 10 commits intoMythicC2Profiles:mainfrom
Conversation
|
have you seen any performance hits (cpu spikes or memory increases) with this? Since you're already doing testing to see what works, I'd be curious if you could simply do a check for the last character to see if it's |
|
I've only tested with a couple of beacons checking in slowly so while I haven't seen any signs of problems I'm also not really testing anything close to the worst case scenarios. Any suggestions on testing? 10 or so realtime agents unpadded over POST while downloading some big files? As you can undoubtedly see Go isn't my thing, so I can try to raise it the way you suggest? My thinking was that this would have zero impact on the current padded case if I'm the only person that wants this that's fine. Checking the string first I would think would have a smaller impact in worst case scenarios but also impact existing beacon implementations. |
|
relatively simple change, but converted to draft until I can check this hasn't broken either case. Sorry if you get notified of each of these commits. I'm building/testing on a different machine via GH pulls and didn't really think it through. |
Hi, I'm not sure how to best raise a PR on this repo, sorry if not appropriate.
I've been doing some debugging on an agent using HTTPX, and was a bit confused about the base64 implementation, particularly in GET requests.
Long story short, it appears padding is needed even when base64url encoding and passing as query strings or cookies which is a bit weird and suspicious a behaviour I think. Not sure it qualifies as a bug nor broken but definitely weird. Sending unpadded results in an error.
I've tested this patch that appears to work fine for my use case, where it tries padded and will then try unpadded and fall back to failure after this. Is this a reasonable approach? If so, can it be merged?
Base64 could maybe do with the change too to allow some flexibility in agents, but the behaviour only really bothers me on the URL encoded version so that's all I've touched here.