Differences

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

--- haas:spring2015:unix:projects:udr2 [2015/03/16 14:57] – [Task] wedge
+++ haas:spring2015:unix:projects:udr2 [2015/03/30 16:39] (current) – [Errata] wedge
@@ Line 11: / Line 11: @@
 Typos and bug fixes:
-  * no fixes of note
+  * bgrep was giving the address of the last byte matched of a pattern, vs. the address of the start of the matched pattern (the intended action). This has been corrected, and **bgrep** has been updated. (20150322)
+    * This should not change anything, save for saving you an additional calculation to determine the start of the packet.
+  * My aforementioned fix did not work, reverted **bgrep** to original version (20150324)
+  * Implemented new fix: **bgrep** should now be correctly reporting the starting address of the matched pattern -- no change on your part, just start using it (and be aware that the address represents the start of the pattern, and not the end) (20150330)
 =====Objective=====
 Continuing our "1337 haxxing" series of projects, we've found considerable conceptual self-imposed roadblocks blocking our employment of otherwise simple computing properties (that data is a series of bytes, and ultimately, that **everything is a file**).
@@ Line 266: / Line 268: @@
   * **grep**(1) - can be contorted to cooperate
   * **date**(1) - might be useful for time/date manipulations
-  * check out provided **bgrep.c** source code; compile and use as needed
+  * **bgrep** (see below for usage)
 ... along with other tools previously encountered.
+====bgrep====
+To assist you with this project, a special "binary grep" has been deployed on the system, called **bgrep**. bgrep searches for patterns among binary data, as part of STDIN.
+It supports space-separated (or not) bytes of data, and even allows the use of '.' to denote any hex value (remember, it takes 2 hex values to occupy a byte).
+===Example Usage===
+Let's say you wanted to search for the consecutive bytes 0x12 and 0x34 within a binary file:
+<cli>
+$ cat session-201302200614.raw | bgrep '12 34'
+b:12 34
+af3:12 34
+dff:12 34
+f85:12 34
+a8a9:12 34
+aa2f:12 34
+abb5:12 34
+aec1:12 34
+b353:12 34
+$
+</cli>
+What you see are the addresses (in hex) that denote the start of this requested pattern (0x12 immediately followed by 0x34).
+If you wanted 0x12 followed by anything, followed by 0x34, we'd do:
+<cli>
+$ cat session-201302200614.raw | bgrep '12 .. 45'
+:12 e0 45
+$
+</cli>
+In this case, there is only one such match in the entire file.
+The '.' pattern can also be applied to only part of a byte... 0x12 0xe# (we don't care what the lower order 4-bits are, but the upper 4-bits of the second byte MUST be an 0xe):
+<cli>
+$ cat session-201302200614.raw | bgrep '12 e.'
+cf4:12 ee
+d:12 e0
+:12 e0
+:12 e0
+:12 e0
+:12 e0
+a1:12 e0
+b:12 e0
+edb:12 e0
+e7:12 e0
+b9:12 e0
+df9:12 e0
+fcf:12 e0
+aae3:12 e0
+aae7:12 e0
+b859:12 e0
+c:12 e9
+e11f:12 e0
+bd5b:12 ed
+f7:12 e0
+b877:12 e0
+d3df:12 e0
+e7e1:12 e0
+e7f5:12 e0
+ecf7:12 e0
+$
+</cli>
+We can see variations in the lower 4-bits as it matches our desired pattern.
+Finally, upper 4-bits can be anything, lower 4 must be 0xc, followed by 0x23:
+<cli>
+$ cat session-201302200614.raw | bgrep '.c34'
+c1:3c 34
+:8c 34
+e5:0c 34
+d3:ec 34
+b:dc 34
+a683:0c 34
+ef95:6c 34
+$
+</cli>
+Notice in this last pattern, we opted not to space separate the pattern... it works either way (output will be space-separated regardless).
+This will hopefully prove to be a useful tool in your binary analysis endeavors.
 =====Submission=====
 Successful completion will result in the following criteria being met:
-  * Resulting file with proper settings should enable you to run **urev** tool.
+  * When all is said and done, you will submit:
-  * You have completed all weekly exercises (96, I think) before the deadline, being mindful of the intentionally-paced nature of urev.
+    * **udr2.text**, containing the answers/responses to all the above questions (including commands used to pull off the project)
-    * Bonus opportunity: while still performing a minimum of 3 distict **urev** sessions, how could you get around the urev-imposed time limit? (Without copying/changing urev).
-  * When all is said and done, you will submit 3 files:
-    * **udr1.text**
-      * Append the dd line(s) as well as any other command lines needed to extract and properly re-orient the file. Also be sure to indicate what is in the file you found (content, not just type of data).
-    * your bash script enabling the processing of data.file to produce gizmo
-      * Be sure to include comments indicating the reasoning behind actions taken
-    * Your extracted/processed **gizmo** file
 ====Submit====
 Please submit as follows:
 <cli>
-lab46:~/src/unix/udr1$ submit unix udr1 udr1.text getgizmo.bash gizmo
+lab46:~/src/unix/udr2$ submit unix udr2 udr2.text
-Submitting unix project "udr1":
+Submitting unix project "udr2":
-    -> udr1.text(OK)
+    -> udr2.text(OK)
-    -> getgizmo.bash(OK)
-    -> gizmo(OK)
 SUCCESSFULLY SUBMITTED
-lab46:~/src/unix/udr1$
+lab46:~/src/unix/udr2$
 </cli>

Lab46 Wiki

User Tools

Site Tools

Differences

Page Tools