<Forlax> x64dbg can be scripted to auto add patches?
Cos there is nothing about that beside debugging stuffs in the documentations https://i.imgur.com/nBb9ndV.png
Cos there is nothing about that beside debugging stuffs in the documentations https://i.imgur.com/nBb9ndV.png
<Forlax> mrexodia, is this possible with the current engine that x64dbg uses or it's not in there yet. Because I got no clue, I asked around and they sent me here.
<mrexodia> What are you trying to do?
<Atn> Add ?
<kofteror> Yup..
<mrexodia> Sorry I forgot to answer. Check the “mov” instruction (re @x64dbg_bot: <Forlax> mrexodia, is this possible with the current engine that x64dbg uses or it's not in there yet. Because I got no clue, I asked around and they sent me here.)
<mrexodia> You can mov a byte pattern in a location
<mrexodia> And there is also a command to assemble
<levitanious> Right click on an opcode and then -- assemble. You can find code caves or make your own.
<levitanious> Then you just assemble whatever you want there and then patch to preserve changes.
<mrexodia> Also multimate assembler is a great plugin worth mentioning
<billy-jon> it seems like it has something to do with how bps are stored. if i create them after the remapping, im guessing that the debugger doesn't know to store them as relative to a particular module's base address and instead stores absolute addresses
<billy-jon> but if i restart the process and there now IS a module there, even though the literal address is unchanged, things bug out
<mrexodia> Breakpoints are stored as module+rva or if there is no module as an absolute address
<billy-jon> sorry, i had been under the impression that you have looked at the blizzard anti debug stuff. they will remap the binary with CreateFile(), memcpy, MapViewOfFile() or some such thing to give SEC_NO_CHANGE to the whole binary. just like what is described here: https://github.com/changeofpace/Self-Remapping-Code
<billy-jon> incidentally it would be awesome if the db files for each program could be plaintext like json or something so i could go and remove those bps manually
<Nukem> they are plaintext/json if compression is disabled
<billy-jon> once the debugger encounters an int3 bp it doesnt expect to be there, i cant figure out how to get execution to continue
<billy-jon> oh look at that, thanks
<billy-jon> they are in the dd64 file for the binary as absolute addresses
<billy-jon> if i start the process, paused at the entry point, i cannot delete those bps
<billy-jon> it says: No such breakpoint "0x<address>"
<billy-jon> erm, no 0x
<billy-jon> it seems like there is some kind of sanity check on whether an int3 is due to a bp created by the debugger, and that sanity check does not support remapped code. something like this: "is_my_int3(ea) { if is_in_module(ea) and rva_bp_exists(ea_to_rva(ea)) { return true; } else if abs_bp_exists(ea) { return true; } else { return false; }"
<billy-jon> but probably when the bp is first applied it should remember the ea and check against that later on
<mrexodia> “Can do that” haha
<mrexodia> More like kinda can do it maybe
<levitanious> (also pretty badass)
<levitanious> A wise old man once said: "You make a punchline of what i cannot do and berate me for what i can... send, patches young one!" 😂
<kaens> People would even berate the wise men :<
<levitanious> But the idea! That matters.
<levitanious> <attempt at humour, badum-tsss>
<kaens> A wisecracker is one who can make em patches, amirite?
<Nukem> lol
<kaens> Wish I could chat to the Chinese community. Keep seeing so many weird protections for minor engines