dtrace scripting about cuckoo-osx-analyzer

[rodionovd]

@jbremer I have a question about possible APIs for dtrace invocations from Python. There're two ways:

The first looks like this:

syscalls_made = dtrace_syscalls_analysis(target)
files_open    = dtrace_fileIO_analysis(target)
# and so on

i.e. we'll launch the target as many times as we have things to analyse.

The second approach is:

results = dtrace_analysis(target)

syscalls_made = results.syscalls()
fileIO        = results.fileIO()
# and so on

so we'll run analysis (as well as the target) only once and it'll be gathering all the data at once.

---

I've been working on the first way for the last couple days, but finally realised that some targets could act differently when running second/third/etc time, so it's not correct to run analysis this way. But I may be wrong here — let me know.

The second way is trickier to implement because I'll need one giant dtrace script that'd do all kind of analysis. Don't like this approach, but it seems the only correct one.

Looking forward for your feedback!

[jbremer]

What we do currently in Cuckoo is that each analysis task starts a Virtual Machine just for that one task. So if I understand your question correctly, then the answer would be to go for the first option.
I somewhat assume this is easier to implement for you as well, so I'd suggest to go that route. If we have time left on the end of the summer we can always experiment some more ;-)

[rodionovd]

Great! Thank you, I'm going the first way then :)

[phretor]

@rodionovd have you considered fslogger?

[rodionovd]

@phretor I'm not sure about integrating 3rd-party tracing scripts/tool, but thanks for mention it — I'll take a look!

[phretor]

@rodionovd @jbremer I've integrated some of my code and crafted out a sort of analyzer.py in my fork. However, this is my first time creating a custom analyzer for Cuckoo and I'm not really sure what's the common practice:

1. do everything, including the parsing of the behavior trace, on the analyzer (i.e., guest)
   • pros: self contained analyzer, no need to modify Cuckoo
   • cons: not very elegant, more time consumed on the guest
2. dump a "raw" text representation of the trace on the guest and parse it on the host
   • pros: small analyzer, focus on collecting data and that's it
   • cons: we have to modify Cuckoo

[jbremer]

Sending "raw" data to the host does not necessarily mean you have to modify Cuckoo, merely add modules to handle that data ;) So based on that I guess option two is the way to go, @phretor.

[phretor]

@jbremer, you mean <cuckoo root>/modules/processing/, right?

[jbremer]

Yes!