#x64dbg

/

      • x64dbgbot
        <athre0z> I'm currently in the progress of abstracting away more and more parts the disassembler library itself behind the wrapper class, reducing the amount of CS/zydis constants and structures in the debugger & gui logic. however, there's a limit to what can be done at zero-overhead-level. what's your stand on that? should we rather cleanly tuck the disassembler engine away behind a single facade or stick with accessing disas-engine-specific structs
      • <athre0z> but avoiding copying of data?
      • <athre0z> personally, I'd opt for abstracting at the (probably very minor) cost of copying some info
      • <athre0z> mh, probably we can even make it near zero overhead with use of accessors
      • <athre0z> another thing: what do you guys think about renaming "TokenType::MnemonicPushPop" to "TokenType::MnemonicStackOp" and expandings its scope to all instructions that perform writing access to rSP, e.g. stuff like `add rsp, 16`?
      • <athre0z> (with a higher precedence for instruction with a more specific category, like `ret`, obviously)
      • munch has quit
      • munch joined the channel
      • munch has quit
      • munch joined the channel
      • athre0z joined the channel
      • StepS joined the channel
      • StepS has quit
      • StepS joined the channel
      • yonder has quit
      • NWMonster joined the channel
      • StepS has quit
      • athre0z
      • x64dbgbot
        <mrexodia> athre0z I don't know if changing the push pop thing is a good idea
      • <mrexodia> At least not before Zydis output is compared with capstone thoroughly
      • athre0z
        alright. so then, how do we go with comparing them? just c&p the capstone class and the tokenizer, then do the mentioned int3 if they clash and do some normal debugging? that would still leave all the other aspects like graphs untested
      • x64dbgbot
        <mrexodia> Well, I don't assume Zydis reports invalid branch destinations?
      • <mrexodia> Because the graph just uses the QBeaEngine to tokenize
      • <mrexodia> But if the Capstone class from capstone_wrapper is copied all the return values of helper functions can be compared
      • athre0z
        well yeah. the issue is that a pretty big part of the codebase accesses the raw disassembler structs directly and not everything in zydis and CS is a 1-1 mapping
      • x64dbgbot
        <mrexodia> Yeah that's true
      • athre0z
        for example, we have operand sizes in bits, CS in bytes
      • so I had to change quite a bit of stuff
      • x64dbgbot
        <mrexodia> Yeah
      • <mrexodia> Well, mostly I'm interested in the tokenizer output
      • <mrexodia> So if copies are made from the capstone class and QBeaEngine the tokenizer of Zydis can call the capstone one and compare the output tokens
      • <mrexodia> It should be very doable
      • athre0z
        will do
      • I assume x64dbg only tokenizes/formats the stuff in the screen region and possibly a tiny range around the visible window?
      • x64dbgbot
        <mrexodia> Yeah
      • <mrexodia> It should so scrolling around in a few big executables and logging mismatches should pop up quite a few things
      • athre0z
        I should probably hack together a stub that disassembles and formats all modules or something
      • x64dbgbot
        <mrexodia> Perhaps
      • <mrexodia> I'm pretty sure scrolling around might pop up some small bugs
      • <mrexodia> But after that probably not too much
      • athre0z
        well, what certainly will clash quite commonly is mnemonic names
      • jz vs je etc
      • we currently have 100% intel SDM defined mnemonics
      • any preference on your side regarding those, btw? we're currently considering to switch to the more intuitive ones for jumps, but we haven't quite decided, yet
      • e.g. "JA" seems so much more obvious then the intel procided "JNBE" IMHO
      • x64dbgbot
        <mrexodia> Definitely
      • <mrexodia> But my preference is in x64dbg
      • <mrexodia> I guess Intel produces them how they are implemented or something?
      • athre0z
        yeah, I guess so
      • g11 has quit
      • Semlar has quit
      • Semlar joined the channel
      • NWMonster has quit
      • NWMonster joined the channel
      • NWMonster has quit
      • StepS joined the channel
      • dummys
        mrexodia question for you
      • do you have tutorial for the type system you mentionned here: https://github.com/x64dbg/x64dbg/issues/1268 ?
      • x64dbgbot
        <mrexodia> There is a blog
      • dummys
        is it possible to register a "callback" for example when debugging a PE, the structure is showed in the view -> memory view like in olly for example ?
      • x64dbgbot
        <mrexodia> Ah
      • <mrexodia> There is no tutorial
      • <mrexodia> But the relevant code is commented
      • dummys
        same for elf for example
      • x64dbgbot
        <mrexodia> The command is
      • <mrexodia> Hm
      • <mrexodia> Forgot
      • <mrexodia> It's in cmd-types
      • <mrexodia> And the structure is in bridgemain.h
      • dummys
        and there is no plugin already ?
      • because malware reverser use this a lot
      • because I tried to avoid using olly to reverse and use only x64dbg
      • but it remains some juicy stuff available only in olly still
      • x64dbgbot
        <mrexodia> Like what?
      • dummys
        tracing window, information about windows api when calling
      • x64dbgbot
        <mrexodia> I'm on my phone
      • dummys
        parsing of usefull windows structures
      • like PEB
      • x64dbgbot
        <mrexodia> But if you know c++ or c it's not hard
      • <mrexodia> I can find the relevant code if you want
      • dummys
        ok, it could be a cool project to start writing c/c++
      • never found good "little" project to start it
      • should not be hard to start right ?
      • x64dbgbot
        <mrexodia> Not at all
      • <mrexodia> Visual studio
      • <mrexodia> And plugintemplate
      • <mrexodia> See plugins.x64dbg.com
      • <mrexodia> You have to know that a display of the types is a tree
      • <mrexodia> And you have GuiAddTypeNode (or something like that)
      • dummys
        ok
      • will try to do that then
      • usefull stuff for the core imho
      • because your debugger is for PE
      • NT Header/PE Header/PEB is always cool to have
      • nobody has already tried to reimplement the API calls like olly in x64dbg ?
      • x64dbgbot
        <Smiling_Wolf> @ThunderCls I think
      • dummys
        I see that many many malware reverser don't move to your debugger
      • and I'm always wondering why, because it just rocks
      • as a plugin ?
      • x64dbgbot
        <Smiling_Wolf> Yep
      • athre0z
        people are usually just insanely lazy when it comes to adapting to new tools. i know a guy who was still using softice in 2010
      • dummys
        those stuff should be not in a plugin
      • I'm ok to keep the core very light, but for me it's mandatory stuff on a debugger like this
      • jachome joined the channel
      • lol athre0z softice...
      • x64dbgbot
        <mrexodia> dummys I started to implement pe parsing
      • <mrexodia> But immediately stopped because alignment is really complicated and almost completely undocumented
      • dummys
        oh yeah
      • did you know if the source code of olly is available ?
      • x64dbgbot
        <mrexodia> And you can just use the favorite tools feature
      • <mrexodia> You can add a favorite menu that opens the binary currently in the cpu in cff Explorer for example
      • dummys
        ok I see
      • x64dbgbot
        <mrexodia> But start implementing a parser for the peb or pe
      • <mrexodia> I will help with the apj
      • dummys
        ok, I will try to find some time doing this
      • x64dbgbot
        <mrexodia> And if it's not too complicated we can add it in x64dbg
      • dummys
        yep ok
      • x64dbgbot
        <mrexodia> The relevant command is "VisitType"
      • <mrexodia> It walks the type and adds nodes to the struct view
      • dummys
        sweet I take not when I start it
      • athre0z
        mh. for imms, in zydis, we report the physical operand size like documented by intel, capstone seems to report the effective operand size (what it'd be like after it was padded, e.g. 8 bytes for a "mov rax, 1" with 1 byte imm). is the capstone behavior what you were looking for in the tokenizer or is that just something you couldn't change? should I put the padded size as well?
      • seu has quit
      • seu joined the channel
      • x64dbgbot
        <mrexodia> I think the padded size is most relevant
      • <mrexodia> Although for immediate values I'm not sure if it's used