<mrexodia> Yeah jesus (re @x64dbg_bot: <Nukem> i see that we are still getting the stop emails lol)
<billy-jon> right. but if i do restart process it seems i need to do that again?
<mrfearless> yes
<billy-jon> so im asking if there is a way to have it re-apply automatically the way breakpoints do
<mrfearless> there are a few patch related functions in the DbgFunctions: PatchGet, PatchInRange, MemPatch, PatchRestoreRange, PatchEnum, PatchRestore, PatchFile, PatchGetEx
<mrfearless> just would need to register a command and tie in the logic to call the appropriate function
<mrfearless> and do error checking, make sure target debuggee is loaded etc
<billy-jon> that's a good point. there may not be a universally acceptable time to install them. but i guess whenever the bps are applied should work for this too?
<mrexodia> There is a plugin (re @x64dbg_bot: <billy-jon> so im asking if there is a way to have it re-apply automatically the way breakpoints do)
<billy-jon> oh cool
<billy-jon> ahh https://github.com/x64dbg/AutoExportPatches
<Tornikepa> Now i see blank space
<Malware Utkonos> it doesn’t work and appears to do a lot of work before failing
<Malware Utkonos> i should say it doesn’t do anything, but it takes a long time
<Ab> I'm not at my desk atm
<billy-jon> i wonder if i may have discovered a bug in x64dbg. while analysing a malware sample, a call to VirtualProtect() which attempts to set PAGE_EXECUTE_READWRITE for the whole module [base, base+PEHeader->SizeOfImage] causes the .text segment to vanish from the memory map and be considered invalid by x64dbg. however if i step through i can see RIP proceeding as expected through those addresses. there is also a rep movsb instruction shortly after the
<billy-jon> VirtualProtect() call which successfully copies data from the now-vanished .text segment. i looked for some kind of a hook on VirtualProtect() and found none.
<billy-jon> i tried reproducing it in a hello-world cpp file, but there it behaves normally
<billy-jon> and regardless of what is going on, x64dbg should never forget about this memory i think?
<billy-jon> my next step was to try and build my own x64dbg and debug it, find where the code is that forgets about the .text segment, and try to learn why it is deciding to do that
<mrfearless> it probably sets up an exception handler and when the protected memory is hit it checks for type of exception - single step etc = debugger, otherwise unprotect the memory and continue - think i read about this recently with some post on twitter or somewhere relating to malware or ransomware
<mrfearless> this was the reference i was thinking of: https://secrary.com/Random/anti_re_simple/
<billy-jon> i have a bp on the indirect call to VirtualProtect(), which i have stepped through one instruction at a time. the .text segment disappears only following the syscall instruction with id 0x50 (which is the correct id)
<billy-jon> the indirect call is within the .text segment and there is nothing special about it at this point afaik
<billy-jon> i guess they might be using an instrumentation callback to hook the return to usermode following the syscall? o.O
<billy-jon> ive never tried it but im assuming that x64dbg would pickup an instrumentation callback since RIP would be different than the value following the syscall instruction
<n> bpx is not working
<mrexodia> Maybe. The problem is that x64dbg has a different idea of reality with regards to memory per default, but yeah probably the header shouldn’t disappear (re @x64dbg_bot: <billy-jon> and regardless of what is going on, x64dbg should never forget about this memory i think?)
<shaddycls> findout that the syntax is:
init "binary.exe","arg1 arg2 ..."
init "binary.exe","arg1 arg2 ..."