none
mapping Function names and Memory addresses RRS feed

  • Question

  • Hey all,
     
    I am working on a WinDBG extension that can alter data of a running application. 
    My requirement is to get the memory address of a given function name.
    Is there a way to do the same (a direct command or a set of commands).
     
    Thanks in advance.
    Tuesday, December 11, 2012 6:54 AM

Answers

  • Are you working with .NET application? If yes, then mapping functiona names to addresses is no longer required. You can use SOS extension with WinDbg.

    http://www.dotnetcurry.com/ShowArticle.aspx?ID=648

    http://stackoverflow.com/questions/13116549/stepping-through-source-code-using-windbg-sos-extension


    Please mark this post as answer if it solved your problem. Happy Programming!

    • Marked as answer by Deepjot_Singh Wednesday, December 12, 2012 6:33 AM
    Tuesday, December 11, 2012 8:55 AM
  • When you need to find the address at which a known function or a global variable resides, you can
    use the x command of the windbg.exe debugger. This translation is often useful when trying to set
    code or data breakpoints. For this to work, naturally, the module (DLL or main EXE) that contains the
    function or global symbol should’ve already been loaded by the target process. Note that this command
    also supports the wildcard character (*), which is often convenient for discovering the available
    symbol (function or global variable) names that match a given pattern
    .
     
    0:000> x notepad!*main*
    00151320 notepad!_imp____getmainargs = <no type information>
    00151405 notepad!WinMain = <no type information>
    00153689 notepad!WinMainCRTStartup = <no type information>
    0:000> x notepad!g_*
    0015c00c notepad!g_ftOpenedAs = <no type information>
    0015e040 notepad!g_ftSaveAs = <no type information>
    0015c100 notepad!g_wpOrig = <no type information>
     

    reference : Inside Windows Debugging (Tarik Soulami)
    • Marked as answer by Deepjot_Singh Wednesday, December 12, 2012 5:14 AM
    Wednesday, December 12, 2012 5:14 AM

All replies

  • Are you working with .NET application? If yes, then mapping functiona names to addresses is no longer required. You can use SOS extension with WinDbg.

    http://www.dotnetcurry.com/ShowArticle.aspx?ID=648

    http://stackoverflow.com/questions/13116549/stepping-through-source-code-using-windbg-sos-extension


    Please mark this post as answer if it solved your problem. Happy Programming!

    • Marked as answer by Deepjot_Singh Wednesday, December 12, 2012 6:33 AM
    Tuesday, December 11, 2012 8:55 AM
  • Thanks for the reply.   Yes the application is in .Net.    I actually need the addresses of specific functions whose names i would feed, with a purpose to corrupt them.   I suppose SOS doesn't give us the feature of fetching address.
    Tuesday, December 11, 2012 9:25 AM
  • When you need to find the address at which a known function or a global variable resides, you can
    use the x command of the windbg.exe debugger. This translation is often useful when trying to set
    code or data breakpoints. For this to work, naturally, the module (DLL or main EXE) that contains the
    function or global symbol should’ve already been loaded by the target process. Note that this command
    also supports the wildcard character (*), which is often convenient for discovering the available
    symbol (function or global variable) names that match a given pattern
    .
     
    0:000> x notepad!*main*
    00151320 notepad!_imp____getmainargs = <no type information>
    00151405 notepad!WinMain = <no type information>
    00153689 notepad!WinMainCRTStartup = <no type information>
    0:000> x notepad!g_*
    0015c00c notepad!g_ftOpenedAs = <no type information>
    0015e040 notepad!g_ftSaveAs = <no type information>
    0015c100 notepad!g_wpOrig = <no type information>
     

    reference : Inside Windows Debugging (Tarik Soulami)
    • Marked as answer by Deepjot_Singh Wednesday, December 12, 2012 5:14 AM
    Wednesday, December 12, 2012 5:14 AM