Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 05 17:47
    mrexodia deleted #2797
  • Dec 05 16:48
    ZehMatt closed #2797
  • Dec 05 16:48
    ZehMatt commented #2797
  • Dec 05 15:45
    lsh7161 edited #2797
  • Dec 05 15:44
    lsh7161 labeled #2797
  • Dec 05 15:44
    lsh7161 opened #2797
  • Dec 05 15:44
    rajkumarananthu commented #2752
  • Dec 05 15:43
    rajkumarananthu commented #2752
  • Dec 05 14:28

    mrexodia on development

    Attempt to scale the column wid… (compare)

  • Dec 04 15:30
    mrexodia commented #2752
  • Dec 04 11:52
    mrexodia assigned #2752
  • Dec 04 05:25
    rajkumarananthu commented #2752
  • Dec 03 13:42
    mrexodia commented #2752
  • Dec 03 10:43
    rajkumarananthu commented #2752
  • Dec 03 03:27

    mrexodia on development

    Update FUNDING.yml (compare)

  • Dec 03 03:26

    mrexodia on development

    Update README.md (compare)

  • Dec 03 01:13
    stevemk14ebr closed #2278
  • Dec 02 13:49
    SNOW-Loli commented #2796
  • Dec 02 13:28
    SNOW-Loli commented #2796
  • Dec 02 13:11
    mrexodia commented #2796
x64dbgbot
@x64dbgbot
<morsisko> but in case of x64dbg the loop is not needed, it look like something another is feeding the dialog queue with messages
<morsisko> not sure if it's implemented on Qt level or what, because I don't see it anywhere in the x64dbg source
<morsisko> but the message queue of my dialog is indeed filled with messages to dispatch
<mrexodia> It’s in qt
<mrexodia> But your dialog isn’t related to qt
<mrexodia> If you pump on the same thread as you created the dialog on it’ll work
<mrexodia> Or are you creating a qt dialog?
<morsisko> Nah, I'm using the native winapi CreateDialog
<mrexodia> So then messages will be pumped by user32
<mrexodia> CreateWindow needs a loop
<mrexodia> DialogPaeamW or whatever doesn’t
<morsisko> Ah, that's the reason
x64dbgbot
@x64dbgbot
<morsisko> It's kinda strange anyway, because then the "tab" key doesn't work well, but as far as I remember it worked fine with the standard dialog
<mrexodia> Hm
<mrexodia> That is weird
<morsisko> like as now you can't use tab key inside dialog without making some strange thing like subclassing inputs that are focused
<morsisko> and I see that almost every plugin for x64dbg works like this
<morsisko> (you can't use tab to switch to the next input)
<mrexodia> It could definitely be a qt issue
<morsisko> I see that with casual event loop you need to add the "IsDialogMessage" like this:
while (GetMessage(&msg, 0, 0, 0) > 0)
{
  if (!IsDialogMessage(hwnd, &msg))
  {
    TranslateMessage(&msg);
    DispatchMessage(&msg);
  }
}
<morsisko> but as the dialog got the default one, don't think there is a good way to implement this
<morsisko> but yeah that is strange, I think you can use the tab key in the native windows dialogs without any problem
x64dbgbot
@x64dbgbot
<mrfearless> Its possible to use a separate thread and then run CreateDialogParam (as an example), and use your own event loop after with the IsDialogMessage as you have above
x64dbgbot
@x64dbgbot
<morsisko> Damn this is good idea, but can i call the x64dbg from other threads in safe manner?
x64dbgbot
@x64dbgbot
<morsisko> I mean x64dbg api functions
<morsisko> Because i see this can get more complicated then
x64dbgbot
@x64dbgbot
<mrexodia> Yeah the apis should be thread safe (re @x64dbg_bot: <morsisko> Damn this is good idea, but can i call the x64dbg from other threads in safe manner?)
x64dbgbot
@x64dbgbot
<mrfearless> I did create an x64dbg plugin for auto updating, but I never released it publicly, just as a test to a few users - seemed to work mostly ok - altho there was an occasional crash if exiting x64dbg whilst that thread was active for that plugin - cant recall if i resolved that, so thats the only thing to worry about as far as i know.
x64dbgbot
@x64dbgbot
<testpil0t> That sounds interesting. I personally would prefer to have it on chocolatey tho (re @mrfearless: I did create an x64dbg plugin for auto updating, but I never released it publicly, just as a test to a few users - seemed to work mostly ok - altho there was an occasional crash if exiting x64dbg whilst that thread was active for that plugin - cant recall if i resolved that, so thats the only thing to worry about as far as i know.)
x64dbgbot
@x64dbgbot
<EvilSapphire> In CB_MENUENTRY callback function can we ever get an hEntry value from x32dbg that was not registered while registering the menus with _plugin_menuaddentry?
x64dbgbot
@x64dbgbot
<mrfearless> well the info pointer of CBMENUENTRY points to the PLUG_CB_MENUENTRY structure, which has the hEntry field
<mrfearless> you would only be able to check the hEntry against menu items you yourself added for your plugin
<mrexodia> Should not be possible (re @EvilSapphire: In CB_MENUENTRY callback function can we ever get an hEntry value from x32dbg that was not registered while registering the menus with _plugin_menuaddentry?)
<mrexodia> Personally I use an enum
<mrfearless> same - altho in asm its just static vars: ; Plugin Menu IDs
MENU_OPTIONS EQU 1
MENU_CHECKNOW EQU 2
MENU_CHECKNOW_SILENT EQU 3
MENU_CHECKONSTARTUP EQU 4
MENU_CHECKONIDLE EQU 5
MENU_REMINDDOWNLOADED EQU 6
MENU_ABOUT EQU 7
x64dbgbot
@x64dbgbot
<mrexodia> Yeah it’s your own enum that you get back
<mrexodia> Internally there is another id but it’s not exposed iirc
x64dbgbot
@x64dbgbot
<EvilSapphire> In scyllahide the CB_MENUENTRY function checks for the passed hEntry via a switch case and there's cases for the registered entries, but also a default case where the actual hookdll injection happens
<mrexodia> I don’t think it’s called
<EvilSapphire> What do you mean?
<EvilSapphire> It definitely registers a menu
<EvilSapphire> With menu entries for about, injection etc
<EvilSapphire> With the entry ids that are checked with a switch case on the callback CB_MENUENTRY registered function
<EvilSapphire> From what you guys say I'm doubtful execution would even reach the default case (re @EvilSapphire: In scyllahide the CB_MENUENTRY function checks for the passed hEntry via a switch case and there's cases for the registered entries, but also a default case where the actual hookdll injection happens)
<EvilSapphire> Registering the menus with the MENU_* entries:
<mrexodia> Yeah that’s what I meant (re @EvilSapphire: From what you guys say I'm doubtful execution would even reach the default case)
<mrexodia> The MENU_XXX will be in the hEntry
<mrexodia> But there’s no default case iirc
<mrfearless> maybe if hEntry is 0?
x64dbgbot
@x64dbgbot
<mrfearless> but seems unlikely