Skip to content

Base64url decoding support nopadding#6

Draft
steve-embling wants to merge 10 commits intoMythicC2Profiles:mainfrom
steve-embling:base64url-decoding-support-nopadding
Draft

Base64url decoding support nopadding#6
steve-embling wants to merge 10 commits intoMythicC2Profiles:mainfrom
steve-embling:base64url-decoding-support-nopadding

Conversation

@steve-embling
Copy link
Copy Markdown

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.

@its-a-feature
Copy link
Copy Markdown
Contributor

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 = and do padded or unpadded decoding based on that? That might be easier than trying to decode it twice

@steve-embling
Copy link
Copy Markdown
Author

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.

@steve-embling steve-embling marked this pull request as draft April 22, 2026 18:21
@steve-embling
Copy link
Copy Markdown
Author

steve-embling commented Apr 22, 2026

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants