[Tooling] IDT tracking

[cecille]

Reproduction steps / Feature

From the IDT review (tracking bug - comments from austin)

Hi Cecille and James,

Sincerest thanks for your thorough and timely reviews here, it is genuinely appreciated!!!

Although I've marked some of these comments resolved without action, I am likely going to refer back to many; the effort is not wasted.

I've done my best to summarize and prioritize unresolved suggestions below so we can move on but refer back to this as needed:

Low LOE

• P0 Include a diagram in README
• P0 Make activate build container image if needed
• P0 Pull full bugreport in android
• P1 Consider updating default pcap interface to any, update notes on wifi vs eth DONE
• P1 Script to generate vars.sh DONE
• P1 Document exception that could be raised in shell_utils
• P1 Add pull_artifacts() to platform base class

Med LOE

• P0 Make extending ecosystem and platform possible without editing the source of the tool DONE
• P0 Pull btsnoop logs, push tcpdump to android phones and execute there
• P0 Add bt into capture
• P0 Split Android screen recording to its own class. Handle recording max size and duration issues. Add --bugreport.
• P1 Main entry point: Better error handling, concurrency, (eventually everything should be async aware) run for multiple platforms within a single shell
• P1 Stop using Kali OS image for the Pi, ensure we can still do monitor mode DONE
• P1 Switch from print() to logging framework + colorize output
• P2 Consider depending on adb from aosp.
• P3 For raspi: config a user for no sudo, setup ssh keys, setup rsync Made README more generic

High LOE

• P0 Standardize artifact output format
• P1 Standardize pcap interface. Possibly standardize root of type hierarchy for all captures.
• P2 Regarding ecosystem base class: Stop might return a useable handle like "CaptureDescriptor" and then have a separate interface that processes CaptureDescriptor(s).
• P3 Use urwid.

Other comments that I just pulled from the PR

• I don't want to block you on this, but without re-reviewing all of the code, I'm having a hard time remembering my mental class diagram. Just the feeling of the tool give me the feeling there should be a a set of Monitors with a few lifecycle methods like setup, start monitor, stop monitor, cleanup, and depending on how you want to structure it, a pull artifacts, or flush records, or potentially you setup the monitor feed to be streamed to a destination during the setup. I'm not sure where Discover fits in there. Just thinking about the Monitor(s), I would have a directory called /monitor/ and have a sub-directory for each implementation. Are you trying to "discover" think that could be Monitor'ed? Or are you just trying to start observing monitoring the network?

• Can you make the Discovery modules adhere to a common interface?

Platform

other

Platform Version(s)

IDT

Type

Manually tested with SDK

(Optional) If manually tested please explain why this is only manually tested

No response

Anything else?

No response