[SOLVED] Cs6747 lab #5 – dynamic control flow tracing

Congratulations (again)! Your reverse engineering internship at Commonwealth National Laboratory has been a resounding success!
You happily arrive to work at 7:00 am on the last day of your internship, as you have done all summer. This morning, however, you find that the Vice President of Technological Disruption is already waiting at your cubicle.
“I saw that GHID’ER plugin you wrote” he says. “The whole team is amazed! It comments every instruction showin’ the data dependence. Even, countin’ those function arguments like they like!” He is clearly very pleased.
“Just doing my job, sir!” you say, but he is searching for something in his expensive leather briefcase…
“Oh boy! Sure I will!” You exclaim.
“Excellent” says the VPTD. “Now, I have to ask you to begin your next mission immediately. This one is of grave importance to the nation.” “Finally Stuxnet!” You think.
“The team is having trouble getting from point A to point B, and by that I mean, they don’t know which instructions come after the others” he explains.
“Click on Graph View!” you say, thinking that this all sounds very familiar, but it is clear that he has never even opened GHIDRA before.
“We need a way to know which order the instructions go in, but not all the instructions, only the ones that get executed when you run the program. You know?”
“Sure… a dynamic control flow graph.” You respond
“That’s the kind of out-of-the-box thinking that we like around here! Welcome to the team!” he says.
“This will be a long career” you think as you begin looking up the Pin docs.
https://software.intel.com/content/www/us/en/develop/articles/pin-a-dynamic-binaryinstrumentation-tool.html
Instructions:
In addition to the silly story, this lab will introduce you to carefully manipulating a malware’s execution under instrumentation. You will “puppeteer” GreenCat by pretending to be the C&C server and sending it the C&C commands you recovered in the previous labs. This sort of malware puppeteering is extremely common when trying to instrument and explore as much of a malware’s code as possible. A dynamic Control Flow Graph (CFG) is one essential program analysis building block that is often the desired output of this. A dynamic CFG allows you to answer all the malware analysis questions of a static CFG, but with more precision (because it follows a precise execution) and revealing any packed/encrypted code. After completing this lab, I encourage you to go a step further and write a simple analysis script to automatically compare your dynamic CFG with the static CFG from Lab #3 (they should be quite different!) — you’ve probably seen this trick used in the research papers to measure code coverage of the malware being tested.
Download and set up the Sandbox VM.
Download link: https://www.dropbox.com/scl/fi/enzu9xsa51sbz220q182d/vm.ova?rlk ey=d6ji9ofkbarg45irgi4xwcts8&st=lowqumkj&dl=0

Build the example MyPinTool that counts instructions as described in the PinTools slides.
PIN can be found in the C: directory of the VM.
Run the example MyPinTool on greencat in the Sandbox and send greencat the “list /p” command as described in the PinTools slides. Make sure the path to your built plugin is correct when running. You can download c2server.py here: https://www.dropbox.com/scl/fi/jsv5efiv0usydful6eenm/c2 server.py?rlkey=uj3c0bqs2l4f56za4o2pcnay7&st=7jcyzd9a&dl=0
If the installation worked correctly, then you should extend MyPinTool to do the following:
Trace the control flow of the executed instructions. To do so, your pintool will need to instrument the execution of every instruction. When each instruction is executed, your pintool will need to save what instruction preceded it. Do this tracing entirely in memory! Your pintool should only write to an output file in the Fini function (or ThreadFini). Constantly writing every instruction to the trace file will make your pintool unbearably slow!
After the process that your pintool is tracing exits (i.e., in your pintool’s Fini function), generate a DOT directed graph file representing the control flow of all the observed instructions. More information about DOT directed graph files can be found here: https://en.wikipedia.org/wiki/ DOT_(graph_description_language)#Directed_graphs. Each node in your DOT directed graph file should be the address of an instruction that was executed (only ONE node per instruction address). The edges in your DOT directed graph file should go from each executed instruction to the instructions which executed immediately after it.
For example, assume your pintool observes the following sequence of executed instruction addresses: 0x634, 0x636, 0x634, 0x640. The DOT directed graph file generated by your tool should be as follows:
digraph controlflow { “0x634” -> “0x636”;
“0x634” -> “0x640”;
“0x636” -> “0x634”;
}
The order of the edges in the DOT directed graph file do not matter. Also see: https://stackoverf
low.com/questions/1494492/graphviz-how-to-go-from-dot-to-a-graph
To optimize the accuracy of your results, limit the instructions that your pintool instruments to only those that:
• Execute after WinMain is called (i.e., do not instrument any instructions that execute before WinMain since these are mostly runtime set up code).
• Are inside of the greencat binary itself, and not dynamically linked libraries. The Pin “IMG” functions will be very helpful here.
You can use sendsignal.exe on the Desktop (via the command prompt) to kill it.
Use your pintool and explore all the different greencat capabilities that each of the greencat command and control (C&C) commands exercise. Refer back to your previous labs to recover the C&C commands that greencat accepts from its C&C server. Send each command to greencat (one time is enough, order does not matter) and generate one DOT file. Your goal is to run several C2 commands in the session so as to dynamically discover as many control flow paths as possible. Note that success paths and error paths are equally important!
Submit your pintool source code and the DOT file your pintool generated to Gradescope. For this lab, Gradescope will provide feedback every time you submit. The Gradescope feedback will tell you which greencat capabilities were explored and which ones you missed. The feedback will also show control flow paths that you missed. You should understand greencat well enough by now to find the C&C commands that cause those paths to execute.
Grade: 100 points
Grading Criteria:
The grade will be based on the correctness of the DOT file that your pintool generates.
-10 points for every missed C&C command’s control flow path.
-3 points for every missing or duplicated node in the DOT directed graphs. The DOT directed graph should contain one node for each instruction that gets executed when the program is run.
-3 points for every missing or erroneous edge in the DOT directed graphs. For every pair of instructions, A and B, if the control flow along any path of the observed execution causes B to execute immediately after A, then the DOT directed graph should contain only one edge from A to B.
Teams:
This assignment can be done individually or in a team of 2. Please join a group in Gradescope if you are collaborating.
Do not create or join a group in Canvas. Canvas groups are different from Gradescope groups.
New to Gradescope? This link provides instructions for how to create groups in Gradescope: https://help.gradescope.com/article/m5qz2xsnjy-student-add-group-members
Zoom can also provide the ability to collaborate and video conference with your teammate.
Submission Instructions:
Upload the following to Gradescope:
The DOT file that your pintool generated, named “submission.dot”.
Your pintool code, named “plugin.cpp”. We reserve the right to run all submitted code, through automated means or otherwise, and if it is found that your code does not output equivalent to your original dotfile submission then you will also receive a zero.
Be advised, please submit (1) and (2) separately, do NOT zip them together.
Note: You can download the webc2-greencat-2.7z file directly into your lab environment. After you are done with this lab, you can submit your files directly from the lab environment (Highly recommended). Doing this will help you avoid transferring the file from the lab environment to your personal computer.
Transferring Files:
To transfer files from your personal device to the lab environment or to the Windows7 VM:
Create a zip folder of all the files that you would like to transfer to the lab environment or the Windows7 VM.
Every GT student has Box and OneDrive accounts given free by the institution. Login to either of those two and upload the desired files.
Now go back to the lab environment or the Windows7 VM and login to either of those two services where you uploaded you zip folder. Download folder to the lab environment or the Windows7 VM and use the appropriate 7z command to unzip your folder.
What to do when you encounter technical difficulties?
If you are experiencing technical difficulty such as being unable to access the lab environment, please submit a ticket to the “Digital Learning Tools and Platforms” team at https://gatech.servicenow.com/continuity. And on the ticket, please put “Route to the DLT Team” at the top of the ticket because it will help the Service Desk know where to send it.