Package: archr
archrTraditionally, binary analysis has been implicitlyprogram-centric, meaning that the atomic unit of concern is the binary being analyzed.
This assumption is usually implicit:angr.Projectis instantiated with the binary in question,afllaunches the binary itself, generally hyper-modified to make it easier to fuzz, and so on.However, outside of the CGC, programs do not exist in a vacuum.
Specific library versions, values in configuration files, environment variables, and a myriad other factors combine with the program binary itself to make a unique holistictarget, and in many cases, it is that target that needs to be analyzed, not just the program itself.
This is specifically true for analysis that need extreme accuracy, such as automatic exploit generation.archris an implementation of such atarget-centricanalysis paradigm.
It consists of two main concepts:Targets, which describe the specification of the target itself, how it is configured, how it will be launched, and how it would be interacted with, andAnalyzers, which specialize targets for specific analysis actions, such as tracing, symbolic execution, and so on.
To accomplish their tasks, Analyzers might injectImplants(i.e., qemu-user, gdbserver, and so on) into the target.We have the following Targets:DockerImageTarget, which takes a description of the target in the form of a docker imageLocalTarget, which just describes running the target in the local systemThe following Analyzers exist:DataScoutAnalyzer (will grabs the memory map, environment, and auxv of the process, exactly as it is at launch)AngrProjectAnalyzer (can create an angr project with the right libs at the right offsets)AngrStateAnalyzer (can create a angr states with the right env, args, and fs)QEMUTraceAnalyzer (does qemu tracing of the target)GDBServerAnalyzer (launches the target in a gdbserver)STraceAnalyzer (straces a target)CoreAnalyzer (launches the target and retrieves a core)InputFDAnalyzer (determines the FD number for user input (in some cases))Using archrTo use archr, one must first create a Target.
First, build a docker image that launches your target.
Here is an example dockerfile for adocker-catimage:from ubuntu:latest
entrypoint ["/bin/cat"]Then, load it as a target:import archr
t = archr.targets.DockerImageTarget('docker-cat').build()Andviola!, your target is ready to use.
archr will automatically figure out how your binary runs inside your target, and then you can launch and interact with it:t.start()
assert t.run_command(stdin=subprocess.DEVNULL).wait() == 0
t.stop()archr makes heavy use ofwithcontexts, which will help clean up resources.
Embrace them.
For example, you can:with t.start():
	with t.run_context() as p:
		print(p,"is a subprocess.Popen object!")
		p.stdin.write("hello")
		assert p.stdout.read(5) == "hello"There is even a context that will allow you to temporarily replace files on the target!with t.start():
	with t.replacemenet_context("/etc/passwd", "hahaha"), t.run_context(args_suffix=["/etc/passwd"]) as p:
		assert p.stdout.read() == "hahaha"
	assert t.run_command(args_suffix=["/etc/passwd"]).stdout.read() != "hahaha"And even one that willtemporarily replace the target binary's code with shellcode:with t.start():
	with t.shellcode_context(asm_code="mov rax, 60; mov rdi, 42; syscall") as p:
		assert p.wait() == 42You can retrieve files from the target withretrieve_contents,retrieve_paths, andretrieve_glob, inject files withinject_path,inject_contents, and so on, get network endpoints usingipv4_address,udp_ports, andtcp_ports, and some other interesting stuff!
You can also make aLocalTargetto just run stuff on your host, and it is almost perfectly interchange with a DockerTarget:import archr
t = archr.targets.LocalTarget(["/bin/cat"]).build()To figure out how to run the binary,LocalTargettakes at least an argv list.
You can also pass in an env.Keep in mind that since some of the above examples need write access to files, you will need to use writable files instead of/etc/passwdand/bin/cat.CaveatsSome caveats at the moment:archr does not handle string-specified (as opposed to array-specified) entrypoint directives in the docker file.
This isn't hard; we just haven't gotten around to it (see issue #1).