The caveat emptor which is in Daniel's post: Crystal Palace needs a patch to get rid of an over broad error check. I'll address this in the next release and even make sure my local unit tests are covering/working with COFF output more.

This does change how I see COFF output in Crystal Palace though

Further, while a transparent time-of-use BOF hook isn't there for CS (yet?):

BOFs could be processed offline to add your favored tradecraft cocktail to them. Any C2 could benefit from that.

Further, any C2 could build this time-of-use hook for their BOFs too.

TCG is C2/capability agnostic

IAT hooking to provide tradecraft to your agent AND any BOFs it might run loses the above benefit. It requires an overbuilt tradecraft package acting on what the agent and potential post-ex tools might do. Forces a trade-off to not do some things.

BOF cocktails allow right-sized tradecraft per BOF.

Let me sell this a little more:

Part of the model of Crystal Palace is to over-build your tradecraft. Come up with hooks, rewrite various APIs, etc. Make one big monster thing. Merge it in. And, Crystal Palace LT-optimizes to right-size the tradecraft to the capability. You get only what you need.

Comment out line 54 of src/crystalpalace/export/ParseImport.java. That'll take care of the error. Just did a quick hacky POC and it worked with my unit test BOF runner.

I'll work a more permanent fix to that in the next release. (I used LIbTCG only for dprintf).

I think this is an interesting use.

(My original gut with make coff was an intermediate format to build a PIC/PICO tool with Crystal Palace and distribute that as an artifact that another Crystal Palace script, later and separately, could apply tradecraft too. In my roadmap, not this release yet, I'll have to sit with this again)

Yes, merge hooks into the BOF and use attach. make coff output. Leave API alone. Fingers crossed, it's something C2s can use.

Earlier, I listed different possibilities (e.g., PIC, PICOs, etc.)--but for BOF in a C2, I'd think coff output might be the path.

Caution, make coff isn't well exercised.

import to pass an API in if it's make object. For make pic I've merged an API impl and did some remap __imp_BeaconPrintf BEACON$BeaconPrintf and then attach'd t those. For make coff? I haven't touched that feature since it shipped. If using COFF w/ CS, leave imported APIs alone, but merge/attach?

A path (don't know if CS has hooks for this, not sure if make coff would hold up) would be the ability to pair BOFs or other things with +optimize'd tradecraft cocktails (e.g., merge it in, attach/redirect) vs. having them inherit from the parent agent's hooks. Limits exposure of that stuff too.

Sounds like a chicken or egg problem. What if you don't IAT hook GetProcAddress? Doesn't let hooks propagate downstream to BOFs and things, but would solve this issue?

And, migration complete.

Pleased to keep my 1-2 9s of reliability promise.

Server came back a few hours ago. Hypervisor outage. I gave provider a green light to migrate my server.

We'll have some downtime again between when they migrate and I handle the post-migrate configuration changes.

Also, I'd love to add your project to the TCG's Community Pavilion page. I just ask that you add a LICENSE file first so I can note the right license.

I'm studying your repository to understand what's going on. I'm not a Rust programmer.

I'm also somewhat shocked, as I genuinely wouldn't have expected Crystal Palace's pipeline to work this far outside of the original scope.

You're clearly friends with Iced. I'm looking at how you extended the CallWalker to account for jmp QWORD to a function call. Is jmp QWORD of Rust's tail call-optimization?

Did you run into other gotchas here too?

I'd consider using this within the runner itself to break one large string down into an arg array.

learn.microsoft.com/en-us/window...