Page 1 of 3 123 LastLast
Results 1 to 15 of 32

Thread: Conditional Branch Logger A New Plugin

  1. #1
    Super Moderator
    Join Date
    Dec 2004
    Posts
    1,511
    Blog Entries
    15

    Conditional Branch Logger A New Plugin

    Hello OllyDbg users,

    We, Kayaker, dELTA and Me take the pleasure of Announcing a new plugin:

    Conditional Branch Logger

    The salient features of the plugin are as follows:

    * An ability to detect all conditional branches and log their behaviour during
    runtime without having to single step the whole process, which results in a dramatic improvement of performance when compared to run trace logging.

    * An ability to choose specific conditional jumps only to monitor and log.

    * Log conditional branches spanning multiple modules .

    * an ability to filter out sytem modules from being logged

    * Ability to choose and opt included ranges and excluded ranges to fine
    tune the logging.

    * Ability to disable, delete and restore the logging status of the
    detected conditional branches.

    * An ability to list all the procs that ollydbg has recognised, with
    their names if they exist, as a handy referance so that it is easier to
    include or exclude ranges.

    * A text mode log file that could serve to compare two similar runs to detect divergent paths taken with respect to input


    * A runtime log window that displays the status of conditional branches live with context menus to edit, delete and disable the entries on the fly.

    * Context menus in memory window to mass add modules after auto
    analysing them or add specific modules.

    * Context menus in memory window to add non module ranges.

    * Context menu to add odd ranges in disassembly window.

    * And a few more, like background tasks e.g. saving the entire database of conditional branches to udd and restored back when restarting the project afresh.

    We hope this plugin could be of immense use when monitoring execution flow path.


    Any comments, bouquets and brickbats are welcome.


    Please direct your suggestions, criticisms, bug reports

    to ollydbg plugin sections.


    I personally would like to offer my thanks to dELTA and Kayaker for
    their initiative to bring this plugin to a successful release.
    I thank Woodmann for hosting this OllyDbg specific forum,
    and of course all of you OllyDbg users and well wishers.

    The plugin's genesis can be found in this thread:

    http://www.woodmann.com/forum/showthread.php?t=9807


    From the simple 40 line prototype with which i seeded this plugin, I'm
    really glad to see this Conditional Branch Logger evolve into a
    multi-language, multi-kilobyte, mature plugin for OllyDbg.

    I'm also very glad to have the pleasure of working along with Kayaker,
    and dELTA.

    dELTA is instrumental in providing the fast logging engine, the
    configuration save and restore code, and the GUI frontend (including
    modifying it umpteen times to match the requests ).


    Kayaker is the Chief Architect of the entire code that interfaces with the GUI and OllyDbg.


    I am proud to be the Catalyst, Consultant and Progenitor of the idea that started this all.

    You can find this plugin at OllyStuph

    http://www.woodmann.com/collaborative/tools/index.php/Conditional_Branch_Logger


    Thanks and Regards,

    blabberer

  2. #2
    does it make use of the MSR registers to do branch tracing and logging on newer processors? or it disassembles and sets breakpoints? or something else?

    thanks for the plugin, I foresee millions of uses for it!

  3. #3
    I answer myself: I just read the original thread, and apparently it does use the msr registers and stuff.

  4. #4
    Excellent plugin, blabberer, Delta and Kayaker !
    I am playing with your plugin, and I think I found 2 bug:
    - When I start OllyDbg from shortcut or Context menu in Explorer, the cbl_gui.dll could not load. I read your source code and found the bug in the function ODBG_Plugininit, at the line which calls GetCurrentDirectory. In my opinion, do not use this function, replace it with GetModuleFileName(NULL,...) to get OllyDbg.exe, .ini, plugin path.
    - OllyDbg shows the warning message box "Suspicious breakpoint...." many times when the Conditional Branch Logger show the wait box "Please wait while conditional branch logger is processing...", and I must press Enter key many times. So I have to kill OllyDbg with Process Explorer.
    Hope you will fix those bugs.
    Best regards, and thanks very much for your greate plugin, great source code !
    TQN

  5. #5
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,124
    Blog Entries
    5
    Hi

    Thank you for the feedback.

    No, the plugin doesn't use MSR registers it's based only on what Olly disassembles as conditional branch instructions, the JCC series, JCXZ/JECXZ and LOOP instructions if selected. That might be something to look into though if the idea could be incorporated with regular OllyDbg functioning.

    Re the "Suspicious breakpoint" message, that's a message from Olly itself. I think there are two situations where that might occur. One is if you add a logging (included) range of a non-standard section or memory mapping, such as the PE header, data section, non-executable heap location, etc. Certain bytes could be interpreted as conditional jump instructions by Olly and when it tries to set a breakpoint there you get the warning.

    The other situation where that might occur is if the module hasn't been analyzed yet by the Olly code analysis function. In the majority of cases the plugin will first test if the module has been analyzed by checking the t_module->codedec flag, if not it will analyze the module first using Olly's Analysecode function (or you can do it from a separate menu item) before adding anything as a logging range.

    In most cases you *shouldn't* get the "Suspicious breakpoint" message if the addresses are valid code in the first place. It's actually a warning that one needs to be judicious in selecting ranges to log with the plugin (the plugin will warn you if you try to add non-standard regions from the Ollydbg Memory map window at least). I've been caught several times as well and had to close possibly hundreds of message boxes. I wish there was a way to tell Olly to either ignore the problem or just stop processing. Since chances are that the breakpoint will never be hit, it wouldn't do any harm to have a false breakpoint set and it's more of annoyance (at least to our plugin ) than anything else.


    As for the issue of cbl_gui.dll not loading, I wasn't able to reproduce that error even when opening Olly from a shortcut, context menu or run command. My assumption is that GetCurrentDirectory should retrieve the location of the currently running Olly exe process, the plugin then parses ollydbg.ini (in the same directory) to get the plugin path and tries to load the dll from there. If that fails it will try to load it from the main Olly directory or %PATH% locations. I'm certainly willing to change the code if there's a problem.

    Thanks again, all reports are welcome.

    Regards,
    Kayaker

  6. #6
    Thanks for your reply, Kayaker !
    At this time, I have to copy cbl_gui.dll to System32 directory. And if we have a new version, I should remember that I have to copy new cbl_gui.dll to System32 directory, overwrite the old dll. It is inconvenient.
    And with a lot of modified OllyDbg version, your plugin will not work because the ollydbg.ini will not found. So I think we can change the code as below:
    Code:
    ....
    char szPluginPath[_MAX_PATH] = { 0 };
    char szPluginDrive[_MAX_DRIVE] = { 0 };
    char szPluginDir[_MAX_DIR] = { 0 };
    ....
    GetModuleFileName(hinst, szPluginPath, MAX_PATH);
    splitpaht(szPluginPath, szPluginDrive, szPluginDir, NULL, NULL);
    makepath(szPluginPath, szPluginDrive, szPluginDir, "cbl_gui", ".dll");
    if (0 != _access(szPluginPath, 0))
    {
        // Error: file cbl_gui.dll not existed
        ....
    }
    else
    {
        guidll = LoadLibrary(szOllyPluginPath);
    }
    ....
    With this code, we can place the cbl_gui.dll to OllyDbg's Plugin directory, and we can alway load the dll.
    If I have any mistake, forgive me.
    Best regards,
    TQN
    Last edited by TQN; June 13th, 2007 at 21:46.

  7. #7
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,124
    Blog Entries
    5
    Quote Originally Posted by TQN View Post
    And with a lot of modified OllyDbg version, your plugin will not work because the ollydbg.ini will not found.
    Thanks TQN, I can look into the changes you suggest. I've not used any modified Olly versions so don't know what effects that may have.

    One question though, will the cbl_gui.dll not load if you place it in the Olly main directory? This is the default location, should it not be found in the plugin directory. That should be just as reliable as placing it in the windows or windows/system32 directory (%PATH%)

    Like most dll's, the command
    LoadLibrary("cbl_gui.dll");
    should first search the current process directory and then %PATH% for the dll in question. So I'd be very surprised if the dll didn't load from the main Olly directory at least. I certainly don't *want* the dll having to be placed in the windows directory, nothing I hate more than scattered program files.

    Cheers,
    Kayaker

  8. #8
    Thanks Kayaker !
    I moved the cbl_gui.dll to OllyDbg directory, and it works. But, because many plugins requires and places its additional dll to OllyDbg directory, for example: RL!Weasle with dumper.dll, importer.dll, realign.dll, OllyBone with ollybone.sys..., so we will have many files in OllyDbg directory. And after, if we have a new version of some plugin, we have to extract some files to OllyDbg plugin dir, some files to OllyDbg main directory, and if we need copy some plugin to another machine, we have to remember and copy some dll from OllyDbg main directory. So, why we can not place all of dll in the OllyDbg directory ?
    Thanks you a lot for waste your time to answer my post !
    Best regards,
    TQN

  9. #9
    Cool,

    Take a look at the thread over here:
    http://www.openrce.org/blog/view/535/Branch_Tracing_with_Intel_MSR_Registers

    If you turn on the BTF flag your tool would run much faster, BUT not sure how it would work in Olly since it expects the default step behavior.

  10. #10
    Super Moderator
    Join Date
    Dec 2004
    Posts
    1,511
    Blog Entries
    15
    hi all,

    thanks for the great feedback

    putting the cbl_gui to ollydbg directory should get the cbl_gui in search path

    yeah i too hate to have the the files scattered at umpteen places
    i wish ollydbg had a Plugingetvalue(val_pluginpath) which i could have gladly used other than that only reliable option seemed to be asking the user for a path to cbl_gui and taking it from the user which is equally annoying

    and as to version changes even if i had a hardcoded path from user i probably would need a version check as well to confirm if the gui dll is the same with which plugin is interfacing

    thanks TQN for suggestions and code hopefully it should be eliminated

    as to supicious breakpoint i at one time clocked a million breakpoints
    but the app wasnt any antidebugged one plain ms winword.exe
    i didnt get any suspicious breakpoint message

    it only happens if the addrerss space isnt analysed or it is non executable memory

    could you get more details about the app in question
    if it is non commercial toy then a link would be appreciated too

    ill see if i can bypass the suspicious thingies
    Attached Images Attached Images  

  11. #11
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    Quote Originally Posted by blabberer View Post
    I am proud to be the Catalyst, Consultant and Progenitor of the idea that started this all.
    Hehe, don't be so modest, you did a lot more than that.

    And me for one couldn't resist the idea of working together with the inofficial #1 OllyDbg guru on a plugin project.

    Nice to see the feedback from people too. The MSR register thingy definitely sounds like an interesting possibility, even though a bunch of obstacles regarding the Olly integration with this might have to be solved first.

    Please keep the feedback coming, and stay tuned for a very exciting already planned feature upgrade in the future too...
    "Give a man a quote from the FAQ, and he'll ignore it. Print the FAQ, shove it up his ass, kick him in the balls, DDoS his ass and kick/ban him, and the point usually gets through eventually."

  12. #12
    Registered User
    Join Date
    Aug 2005
    Location
    Greece
    Posts
    157
    This is very good plugin, can you please post the delphi source for the gui part too?
    A picture worth 1K words (or .5K DWORDS).

  13. #13
    Quote Originally Posted by dELTA View Post
    The MSR register thingy definitely sounds like an interesting possibility, even though a bunch of obstacles regarding the Olly integration with this might have to be solved first.
    Which ones? What problem have you had using them?
    I want to know God's thoughts ...the rest are details.
    (A. Einstein)
    --------
    ..."a shellcode is a command you do at the linux shell"...

  14. #14
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    Quote Originally Posted by blurcode View Post
    This is very good plugin, can you please post the delphi source for the gui part too?
    Sorry, it contains commercial components and code, so that cannot be done at the moment.

    Quote Originally Posted by Maximus
    Which ones? What problem have you had using them?
    I was mostly thinking about the problems that could occur if Olly does not support this register functionality directly (which I'm not sure of), and that we in that case might have to implement (parts of) the debugger code/loop ourselves for such a thing, which would make the thing much more detached from OllyDbg. Just a theory though, and at the moment I don't know enough about several things to say it really is so. Please let us know about any additional thought you may have about this.
    "Give a man a quote from the FAQ, and he'll ignore it. Print the FAQ, shove it up his ass, kick him in the balls, DDoS his ass and kick/ban him, and the point usually gets through eventually."

  15. #15
    mmh.. not sure I understand how the plugin works, however a very simple driver with a service call that sets the MSR (wait I get the number from manual) 1d9h, msr_debuctl_a.
    set ther BTF==1 and you will single-step on branches only. on every debug event (i suppose a in olly plugin has a function that can be called whenever a debug exception happens?), call the driver service so it gets set==1 again.

    Or are you meaning the branch trace cache the P4 has?
    I want to know God's thoughts ...the rest are details.
    (A. Einstein)
    --------
    ..."a shellcode is a command you do at the linux shell"...

Similar Threads

  1. Conditional BP
    By REAP in forum OllyDbg Support Forums
    Replies: 2
    Last Post: November 8th, 2013, 23:40
  2. Conditional Branch Logger
    By REAP in forum Tools of Our Trade (TOT) Messageboard
    Replies: 11
    Last Post: July 5th, 2013, 01:56
  3. Conditional Break?
    By RITZ in forum OllyDbg Support Forums
    Replies: 5
    Last Post: June 30th, 2006, 11:17
  4. Conditional breakpoints?
    By Anonymous in forum OllyDbg Support Forums
    Replies: 2
    Last Post: August 13th, 2003, 13:21
  5. Conditional Breakpoint
    By Anonymous in forum OllyDbg Support Forums
    Replies: 5
    Last Post: January 27th, 2003, 11:06

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •