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> because normally when you, for example, create dialog in your application using CreateDialog() you need to pass the messages to the dialog with loop similar I've posted above (not sure if you messed with the winapi gui before)
<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
x64dbgbot
@x64dbgbot
<morsisko> Ah, that's the reason
<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?