Show page

Differences

This shows you the differences between two versions of the page.

--- ep:labs:04:contents:tasks:ex4 [2023/10/29 20:45]
radu.mantu
+++ ep:labs:04:contents:tasks:ex4 [2025/02/11 23:36] (current)
cezar.craciunoiu
@@ Line 1: / Line 1: @@
-==== 04. [10p] Protocol Options ====
+==== 04. [40p] Intel PIN ====
+Broadly speaking, binary analysis is of two types:
+  * **Static analysis** - used in an offline environment to understand how a program works without actually running it.
+  * **Dynamic analysis** - applied to a running process in order to highlight interesting behavior, bugs or __//performance issues//__.
-<spoiler>
+In case you are still wondering, in this exercise we are going to look at (one of) the best dynamic analysis tools available: **Intel Pin**. Specifically, what Pin does is called program instrumentation, meaning that it inserts user-defined code at arbitrary locations in the executable. The code is inserted at runtime, meaning that Pin can attach itself to a process, just like **gdb**.
-As you've probably already seen in the previous exercise, TCP uses protocol extensions (called options) in order to negotiate session parameters and improve overall performance. Note that this mechanism has existed since the very inception of the protocol approx. 30 years ago ([[https://datatracker.ietf.org/doc/html/rfc793#section-3.1|RFC793 - Transmission Control Protocol]]), with many being added post-factum.
+Although Pin is closed source, the concepts that serve as its fundament are described in [[https://web.stanford.edu/class/cs343/resources/pin.pdf|this paper]]. Since we don't have time to scan through the whole material, we will offer a bird's eye view of its architecture. Just enough to get you started with the tasks.
-While the same could be said for IP options ([[https://datatracker.ietf.org/doc/html/rfc791#section-3.1|RFC791 - Internet Protocol]]), there have always been... issues. In 2005 it was decided that [[https://www2.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.pdf| IP Options are not an option]]. Middleboxes (i.e.: network equipment in the Internet -- routers, NATs, firewalls, etc.) would sometimes implement abridged versions of the protocol specifications. For IP options, this meant that the IHL field would be ignored and the header would always be considered to be 20 bytes in length. As a result, if a packet carried IP options, cheap network equipment would wrongly assume that the layer 4 header would start at a 20 byte offset and drop it due to erroneously perceived malformations.
+\\
+{{ :ep:labs:02:contents:tasks:pin_overview.png?700 }}
+<html><center>
+<b>Figure 2:</b> Simplified view of the memory layout of a process being instrumented by Intel Pin. The Pin-specific memory mapped regions contain our pintool, the instrumentation API of the framework and a sandbox region where instrumented code is being reconstructed as per our tool's specification. This reconstruction phase is costly but the process attains near-native speeds afterwards.
+</center></html>
-The authors of the 2005 report discovered that only a fraction (15%) of edge Autonomous Systems (AS -- huge, ISP-grade networks with a unified routing policy) were responsible for most packet drops. This made them optimistic towards a speedy resolution of this issue, but things haven't changed much in the past 15 or so years. Today IP options usually work just fine in local networks. As for the wider Internet, there are specific paths and networks where IP options can pass unthwarted, but only if the layer 4 protocol is ICMP. The logic may be that most IP options are used for path measurement anyway, so why use it in conjunction with anything other than ICMP (a pretty dumb argument, I admit... but it's not mine).
+When a process is started via Pin, the very first instruction is intercepted and new mappings are created in the virtual space of the process. These mappings contain //libraries// that Pin uses, the //tool// that the user wrote (which is compiled as a shared object) and a small //sandbox// that will act as a VM. During the execution, Pin will translate the original instructions into the sandbox on an as-needed basis and, according to the rules defined in the tool, insert arbitrary code. This code can be inserted at different levels of granularity:
+  * instruction
+  * basic block
+  * function
+  * image
-Luckily, one of these compliant networks is RoEduNet. If you're not working from the university's network, then start a VM instance on [[https://cloud-controller.grid.pub.ro/dashboard/auth/login/?next=/dashboard/|OpenStack]]. ISPs like RDS tend to drop IP Options. As a target, we will use [[https://www.digitalocean.com/|DigitalOcean]]. Based on some personal tests, I can guarantee that they don't drop any options, regardless of region.
+The immediate advantages should be clear. Only from a performance evaluation standpoint, a few applications could be:
+  * obtaining metrics from programs that were not designed with this in mind
+  * hotpatching bugs without stopping the process
+  * detecting the most accessed code regions to prioritize manual optimization
-{{ :ep:labs:04:contents:tasks:ip_recordroute.png?700 |}}
+Although this sounds great, we should not ignore some of the glaring disadvantages:
-<html>
+  * overhead
-<center>
+    * this is highly dependent on the amount of instrumentation and the instrumented code itself
-<b>Figure 2:</b> Layout of a layer 3 (IP) header with options. Their presence is confirmed by an Internet Header Length (IHL) value strictly larger than 5. Most options are Type-Length-Value (TLV) encoded. When the length is constant or there is no information to be included (e.g.: No Operation, End of Options List), deviations from this format can be accepted for the purpose of saving space.
+    * overall, this seems to have a bit more impact on ARM than on other architectures
-</center>
+  * volatile
-</html>
+    * remember that the instrumented code shares things like the virtual memory space and file descriptors with the original process
+    * while something like in-memory fuzzing is possible, the risk of breaking the process is very high
+  * limited use cases
+    * Pin works directly on a regular executable (with native bytecode)
+    * Pin will not work (as intended) on interpreted languages and variations of these
-<html><h4>Overarching Goal</h4></html>
+In case you are wondering what else you can do with **Intel Pin**, check out [[https://www.comp.nus.edu.sg/~prateeks/papers/TaintInduce.pdf|TaintInduce]]. The authors of this paper wrote an architecture agnostic taint analysis tool that successfully found 24 CVEs, 17 missing or wrongly emulated instructions in [[https://www.unicorn-engine.org/|unicorn]] and 1 mistake in the Intel Developer Manual.
-The first task is to modify outgoing traffic and include a Record Route option in an ICMP Echo Request. Check its description in [[https://datatracker.ietf.org/doc/html/rfc791|RFC791]] to understand what it does (and no, not "Loose/Strict Source and Record Route"... keep hitting that Find key). The packet structure will resemble that in the picture above. Don't worry; for this step, we'll give you a little help ;)
+For reference, use the [[https://software.intel.com/sites/landingpage/pintool/docs/98484/Pin/html/index.html|Intel Pin User Guide]] (also contains examples).
-Your second task will be to write a bash script that extracts the IP addresses from the ICMP Echo Response's Record Route option from a packet capture and perform an AS Lookup. In other words, you will determine the names of all the networks that the packet traverses on its way from the university to DigialOcean and back.
-But let's take it step-by-step.
+=== [5p] Task A - Setup ===
-<html><h4>Task A - Injecting IP Options</h4></html>
+In this tutorial we will build a Pin tool with the goal of instrumenting any memory reads/writes. For reads, we output the source buffer state before the operation takes place. For writes, we output the destination buffer states both before and after.
-Remember talking about **iptables** extensions earlier? **Netfilter Queue** is one of them and will be relevant for this task. What it is, is an **iptables** target. What it does, it redirects each matched packet to a userspace process for evaluation and optionally, //modification//.
+Download the {{:ep:labs:02:contents:tasks:minspect.zip|skeleton}} for this task. First thing you will need to do is run //setup.sh//. This will download the Intel Pin framework into the newly created //third_party/ // directory.
-The userspace process receives each packet by polling a [[https://man7.org/linux/man-pages/man7/unix.7.html|Unix Domain Socket]]. After obtaining one, it can perform any type of analysis that it wants (e.g.: [[https://dl.acm.org/doi/pdf/10.1145/1151659.1159952|deep packet inspection]]) in order to reach a verdict. The verdict can be the already known built-ins (i.e.: //ACCEPT, DROP,// etc.) or it can redirect the packet to another queue, with another process listening. When setting the verdict, a modified packet can be provided to replace the original on its datapath through the kernel's network stack.
+Next, open //src/minspect.cpp// in an editor of your choice, but avoid modifying the code. In between tasks, we will apply diff patches to this file. This will allow us to gradually build our tool and observe its behavior at different stages during its development. However, altering the source in any significant manner may cause the patch to fail.
-Enter [[https://github.com/RaduMantu/ops-inject|ops-inject]]. This is a tool (that's still under development, mind you) that allows the annotation of matched packets with IP/TCP/UDP options. Why is this tool simple to use: all you have to do is provide a sequence of bytes representing the [[https://www.iana.org/assignments/ip-parameters/ip-parameters.xhtml|codepoints]] of the options that you want to append. This byte stream is passed to an internal decoder that //expands// each byte into a fully-fledged option, albeit in accordance to an arbitrary implementation. Once you clone the repo, you should look over two sources in particular:
+Let us apply the first patch before proceeding to the following task:
-  * ''src/main.cpp'' : here, just understand what **libnetfilterqueue** library calls are made in order to set up the Unix socket, to receive the packet and to set its verdict.
-  * ''src/ops_ip.c'' : this is where all available IP Options are implemented; take a look at the **ip_decoders** vtable at the bottom to associate options and codepoints.
-First of all, let's fetch the tool and compile it.
 <code bash>
-$ git clone https://github.com/RaduMantu/ops-inject.git
+$ patch src/minspect.cpp patches/Task-A.patch
-$ cd !$:t:r
-$ make -j $(nproc)
 </code>
-<note tip>
+=== [10p] Task B - Instrumentation Callbacks ===
-//Pro tip #3//: [[https://www.gnu.org/software/bash/manual/html_node/Modifiers.html|Bash Modifiers]] and [[https://www.gnu.org/software/bash/manual/html_node/Word-Designators.html|Word Designators]]
-  * ''!$'' is substituted with the final argument of previously executed command
-  * '':t'' removes the leading pathname components, leaving //ops-inject.git//
-  * '':r'' removes exactly one trailing suffix, leaving //ops-inject//
-----
+Looking at //main()//, most Pin API calls are self explanatory. The only one that we're interested in is the following:
+<code C++>
+INS_AddInstrumentFunction(ins_instrum, NULL);
+</code>
+This call instructs Pin to trap on each instruction in the binary and invoke //ins_instrum()//. However, this happens only //once// per instruction. The role of the instrumentation callback that we register is to decide if a certain instruction is of interest to us. "Of interest" can mean basically anything. We can pick and choose "interesting" instructions based on their class, registers / memory operands, functions or objects containing them, etc.
-Troubleshooting:
+Let's say that an instruction has indeed passed our selection. Now, we can use another Pin API call to insert an //analysis routine// before or after said instruction. While the instrumentation routine will never be invoked again for that specific instruction, the analysis routine will execute seamlessly for each pass.
-  * **IPPROTO_ETHERNET error** : if your //netinet/in.h// is missing this definition, you can delete line 36 from //src/str_proto.c//.
-  * **libnetfilter-queue missing** : consider installing //libnetfilter-queue-dev// and //libnetfilter-queue1//.
-</note>
-Next, let's insert an **iptables** rule that matches all outgoing ICMP packets.
+For now, let us observe only the instrumentation callback and leave the analysis routine registration for the following task. Take a look at //ins_instrum()//. Then, compile the tool and run any program you want with it. Waiting for it to finish is not really necessary. Stop it after a few seconds.
-Take note of ''%%--%%queue-num 0'' for when we'll need to tell the userspace process which Netfilter Queue to subscribe. Also, ''%%--%%queue-bypass'' tells the **iptables** module to disable enqueuing packets if there's no process listening. Otherwise, the queue's buffer will fill up and overflowing packets will be dropped by default until some space is created.
 <code bash>
-$ sudo iptables -I OUTPUT -p icmp -j NFQUEUE --queue-num 0 --queue-bypass
+$ make
+$ ./third_party/pin-3.24/pin -t obj-intel64/minspect.so -- ls -l 1>/dev/null
 </code>
-Finally, run **ops-inject** while telling it to append the Record Route option (0x07). Because the tool takes a file as input, and because we give it the PseudoTerminal Slave of a [[https://www.gnu.org/software/bash/manual/html_node/Command-Grouping.html|subshell]], things can get messy if we simply run it with **sudo**. As a result, it's easier to just switch to **root**. To get a feel of what the other options do, just run ''ops-inject %%--%%help'' once.
+Just to make sure everything is clear: the default rule for //make// will generate an //obj-intel64/ // directory and compile the tool as a shared object. The way to start a process with our tool's instrumentation is by calling the //pin// util. **-t** specifies the tool to be used. Everything after **%%--%%** should be the exact command that would normally be used to start the target process.
-<code>
+**Note:** here, we output information to stderr from our instrumentation callback. This is not good practice. The Pin tool and the target process share pretty much everything: file descriptors, virtual memory, etc. Normally, you will want to output these things to a log file. However, let's say we can get away with it for now, under the pretext of convenience.
-$ sudo su
-# ./bin/ops-inject -p ip -q 0 -w <(printf '\x07')
-</code>
-Having completed the setup, let's generate some traffic!
+Remember to apply the //Task-B.patch// before proceeding to the next task.
-<code bash>
+<spoiler>
-$ ping -c 3 $(dig +short digitalocean.com | head -n 1)
+{{ :ep:labs:02:contents:tasks:pin_tb.png?700 |}}
-    PING 104.16.182.15 (104.16.182.15) 56(84) bytes of data.
+<html><center>
-bytes from 104.16.182.15: icmp_seq=1 ttl=57 time=46.7 ms
+<b>Figure 3:</b> Each instruction is instrumented with a routine that outputs the memory mapped object containing it (red), the section inside that object (green), the function name (blue; defaults to section name if no symbol available), and the runtime address (yellow). The same routine also prints the instruction itself, using Pin's built-in disassembler.
-    RR:     141.85.13.15
+</center></html>
-.128.225.226
+</spoiler>
-.128.232.178
-.128.232.177
-.97.248.33
-.158.16.1
-.16.182.15
-.16.182.15
-.158.16.1
-bytes from 104.16.182.15: icmp_seq=2 ttl=57 time=14.2 ms     (same route)
+=== [10p] Task C - Analysis Callbacks (Read) ===
-bytes from 104.16.182.15: icmp_seq=3 ttl=57 time=18.2 ms     (same route)
-</code>
-Normally, we would need **wireshark** or **tcpdump** to see the result but fortunately, **ping** is able to understand the Record Route option. The reason for this is that it can generate it itself (see ''-R'' option). Should it have wondered that it received a Record Route option in response to a normal ICMP Echo Request? Apparently not...
+Going forward, we got rid of some of the clutter in //ins_instrum()//. As you may have noticed, the most recent addition to this routine is the //for// iterating over the memory operands of the instruction. We check whether each operand is the source of a read using [[https://software.intel.com/sites/landingpage/pintool/docs/81205/Pin/html/group__INS__BASIC__API__GEN__IA32.html#ga3fdb434cd56a5b72be15dd0931a2b19c|INS_MemoryOperandIsRead()]]. If this check succeeds, we insert an //analysis routine// before the current instruction using [[https://software.intel.com/sites/landingpage/pintool/docs/81205/Pin/html/group__INS__INST__API.html#ga26d02bff719bf8600421895956804252|INS_InsertPredicatedCall()]]. Let's take a closer look at how this API call works:
-<note important>
+<code C++>
-If your ISP is blocking IP options, try **ping**-ing your //default gateway//.
+INS_InsertPredicatedCall(
+    ins, IPOINT_BEFORE, (AFUNPTR) read_analysis,
+    IARG_ADDRINT,       ins_addr,
+    IARG_PTR,           strdup(ins_disass.c_str()),
+    IARG_MEMORYOP_EA,   op_idx,
+    IARG_MEMORYREAD_SIZE,
+    IARG_END);
+</code>
-Normally, that should work, but there is really no guarantee. A TP-Link router usually runs Linux 2.6 (at least) and does its job well. A Tenda router, however, most likely runs some garbage proprietary firmware and won't even reply to an ICMP Echo Request with IP options.
+The first three parameters are:
-</note>
+  * ''ins'': reference to the INS argument passed to the instrumentation callback by default.
+  * ''IPOINT_BEFORE'': instructs to insert the analysis routine //before// the instruction executes (see [[https://software.intel.com/sites/landingpage/pintool/docs/97503/Pin/html/group__INST__ARGS.html|Instrumentation arguments]] for more details.)
+  * ''read_analysis'': the function that is to be inserted as the analysis routine.
+Next, we pass the arguments for //read_analysis()//. Each argument is represented by a type macro and the actual value. When we don't have any more parameters to send, we end by specifying **IARG_END**. Here are all the arguments:
+  * ''IARG_ADDRINT, ins_addr'': a 64-bit integer containing the absolute address of the instruction.
+  * ''IARG_PTR, strdup(ins_disass.c_str())'': all objects in the callback's local context will be lost after we return; thus, we need to duplicate the disassembled code's string and pass a pointer to the copy.
+  * ''IARG_MEMORYOP_EA, op_idx'': effective address of a specific memory operand; so this argument is not passed by value, but in stead recalculated each time and passed to the analysis routine seamlessly.
+  * ''IARG_MEMORYREAD_SIZE'': size in bytes of the memory read; check the documentation for some important exceptions.
-From this point onward, it's all you! :)
+Take a look at what //read_analysis()// does. Recompile the tool and run it again (just as in task B). Finally, apply //Task-C.patch// and move on to the next task.
-<html><h4>Task B - Traffic capture</h4></html>
+<spoiler>
+{{ :ep:labs:02:contents:tasks:pin_tc.png?700 |}}
+<html><center>
+<b>Figure 4:</b> Another instruction-level instrumentation routine, targeting only instructions that perform memory reads. It prints the runtime address and the disassembly of each instruction. Additionally, it outputs the value of the read memory (green). The reads can be direct (e.g.: <b>mov</b>) or indirect (e.g.: <b>ret</b> -- obtains the return address from the stack).
+</center></html>
+</spoiler>
-Run the same experiment with ICMP Echo Request again, but this time capture the traffic using **tcpdump** and write it to a //pcap capture file//.
+=== [10p] Task D - Analysis Callbacks (Write) ===
-<note tip>
+For the memory write analysis routine, we need to add instrumentation both before and after each instruction. The former needs to save the original buffer state while the latter displays the information in its entirety. Assuming that there are more than one memory locations that are written to, we push the initial buffer state hexdumps to a stack. Consequently, we need to add the post-write instrumentation in reverse order to ensure that the succession of elements popped from the stack is correct. Let's take a look at the pre-write instrumentation insertion:
-Consider using the ''-U'' option in **tcpdump** to avoid buffering packets if you plan to suddenly stop it with //Ctrl^C//.
-</note>
-<note important>
+<code C++>
-If you had reachability problems at task A and IP options just can't get through, use {{:ep:labs:04:contents:tasks:ip-ops.zip|this pcap}} starting with Task C. It contains pretty much what you were supposed to get.
+INS_InsertPredicatedCall(
+    ins, IPOINT_BEFORE, (AFUNPTR) pre_write_analysis,
+    IARG_CALL_ORDER,    CALL_ORDER_FIRST + op_idx + 1,
+    IARG_MEMORYOP_EA,   op_idx,
+    IARG_MEMORYWRITE_SIZE,
+    IARG_END);
+</code>
-As for Task B, show us that you can capture traffic correctly by targeting the //default gateway// again.
+We notice a new set of parameters:
-</note>
+  * ''IARG_CALL_ORDER, CALL_ORDER_FIRST + op_idx + 1,'': specifies the call order when multiple analysis routines are registered; see [[https://software.intel.com/sites/landingpage/pintool/docs/97503/Pin/html/group__INST__ARGS.html#ga3d1d5f6805cb16d00bce441290ca2212|CALL_ORDER enum]]'s documentation for details.
-<solution -hidden>
+Recompile the tool. Test to see that the write analysis routines work properly. Apply //Task-D.patch// and let's move on to applying the finishing touches.
-<code bash>
-$ sudo tcpdump -Uw ip-ops.pcap 'icmp and host 104.16.181.15'
-</code>
-</solution>
-<html><h4>Task C - Route extraction</h4></html>
+<spoiler>
+{{ :ep:labs:02:contents:tasks:pin_td.png?700 |}}
+<html><center>
+<b>Figure 5:</b> An extension of the instrumentation routine in the previous sub-task, accounting for memory writes in addition to memory reads. For these, it prints the state of the written memory both prior (yellow) and after (red) the instruction retired.
+</center></html>
+</spoiler>
-Use **tshark** to extract the Record Route payload of ICMP Echo Replies from the created //pcap//. \\
+=== [5p] Task E - Finishing Touches ===
-You only need the IPs of the intermediary hops; these will be further processed in your script at Task D.
-<note tip>
+This is only a minor addition. Namely, we want to add a command line option **-i** that can be used multiple times to specify multiple image names (e.g.: ls, libc.so.6, etc.) The tool must forego instrumentation for any instruction that is not part of these objects. As such, we declare a [[https://software.intel.com/sites/landingpage/pintool/docs/98189/Pin/html/group__KNOB__BASIC.html|Pin KNOB]]:
-  * Check out the ''-Y'' option in ''man tshark(1)''.
-  * Look for the appropriate [[https://www.wireshark.org/docs/dfref/i/ip.html|IPv4 Display Filter]].
-  * Test filter expressions in **wireshark** before applying them in **tshark**.
-</note>
-<solution -hidden>
+<code C++>
-<code bash>
+static KNOB<string> knob_img(KNOB_MODE_APPEND,    "pintool",
-$ tshark -r ip-ops.pcap -Tfields -e ip.rec_rt 'icmp.type == 0 && ip.rec_rt'
+        "i", "", "names of objects to be instrumented for branch logging");
 </code>
-</solution>
-<html><h4>Task D - AS lookup</h4></html>
+We should not use [[https://www.gnu.org/software/libc/manual/html_node/Argp.html|argp]] or other alternatives. In stead, let Pin use its own parser for these things. ''knob_img'' will act as an accumulator for any argument passed with the flag **-i**. Observe it's usage in //ins_instrum()//.
-Write a //bash script// starting from your **tshark** command. The script must perform an AS lookup and display information about each registered hop (e.g.: IP, AS name, etc.), for all packets in the //pcap//. Run the script. What do you notice?
+Determine the shared object dependencies of your target binary of choice. Then try to recompile and rerun the Pin tool while specifying some of them as arguments.
-<html>
-    <details>
-        <summary>The output should look something like this ± a few info.</summary>
-        <center>
-            <img src="https://ocw.cs.pub.ro/courses/_media/ep/labs/04/contents/tasks/ip-rr_sample.png">
-            <br>
-            <b>Figure 3:</b> Packet sent from <i>104.16.181.15</i> to <i>172.19.7.205</i>. In green are enumerated middleboxes (e.g.: routers) that added the IP of their outgoing interface to the buffer of the RR option. Not all may do so, depending on the implementation of their networking stack! In blue we have part of the publicly available information regarding the Autonomous System that said IP addresses belong to.
-        </center>
-    </details>
-</html>
-<note tip>
-In order to get the required information, use the **whois** tool.
 <code bash>
-$ whois ${SOME_IP}
+$ ldd /bin/ls
-$ whois -h whois.cymru.com -- -v ${SOME_IP}
+        linux-vdso.so.1 (0x00007ffd0d19b000)
+        libgtk3-nocsd.so.0 => /usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 (0x00007f32df3ad000)
+        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f32df185000)
+        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f32ded94000)
+        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f32deb90000)
+        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f32de971000)
+        libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f32de6ff000)
+        /lib64/ld-linux-x86-64.so.2 (0x00007f32df7d6000)
 </code>
-Want to make your script's output look pretty? Remember that you have [[https://www.lihaoyi.com/post/BuildyourownCommandLinewithANSIescapecodes.html|ANSI color escape codes]] :)
+This concludes the tutorial. The resulting Pin tool can now be used as a starting point for developing a [[https://users.ece.cmu.edu/~aavgerin/papers/Oakland10.pdf|Taint analysis]] engine. Discuss more with your lab assistant if you're interested.
-</note>
-<solution -hidden>
+Patch your way through all the tasks and run the pin tool only for the base object of any binutil. \\
-<file bash analyze_rr.sh>
+Include a screenshot of the output.
-#!/bin/bash
-# analize_rr.sh - perform AS lookup on IP RR content
-#   $1 : [required] path to a pcap file
-###############################################################################
-############################## ANSI ESCAPE CODES ##############################
-###############################################################################
-ANSI_RED='\033[31m'
-ANSI_GREEN='\033[32m'
-ANSI_YELLOW='\033[33m'
-ANSI_BLUE='\033[34m'
-ANSI_PURPLE='\033[35m'
-ANSI_CYAN='\033[36m'
-ANSI_BOLD='\033[1m'
-ANSI_UNBOLD='\033[2m'
-ANSI_CLEAR='\033[0m'
-###############################################################################
-################################# ENTRY POINT #################################
-###############################################################################
-# argument check
-if [[ $# -ne 1 || ! -f $1 ]]; then
-    echo 'Usage: ./analize_rr.sh PCAP_FILE'
-    exit 1
-fi
-# parse ICMP Echo Replies in pcap while extracting relevant fields
-while read -r SRC_IP DST_IP ROUTE; do
-    # print info about src and dst IP for current packet
-    printf '%b%b%15s%b ==> %b%b%-15s%b\n'                   \
-        ${ANSI_YELLOW} ${ANSI_BOLD} ${SRC_IP} ${ANSI_CLEAR} \
-        ${ANSI_YELLOW} ${ANSI_BOLD} ${DST_IP} ${ANSI_CLEAR}
-    # parse each hop in recorded route
-    while read -d , -r HOP_IP; do
-        # print recorded hop IP
-        printf '\t%b%bHop: %b%s%b\n'   \
-            ${ANSI_GREEN} ${ANSI_BOLD} \
-            ${ANSI_UNBOLD} ${HOP_IP} ${ANSI_CLEAR}
-        # get organization info
-        # NOTE: whois can access either RIPE or ARIN databases
-        #       account for different formats
-        printf '\t\t%b%b%-14s: %b%s%b\n' \
-            ${ANSI_BLUE} ${ANSI_BOLD}    \
-            'Net Name' ${ANSI_UNBOLD}    \
-            "$(whois ${HOP_IP}           \
-            | grep -i 'netname'          \
-            | tail -n 1                  \
-            | awk '{$1=""; print $0}'    \
-            | xargs)"                    \
-            ${ANSI_CLEAR}
-        printf '\t\t%b%b%-14s: %b%s%b\n' \
-            ${ANSI_BLUE} ${ANSI_BOLD}    \
-            'Org Name' ${ANSI_UNBOLD}    \
-            "$(whois ${HOP_IP}           \
-            | grep -i 'orgname'          \
-            | tail -n 1                  \
-            | awk '{$1=""; print $0}'    \
-            | xargs)"                    \
-            ${ANSI_CLEAR}
-        # fetch AS info in one request & print
-        IFS='|' read -r AS_NUM IP BGP_PREFIX COUNTRY REGISTRY DATE AS_NAME \
-            < <(whois -h whois.cymru.com -- -v ${HOP_IP}                   \
-              | tail -n 1                                                  \
-              | sed 's/[ ]*|[ ]*/|/g')
-        printf '\t\t%b%b%-14s: %b%s%b\n'              \
-            ${ANSI_BLUE} ${ANSI_BOLD} 'AS Num'        \
-            ${ANSI_UNBOLD} ${AS_NUM:-'NA'} ${ANSI_CLEAR}
-        printf '\t\t%b%b%-14s: %b%s%b\n'              \
-            ${ANSI_BLUE} ${ANSI_BOLD} 'BGP Prefix'    \
-            ${ANSI_UNBOLD} ${BGP_PREFIX:-'NA'} ${ANSI_CLEAR}
-        printf '\t\t%b%b%-14s: %b%s%b\n'              \
-            ${ANSI_BLUE} ${ANSI_BOLD} 'Country'       \
-            ${ANSI_UNBOLD} ${COUNTRY:-'NA'} ${ANSI_CLEAR}
-        printf '\t\t%b%b%-14s: %b%s%b\n'              \
-            ${ANSI_BLUE} ${ANSI_BOLD} 'Reg Authority' \
-            ${ANSI_UNBOLD} ${REGISTRY:-'NA'} ${ANSI_CLEAR}
-        printf '\t\t%b%b%-14s: %b%s%b\n'              \
-            ${ANSI_BLUE} ${ANSI_BOLD} 'Reg Date'      \
-            ${ANSI_UNBOLD} ${DATE:-'NA'} ${ANSI_CLEAR}
-    done <<<"${ROUTE},"
-done < <(tshark -r ${1}             `# input pcap file`        \
-                -Y 'icmp.type == 0' `# filter ICMP echo reply` \
-                -T fields           `# output format`          \
-                -e ip.src           `# print src IP`           \
-                -e ip.dst           `# print dst IP`           \
-                -e ip.rec_rt        `# print recorded route`   )
-</file>
-</solution>
-<html><h4>Task E - AS lookup (part II)</h4></html>
-As you might have noticed during the previous task, even DigitalOcean uses CloudFlare.
-{{:ep:labs:04:contents:tasks:docean-icmp.zip|This archive}} contains a //pcap// with ICMP Echo Request/Replies sent from the university to four VMs hosted on DigitalOcean. Run your script again, on this //pcap// and see if you can spot any interesting organization names. Then, look them up.
-Not really relevant, but here are the IP addresses of the VMs involved:
-<code>
-New York           134.122.28.219
-Frankfurt          46.101.222.105
-Singapore          178.128.213.179
-Toronto            165.22.239.70
-UPB (localhost)    10.5.0.1
-</code>
-</spoiler>

General Information

Lectures

Labs

Assignments

Archived Labs

ep/labs/04/contents/tasks/ex4.1698605138.txt.gz · Last modified: 2023/10/29 20:45 by radu.mantu

Show page Old revisions

Media Manager Back to top