Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 06:36
    gituser5555 opened #2699
  • Jul 26 21:10
    bitRAKE commented #2654
  • Jul 26 20:52
    bitRAKE commented #2654
  • Jul 26 20:43
    bitRAKE commented #2654
  • Jul 26 20:28
    morsisko commented #2654
  • Jul 26 20:24
    morsisko commented #2654
  • Jul 26 20:22
    bitRAKE commented #2654
  • Jul 26 20:19
    bitRAKE commented #2654
  • Jul 26 20:16
    bitRAKE commented #2654
  • Jul 26 20:16
    bitRAKE commented #2654
  • Jul 26 20:15
    bitRAKE reopened #2654
  • Jul 26 20:15
    bitRAKE commented #2654
  • Jul 26 20:09
    Tester798 commented #2523
  • Jul 26 20:07
    bitRAKE closed #2654
  • Jul 26 20:07
    bitRAKE commented #2654
  • Jul 26 18:31
    mrexodia commented #2694
  • Jul 26 18:31

    mrexodia on development

    Add shortcuts in Goto dialog Merge pull request #2694 from t… (compare)

  • Jul 26 18:31
    mrexodia closed #2694
  • Jul 25 20:02

    mrexodia on development

    Add temporary label support for… Merge pull request #2695 from Z… (compare)

  • Jul 25 20:01
    mrexodia closed #2695
x64dbgbot
@x64dbgbot
<EvilSapphire> Yeah it's scyllahide
<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>
x64dbgbot
@x64dbgbot
<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
x64dbgbot
@x64dbgbot
<EvilSapphire> Issue for what? Execution never reaching the pebfix code?
<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
x64dbgbot
@x64dbgbot
<Matti> so there may be side effects to doing this that aren't so obvious
<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
x64dbgbot
@x64dbgbot
<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?
x64dbgbot
@x64dbgbot
<Matti> that's one for mrexodia I'm afraid
<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> but you need to load the script for that separately
x64dbgbot
@x64dbgbot
<EvilSapphire> I'll look more into this
<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
x64dbgbot
@x64dbgbot
<Matti> hmm
<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.
x64dbgbot
@x64dbgbot
<OxZoRo> Hey guys .
x64dbgbot
@x64dbgbot
<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!
  • 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
x64dbgbot
@x64dbgbot
<OxZoRo> Oh sry then 🌹. (re @mrexodia: This is not the right place to ask general RE questions)
x64dbgbot
@x64dbgbot
<Matti> ran into a nice issue with the new windows SDK that took me a while to figure out >.<
<Matti> 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