<EvilSapphire> Attach happens by checking the createprocessinfo.lpstartaddress == null
<EvilSapphire> Which happens if you attach to a process instead of starting it, and it attempts injection inside that switch case
<EvilSapphire>
<EvilSapphire>
<EvilSapphire> You can see the if(!bhooked) block is there only for doing the injection in case of an attach as the later xdbg version doesn't provide plugins with an exception debug event in case of attaching to a process, so the original injection inside exception event switch block wont trigger
<EvilSapphire> Anyway we still don't have the answer to the initial peb confusion I guess
<Matti> no, and I don't currently have time/ability to check it out properly
<Matti> can you make an issue on the scyllahide github for it?
<Matti> I'm not really concerned about ntdll doing the system bp, but this may also be affecting things like its decision to create a normal vs debug heap for example
<Matti> which are visible to the process
<Matti> just do "system breakpoint is reached even though PEB options are checked"
<Matti> but yeah that sounds like the cause
<EvilSapphire> Ohh okay. Will do.
<EvilSapphire> Can I do a pull request and fix it? So far looks like a simple issue of initialising the specialpebfix to true instead of false
<Matti> ehhhhh
<Matti> sure, of course you can
<Matti> but I'd be wary of it being called 'specialpebfix'
<Matti> it is likely a hack, a hack on top of a hack, or a hack to workaround another hack
<Matti> there aren't a lot of things that work straightforward in scyllahide
<Matti> but you're the one looking at the code, not me, so it's possible you're right and that this happened due to some bad merge or whatever
<EvilSapphire> Lol okay. I checked all the references to specialpebfix and it looks like this way for now, but I should look into it more before fixing it. Sounds good. I'll open the issue though.
<EvilSapphire> I guess given what it's for scyllahide is never meant to work straightforward. It's meant to be a hack plugin xD
<EvilSapphire> I was actually worried of it breaking xdbg so that's why I was looking into the code in the first place before using it during my work
<Matti> AFAIK this can't be done, but maybe I'm wrong
<mrexodia> Hm yes, there is a kind of undocumented thing you can do (re @EvilSapphire: Okay another noob question since I can't find a clear answer anywhere, is it possible to set a multiline script like break condition in breakpoints? Like defining a function and breaking acc to the return value or something like that?)
<mrexodia> You can use https://help.x64dbg.com/en/latest/commands/script/scriptcmd.html
<mrexodia> but you need to load the script for that separately
<EvilSapphire> I submitted the scyllahide issue. Funny thing is when xdbg pauses at system breakpoint, I checked isDebuggerPresent in PEB and it shows to be false
<EvilSapphire> So something in between is indeed patching the peb, but not quick enough for it to pass under the radar for the system breakpoint check
<Matti> interesting
<Matti> thanks, I'll take a look when I have time (no promises...)
<EvilSapphire> No problem. I'll keep looking into it too.
<OxZoRo> I have questions ,
Sometimes when i debugging C programs , sometime i get the main function and i can read it , but the changes with the variables names , and comments deleted.. , and sometime i cant see anything’s readable!
Sometimes when i debugging C programs , sometime i get the main function and i can read it , but the changes with the variables names , and comments deleted.. , and sometime i cant see anything’s readable!
- so what is going on there ? or the programer compiled the program differently or he doing some thing to keep it unreadable.
- i know it’s be like a stupid qus , but it’s from someone didn’t have a lot of information about RE , and still learning english🌹 .
<mrexodia> This is not the right place to ask general RE questions
<Matti>
(...etc...)
2>C:\Dev\x64dbg\src\dbg\commands\cmd-general-purpose.cpp(328,47): error C3861: if(!valfromstring(argv[1], &dest) || !MemIsValidReadPtr(dest))
2>C:\Dev\x64dbg\src\dbg\commands\cmd-general-purpose.cpp(328,47): error C3861: ^
2>C:\Dev\x64dbg\src\dbg\commands\cmd-general-purpose.cpp(334,13): error C3861: 'MemPatch': identifier not found
2>C:\Dev\x64dbg\src\dbg\commands\cmd-general-purpose.cpp(334,13): error C3861: if(!MemPatch(dest, data.data(), data.size()))
2>C:\Dev\x64dbg\src\dbg\commands\cmd-general-purpose.cpp(334,13): error C3861: ^
2>C:\Dev\x64dbg\src\dbg\commands\cmd-debug-control.cpp(26,5): error C3861: 'MemRead': identifier not found
2>C:\Dev\x64dbg\src\dbg\commands\cmd-debug-control.cpp(26,5): error C3861: MemRead(exceptionAddress, data, sizeof(data));
2>C:\Dev\x64dbg\src\dbg\commands\cmd-debug-control.cpp(26,5): error C3861: ^
2>C:\Dev\x64dbg\src\dbg\analysis\AnalysisPass.cpp(19,9): error C3861: 'MemRead': identifier not found
2>C:\Dev\x64dbg\src\dbg\analysis\AnalysisPass.cpp(19,9): error C3861: if(!MemRead(VirtualStart, m_Data, m_DataSize))
2>C:\Dev\x64dbg\src\dbg\analysis\AnalysisPass.cpp(19,9): error C3861: ^(...etc...)
<Matti> turns out there's a nice new header named memory.h at
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\memory.h
<Matti> so when dbg/analysis/xx.cpp or dbg/commands/xx.cpp try to include memory.h, they get that instead
<Matti> I see the include dirs are set under 'VC++ directories' -> 'include directories' in the project settings
<Matti> I'm pretty sure they should be under 'C/C++' -> 'additional include directories' instead
<Matti> if I put e.g. $(ProjectDir) there, the issue is fixed