CodeX

the language or the action (or both)

>Very scriptable via Sleep

bro really did all that work to escape cobaltstrike, only to add back (possibly) the worst part about cobalt strike

random thought about this idea - wouldnt a yara rule generator for crystalpalace artifacts promote static sig based defenses, as opposed to educating on the tradecraft (ground truth) itself (and potential defenses) regardless of its implementation?

Ah ok, that makes sense.

Also I think my question was misunderstood as a request to add that capability, I was more asking if you saw signature resistance (or the ability to implement it) as part of tradecraft, and hence part of what the framework as a whole should support :)

True, but isnt there a difference in making a platform potentially usable for ops and tunnel vision on ops? I dont see operational usability and openness as mutually exclusive, though I do agree with the part about secrecy etc. - im more asking about the philosophy than trying to challenge it

Not trying to argue btw, in case it was understood that way. I totally agree with the main driver being to promote tradecraft, I just think that theres a bit more overlap between the operational problem sets and what I personally consider tradecraft :D

No, im not asking for a tool to guarantee subversion, im not referring to using crystal palace to break existing static signatures, im asking about the signatures that are caused by usage of crystal palace itself.

Do you consider being resistant to static signatures part of tradecraft literacy?

Interesting. though then by design crystal palace as a framework would be impractical for any operational use, as it would be quite hard for any amount of tradecraft to cover up the sigs in the framework itself imo

No, im referring to the static (potentially signaturable) parts of crystal palace, like the one shown in @rastamouse.me 's yara rule. Just asking if the crystal palace itself being signaturable is something thats intended to be changed or will remain as is

Gotcha. Then are there plans to expand on the BTF based mutations as of now? or are there any plans to address the currently static parts of crystal palace itself (e.g. the hook intrinsic)

I understand what you mean about the driver not being operational use - but regardless, do you happen to have done any testing of Crystal Palace with clang + LLVM compiled PICOs? (I had issues)
Asking because it would (in theory) solve a broad category of operational problems (static sigs)

Thanks for the answer - for long term resident stuff like hook picos that cant really be masked (a sleep mask for the sleep mask would be funny, lol) would you suggest compile time obfuscation? or are more crystalpalace obfuscation flags planned to make it more robust against static sigs in general

Asking because i was experimenting with crystal kit recently and noticed the hooks PICO broke with the +mutate flag enabled, and i suspect compile time obfuscation like LLVM might as well

@raphaelmudge.bsky.social in your opinion, is the +mutate option itself enough to make a given PICO robust against static signatures?

If not, do you have any ideas or ideal solutions for making PICOs less susceptible to static signatures? Otherwise libraries will quickly become signatured in memory