Closed dhbbb closed 2 years ago
您的邮件我已经收到了,我会尽快处理然后给你回复。谢谢!
@dhbbb I had the same problem as you, I guess it's because the bug is in libgpac.so. As the author mentioned in the article, they do not trace any code outside of the main executable, i.e., shared libraries.
@dhbbb I had the same problem as you, I guess it's because the bug is in libgpac.so. As the author mentioned in the article, they do not trace any code outside of the main executable, i.e., shared libraries.
Hi, thanks for your reply! I found that my problem was that the seeds I provided were not rich enough, resulting in all predicates scoring below 0.9. I tried to enrich my seed bank, but I encountered new problems:https://github.com/RUB-SysSec/aurora/issues/8 Have you ever encountered this situation?
@dhbbb I had the same problem as you, I guess it's because the bug is in libgpac.so. As the author mentioned in the article, they do not trace any code outside of the main executable, i.e., shared libraries.
Hi, thanks for your reply! I found that my problem was that the seeds I provided were not rich enough, resulting in all predicates scoring below 0.9. I tried to enrich my seed bank, but I encountered new problems:#8 Have you ever encountered this situation?
I haven't encountered this problem yet.
In my case, I checked the instruction in the trace, and indeed there is no instruction where the vulnerability exists (because it is in libgpac).
@dhbbb I had the same problem as you, I guess it's because the bug is in libgpac.so. As the author mentioned in the article, they do not trace any code outside of the main executable, i.e., shared libraries.
Hi, thanks for your reply! I found that my problem was that the seeds I provided were not rich enough, resulting in all predicates scoring below 0.9. I tried to enrich my seed bank, but I encountered new problems:#8 Have you ever encountered this situation?
I haven't encountered this problem yet.
In my case, I checked the instruction in the trace, and indeed there is no instruction where the vulnerability exists (because it is in libgpac).
@dhbbb I had the same problem as you, I guess it's because the bug is in libgpac.so. As the author mentioned in the article, they do not trace any code outside of the main executable, i.e., shared libraries.
Hi, thanks for your reply! I found that my problem was that the seeds I provided were not rich enough, resulting in all predicates scoring below 0.9. I tried to enrich my seed bank, but I encountered new problems:#8 Have you ever encountered this situation?
I haven't encountered this problem yet.
In my case, I checked the instruction in the trace, and indeed there is no instruction where the vulnerability exists (because it is in libgpac).
Thanks! This helps me a lot. Is your trace file built with asan?
@dhbbb I had the same problem as you, I guess it's because the bug is in libgpac.so. As the author mentioned in the article, they do not trace any code outside of the main executable, i.e., shared libraries.
Hi, thanks for your reply! I found that my problem was that the seeds I provided were not rich enough, resulting in all predicates scoring below 0.9. I tried to enrich my seed bank, but I encountered new problems:#8 Have you ever encountered this situation?
I haven't encountered this problem yet. In my case, I checked the instruction in the trace, and indeed there is no instruction where the vulnerability exists (because it is in libgpac).
Thanks! This helps me a lot. Is your trace file built with asan?
I built with ASAN in the fuzzing stage but not in the tracing stage. As the article mentioned, the tracing binary should be a non-ASAN binary to avoid sanitizer artifacts disturbing the analysis.
Also, I found that tracing.py seems not to handle parameters and submitted PR #6. I think that might help.
@dhbbb I had the same problem as you, I guess it's because the bug is in libgpac.so. As the author mentioned in the article, they do not trace any code outside of the main executable, i.e., shared libraries.
Hi, thanks for your reply! I found that my problem was that the seeds I provided were not rich enough, resulting in all predicates scoring below 0.9. I tried to enrich my seed bank, but I encountered new problems:#8 Have you ever encountered this situation?
I haven't encountered this problem yet. In my case, I checked the instruction in the trace, and indeed there is no instruction where the vulnerability exists (because it is in libgpac).
Thanks! This helps me a lot. Is your trace file built with asan?
I built with ASAN in the fuzzing stage but not in the tracing stage. As the article mentioned, the tracing binary should be a non-ASAN binary to avoid sanitizer artifacts disturbing the analysis.
Also, I found that tracing.py seems not to handle parameters and submitted PR #6. I think that might help.
Oh,i see that. When I run the command I pass parameters like this: python3 tracing.py "$EVAL_DIR/MP4Box_trace -hint @@ -out /dev/null" $EVAL_DIR/inputs $EVAL_DIR/traces Does this pass parameters successfully?
@dhbbb I had the same problem as you, I guess it's because the bug is in libgpac.so. As the author mentioned in the article, they do not trace any code outside of the main executable, i.e., shared libraries.
Hi, thanks for your reply! I found that my problem was that the seeds I provided were not rich enough, resulting in all predicates scoring below 0.9. I tried to enrich my seed bank, but I encountered new problems:#8 Have you ever encountered this situation?
I haven't encountered this problem yet. In my case, I checked the instruction in the trace, and indeed there is no instruction where the vulnerability exists (because it is in libgpac).
Thanks! This helps me a lot. Is your trace file built with asan?
I built with ASAN in the fuzzing stage but not in the tracing stage. As the article mentioned, the tracing binary should be a non-ASAN binary to avoid sanitizer artifacts disturbing the analysis. Also, I found that tracing.py seems not to handle parameters and submitted PR #6. I think that might help.
Oh,i see that. When I run the command I pass parameters like this: python3 tracing.py "$EVAL_DIR/MP4Box_trace -hint @@ -out /dev/null" $EVAL_DIR/inputs $EVAL_DIR/traces Does this pass parameters successfully?
I have not tried this, you can print the trace command to see if it is correct.
@dhbbb I had the same problem as you, I guess it's because the bug is in libgpac.so. As the author mentioned in the article, they do not trace any code outside of the main executable, i.e., shared libraries.
Hi, thanks for your reply! I found that my problem was that the seeds I provided were not rich enough, resulting in all predicates scoring below 0.9. I tried to enrich my seed bank, but I encountered new problems:#8 Have you ever encountered this situation?
I haven't encountered this problem yet. In my case, I checked the instruction in the trace, and indeed there is no instruction where the vulnerability exists (because it is in libgpac).
Thanks! This helps me a lot. Is your trace file built with asan?
I built with ASAN in the fuzzing stage but not in the tracing stage. As the article mentioned, the tracing binary should be a non-ASAN binary to avoid sanitizer artifacts disturbing the analysis. Also, I found that tracing.py seems not to handle parameters and submitted PR #6. I think that might help.
Oh,i see that. When I run the command I pass parameters like this: python3 tracing.py "$EVAL_DIR/MP4Box_trace -hint @@ -out /dev/null" $EVAL_DIR/inputs $EVAL_DIR/traces Does this pass parameters successfully?
I have not tried this, you can print the trace command to see if it is correct.
Thanks man! Besides gpac and mruby, have you successfully analyzed other files with aurora?
@dhbbb I didn't test much. But the analysis on libzip and nasm was successful.
@dandanxu96 Thank you very much for your reply! Could you tell me your email address?
forwork1004@gmail.com
Hi, looks like you've sorted most of this one out? Let me quickly comment on a couple of issues brought up during the discussion:
@ min_score: I've improved debug output on the develop branch (Aurora should now print how many predicates with a score higher than 0.9 were found). You can additionally try to play around with the MIN_SCORE
(https://github.com/RUB-SysSec/aurora/blob/develop/root_cause_analysis/root_cause_analysis/src/traces.rs#L7) and set it to a lower value. This may decrease the validity of predicates, though.
@ tracing libraries: In theory, you can turn on tracing for libraries by removing the && IMG_IsMainExecutable(image)
check at https://github.com/RUB-SysSec/aurora/blob/69183fd68a194dc68499de20ce46d2dd4c245016/tracing/aurora_tracer.cpp#L284
I don't think we have ever tried this and it may break at other places. This will also likely cause a huge increase in trace sizes.
@ parameter passing: python3 tracing.py "$EVAL_DIR/MP4Box_trace -hint @@ -out /dev/null" $EVAL_DIR/inputs $EVAL_DIR/traces
looks good and should pass the parameters as expected. I do agree that this is not really a good way to handle parameters, but it should work for most research purposes.
Hello aurora team! I seem to have some issues when I try to run some projects with aurora other than mruby. The tracing output was like this:
It doesn't look like it's running correctly because the ranked_predicates_verbose file I get is empty in the next RCA step. Is it because I didn't set the parameters for MP4Box to run correctly? When I run with afl its parameter is ./MP4Box -hint poc -out /dev/null. If so, at which step should I set the parameters?