3

I'm trying to understand and patch the GUI in Microsoft Edge. When I look at the disassembly in 2 different debuggers (x64dbg and cutter), the API calls responsible for much of the GUI functionality is completely missing. I look at the SYMBOLS and IMPORTS tabs to try and find them, but they're not there. Searching the disassembly for certain function names does not turn up any results.

I know that these API calls are being made because they come up in an API monitor (I'm using the rohitab API monitor).

So, to recap, API calls are being made (I can see them ), but the calls themselves do not appear in the disassembly (in 2 different debuggers!).

I'm not very experienced with reverse engineering but I know from common sense that if you can't,

  • Know what libraries the program uses, and
  • Know where in the instruction sequence it's using them.

Then you can't understand what's going on. Am I missing something here? Is it that certain USER32.dll functions just don't show up in debuggers? I'm looking for SetBkColor, SetTextColor, and SelectObject to name a few.

I just want to be able to set breakpoints at certain API calls.

How can I do that?

Improve this question
5
  • 1
    You forgot to mention what file you have created the disassembly of. Also keep in mind that not all functionality has to be implemented in the main executables. A program consists of the EXE file and a set of program specific DLL files. The imports of the main exe file only cover the functionality implemented in the EXE file itself. So you have to also check all program specific DLL files for imports.
    – Robert
    Jun 25, 2022 at 11:45
  • @Robert The file is msedge.exe . Should be "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" in Windows. Now, it's interesting what you say about the disassembly having only the exe functionality itself. I would think that at least the calls to these APIs would be in the disassembly (not the APIs or function definitions themselves, just the calls), because the program needs what is returned from them in order to function, right? How do I track what line of code called the API? Again, I can see what APIs were called because of an API monitor, I just want to set some breakpoints.
    – n0rmalguy011
    Jun 25, 2022 at 17:44
  • 1
    If you use a debugger check the list of loaded libraries, I assume you will find a lot DLLs that do not belong to Windows.
    – Robert
    Jun 25, 2022 at 18:32
  • @Robert Could you explain what you mean by DLLs that do not belong to Windows? And how that is related to what I just asked? No matter what, the DLLs run on the windows OS, yes? And if they are loaded by the program, they are used somewhere in the assembly code, right? I just want to know how to see where in the code the functions are being called so that I can set breakpoints on them and track what happened before and after the call.
    – n0rmalguy011
    Jun 26, 2022 at 2:35
  • Uhm, I think you are missing the obvious: 1.) look at the Chromium source to get started 2.) there's little (not nothing!) in the way of what resides in win32u.dll/win32k.sys, because modern browsers and many modern apps use DirectDraw, Direct2D and similar methods and completely draw their controls themselves. They are no longer classical windows in the sense user32.dll treated framed windows and their controls. You can even verify my claim by using Spy++ (or alternatives) to observe that all these fancy controls aren't windows anymore. For Opera this was true many years ago already.
    – 0xC0000022L ♦
    Jul 5, 2022 at 8:13

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Browse other questions tagged or ask your own question.