<EvilSapphire> Yeah they just take care of the profiles. No idea what that means though
<EvilSapphire> Why the actual injection would happen in these so called profiles is beyond ne
<mrexodia> Different settings for different protections
<mrexodia> It doesn’t just happen there (re @EvilSapphire: Why the actual injection would happen in these so called profiles is beyond ne)
<mrexodia> It also happens in another place
<mrexodia> But if you change the profile the injection happens again
<EvilSapphire> Ohh okay
<EvilSapphire> Yes I also saw it happens inside the debugloop callback function when the process is created
<EvilSapphire> Did you guys develop scyllahide?
<mrexodia> No, I just made some minor fixes
<EvilSapphire> I'm reading through the code and trying to understand exactly how it works right now
<mrexodia> It was originally created by NtQuery
<mrexodia> And now Matti is maintaining it
<mrexodia> But I developed x64dbg ^^
<EvilSapphire> Yeah of course that is world news at this point :P
<EvilSapphire> So in scyllahide the plugin upon process create injects the hooklibrary, and the hooklibrary takes care of the popular api hooking to fool anti debug measures?
<EvilSapphire> Overall is that how the workflow is?
<mrexodia> From what I remember, yes
<EvilSapphire> Yay. At least I'm not a total idiot xD
<EvilSapphire> I'll leave the question here just in case Matti sees it too
<Matti> I see it, and the answer is yes
<Matti> actually I should elaborate
<Matti> hooklibrary_xx.dll provides the hooked functions themselves
<Matti> but the hooking of the functions is done by the debugger plugin / CLI exe
<Matti> so I guess it depends on which of the two you meant
<EvilSapphire> Yup. Got it.
<EvilSapphire> One more thing, looking through the code I found if the debugee is started by x64dbg, the actual injection doesn't happen at create process debug event, rather the first breakpoint exception event
<EvilSapphire> And after that first injection happens a bool bhook is set to true which instructs scyllahide to attempt injection on each subsequent dll load event. Which I guess is done to hook functions from all the subsequently loaded dlls
<EvilSapphire> But why is the first injection done on a breakpoint exception event instead of the create process exception event
<mrexodia> Likely because otherwise it won’t execute any of the hooking code (re @EvilSapphire: But why is the first injection done on a breakpoint exception event instead of the create process exception event)
<mrexodia> You cannot really control rip before the system breakpoint iirc
<mrexodia> Unless you hook LdrInitializeThunk
<EvilSapphire> Ohh okay so the first breakpoint exception event is the mysterious system breakpoint?
<mrexodia> I don’t know for sure
<mrexodia> The system breakpoint has its own callback for sure
<mrexodia> But it might also trigger a debug event callback
<EvilSapphire> Well I'm debugging the plugin loaded xdbg with another xdbg, and the debugger xdbg receives the exception breakpoint, and if I let that run the debugee xdbg reaches system breakpoint right after without any other debug event
<mrexodia> Yeah that’s probably it then
<EvilSapphire> Maybe the first bp exception event is treated as the system breakpoint and given its independent callback?
<EvilSapphire> You designed it :P
<mrexodia> Thanks how it is delivered internally
<mrexodia> But normally you’d use the system breakpoint event for this purpose, not a breakpoint debug event
<EvilSapphire> Yeah got it
<EvilSapphire> So system breakpoint is pretty much a xdbg terminology?