Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent Execution of instrument_bb_coverage Function A #447

Open
bluestar628 opened this issue Aug 18, 2024 · 6 comments
Open

Inconsistent Execution of instrument_bb_coverage Function A #447

bluestar628 opened this issue Aug 18, 2024 · 6 comments

Comments

@bluestar628
Copy link

t appears that the instrument_bb_coverage function is not triggered every time a basic block is executed. I added the following code at the beginning of instrument_bb_coverage:

dr_fprintf(log_file, "bb called %d\n", bb_count);
bb_count++;
if (bb_count == 100000) bb_count = 0;

Upon reviewing the log_file, I noticed that the output increases rapidly when fuzzing begins. However, over time, it slows down and eventually stops at different points for different applications. Could you please help me understand why this might be happening?

Thank you for your assistance!

@ifratric
Copy link
Collaborator

That sounds correct. instrument_bb_coverage is not meant to run each time a basic block is executed, but rather each time a basic block is translated. In DR, my understanding is that this generally occurs the first time a basic block is executed. instrument_bb_coverage then writes assembly instructions to the basic block (using instrlist_meta_preinsert) and those assembly instructions are executed each time a basic block executes.

@bluestar628
Copy link
Author

That sounds correct. instrument_bb_coverage is not meant to run each time a basic block is executed, but rather each time a basic block is translated. In DR, my understanding is that this generally occurs the first time a basic block is executed. instrument_bb_coverage then writes assembly instructions to the basic block (using instrlist_meta_preinsert) and those assembly instructions are executed each time a basic block executes.

Thanks for your help! However, I also noticed some repeated addresses in the log file, though they don't appear too often. How should I understand this?

@ifratric
Copy link
Collaborator

Can you explain what you mean by "repeated addresses"? Addresses of basic blocks or something else and how/where are they logged?

@bluestar628
Copy link
Author

I added the following code at the beginning of instrument_bb_coverage, intending for the offset of each executed basic block to be logged in log_file (a file_t object initialized in dr_main).

dr_fprintf(log_file, "bb called %d\n", bb_count); bb_count++; if (bb_count == 100000) bb_count = 0;

However, over time, the log_file stops increasing. You explained that instrument_bb_coverage is only called the first time a block is translated, yet I observe some addresses appearing more than once. Why are these blocks translated multiple times? Thank you!

@ifratric
Copy link
Collaborator

If the target process restarts for any reason, code is going to need to be reinstrumented (during a fuzzing session this occurs if maximum number of persistent iterations has been reached, on crashes, hangs etc.) so translation will occur again. It's also possible that DynamoRIO sometimes translates basic blocks multiple times for whatever reason (e.g. if it suspects a basic block has changed, as a part of some optimization?), but I'm not that familiar with DR internals. Such questions I can better answer for TinyInst, which I developed myself (TinyInst will not translate a basic block twice unless the target process restarts)

@bluestar628
Copy link
Author

Amazing! You're the author of TinyInst! Thank you so much for your help!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants