Questiones about aurora

[dhbbb]

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:

python3 tracing.py /home/inspur/Desktop/aurora-master/aurora-master/evaluation/gpac-1.0.1/bin/gcc/MP4Box $EVAL_DIR/inputs $EVAL_DIR/traces
INFO: Using files at /home/inspur/Desktop/aurora-master/aurora-master/evaluation/inputs
INFO: Generating temporary directory at /tmp/tm/
INFO: Processing 1732 files in 2 subdirs at /home/inspur/Desktop/aurora-master/aurora-master/evaluation/inputs
INFO: Done processing 1732 files in 77.40813875198364s (on average 2.860346928479765s per input)
INFO: STATS: traced 1732/1732 files in 77.40813875198364s with 64 cores for /home/inspur/Desktop/aurora-master/aurora-master/evaluation/inputs
INFO: killall MP4Box
MP4Box: no process found
INFO: Moving files from /tmp/tm/ to /home/inspur/Desktop/aurora-master/aurora-master/evaluation/traces
INFO: Deleting temporary directory /tmp/tm/
INFO: Cleanup time: 0.002581357955932617s
INFO: Total execution time: 77.4329948425293s
INFO: Finished tracing run
inspur@NF5270M5:~/Desktop/aurora-master/aurora-master/tracing/scripts$ python3 addr_ranges.py --eval_dir $EVAL_DIR $EVAL_DIR/traces
{"heap_start": 93824992624640, "heap_end": 93824993013760, "stack_start": 140737488211968, "stack_end": 140737488351232}

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?

[tiedaoxiaotubie]

您的邮件我已经收到了，我会尽快处理然后给你回复。谢谢！

[0xdd96]

@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]

@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?

[0xdd96]

@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).

[0xdd96]

@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]

@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?

[0xdd96]

@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]

@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?

[0xdd96]

@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.

aurora/tracing/scripts/tracing.py

Lines 116 to 117 in 69183fd

	cmd = f"{ASAN_OPTIONS} {PIN_EXE} -t {PIN_TOOL} -o {outfile} -logfile {pin_logfile} -- {target_exe}"
	logger.debug(f"CMD: {cmd}")

[dhbbb]

@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.

aurora/tracing/scripts/tracing.py

Lines 116 to 117 in 69183fd

	cmd = f"{ASAN_OPTIONS} {PIN_EXE} -t {PIN_TOOL} -o {outfile} -logfile {pin_logfile} -- {target_exe}"
	logger.debug(f"CMD: {cmd}")

Thanks man!
Besides gpac and mruby, have you successfully analyzed other files with aurora?

[0xdd96]

@dhbbb I didn't test much. But the analysis on libzip and nasm was successful.

[dhbbb]

@dandanxu96 Thank you very much for your reply! Could you tell me your email address?

[0xdd96]

forwork1004@gmail.com

[mu00d8]

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

aurora/tracing/aurora_tracer.cpp

Line 284 in 69183fd

if (IMG_Valid(image) && IMG_IsMainExecutable(image)) {

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.