That's what I'm doing here too. 75% of my BlueSky responses are validated by having run a test case locally. The other 25% I give out information that's wrong and misinformed.

Other option would be: make a setupapi(MYEXT_IMPORTFUNCS *) in the module w/ APIs, assign all of the ptrs there, and call from other module. In my local testing, I got an instruction form DFR didn't like (completely actionable)... soo... maybe next release for this approach :)

imports works here from PIC (w/ a BOF runner). But, if you refer to a function pointer across module boundaries (e.g., API is in one file, you assign to extended IMPORTFUNCS in another post merge)--you'll get these relocs. Try combining them into one file (easiest).

And, I misspoke. remap + merge won't work, because __declspec(dllimport) means the compiled code tries to load [IAT slot of MOD$Func], %reg; CALL %reg. Tested remap + attach works.

No miracles though. Anything with a .data (init'd global vars) section won't work.

I did remap "__imp_BeaconPrintf" "__imp_BEACON$BeaconPrintf" foreach API. dfr "resolve_bof" "strings" "BEACON". I was testing DFR out. :) I'd prefer to merge API. Maybe remap "__imp_BeaconPrintf" "BeaconPrintf" could work? Use exportfunc/PicoGetExport to call API to get output?

Some of my unit tests run various BOFs as PICOs. I do import "LoadLibraryA, GetProcAddress, BeaconDataAlloc, ..." to give them the API from the PICO runner.

I've experimented with running some BOFs as PIC too... but more to unit test/push Crystal Palace's features vs. "best practice"

I love the keystroke logging demo concept. Neat to see how a GetProcAddress hook to MSVCRT$_fputc becomes the agnostic path to demo/pair your IPC library as an output mechanism for a keystroke logger DLL.

I've also updated Crystal Loaders to benefit from some of the new CP features github.com/rasta-mouse/...

There's one piece to this model that's missing yet. I want a development and demonstration model that's not C2 and is arm's length from it. The goal is to create a safe undeniable ground truth framing for researchers that want to publish publicly. Separate of but usable with C2 is still key though

Mixing and matching what? Well, take this Hardware Breakpoint PICO which is a start towards a reusable API to dork with Win32 APIs in the current process (e.g., AMSI)--tradecraft building blocks packaged in a quick-to-use in multiple ways format.

github.com/ofasgard/har...

It becomes an opportunity to PAIR the cutting-edge evasive tradecraft ideas with a .NET launcher + .NET tools to see how, for whatever purpose you're applying it, the tradecraft modifies or impacts signals or existing detection/response/mitigation approaches. The power of mix and matching this stuff