Suricata

just want to add that, as victor touch on in this comment https://github.com/OISF/suricata/pull/7233#issuecomment-1099277048

the transform should support some method of "selecting" which bytes to decode.

Shivani has done a lot of work recently getting the base64_decode to handle errors in a way that is reasonable. We'd want to make sure that same behavior occurs here.
References:
#5896 and #5223 and #6135

Also, while I"m sure this is a long stretch, but if i recall correctly transformations can still be used as fast_patterns (from_base64 might be an exception?) but if this transforms opens a path to seeing #5245 implemented that would be amazing!

from_base64: [bytes <n>, offset <n>, mode <relax|rf2045|strict|rfc4648>]

The bytes and offset default to inspection buffer length and 0, respectively.

mode can default to that used with base64_decode -- RFC4648.

Thoughts?

Should we also support variables here? From byte_extract I mean?

That's a good idea. If it's possible to use a variable for the offset and bytes value, we should.

We've deferred using byte variables (see issue 6807).

@Brandon Murphy

Can you comment on which base64 decode modes are useful for rule writers. There's RFC2045, RFC4648 and then Suricata's own strict

strict stops decoding and returns an error iff an invalid character is found in the bytes being decoded.

Jeff Lucovsky wrote in #note-12:

@Brandon Murphy

Can you comment on which base64 decode modes are useful for rule writers. There's RFC2045, RFC4648 and then Suricata's own strict

strict stops decoding and returns an error iff an invalid character is found in the bytes being decoded.

Hard to say, they all have their purpose. Are you asking to help select a default mode if one isn't provided?

I know @Shivani Bhardwaj did a lot of work to allow "extracting" more data from strings in base64 format that have invalid characters in them which has been useful. references: #5885 #5315 #5223

[from a discord thread in #rule-lang-dev]
@Jeff Lucovsky asked: "We'd like input on what to do when the input buffer cannot be base64 decoded (e.g., the buffer isn't a valid base64 string)"

@zoomequipd's reply:
three* thoughts:
1) if the string cant be base64 decoded, IMO the rule should not alert.
taking from your example, consider this rule
alert http any any -> any any (msg:"from_base64: offset #1 [mode rfc4648]"; \
http.uri; content:"/?arg="; from_base64: offset 6; \
content:"thisisatest"; sid:2; rev:1;)

when the traffic encountered incldues the URI /?args=notabase64encodedstring

In this case, i'm not really sure how to best handle it internlly to suricata, but i wouldn't want an alert to trigger.

2) would the condition when the string can be partially base64 decoded (encounters a non-base64 string 40 chars into the base64 string) be considred when the input buffer cannot be base64 decoded?

reference: https://redmine.openinfosecfoundation.org/issues/5885

3) does it make sense to include a "relative" option on the transformation?