Lab46 Wiki

User Tools

Site Tools

You are here: start » haas » spring2015 » unix » projects » udr2
haas:spring2015:unix:projects:udr2

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
haas:spring2015:unix:projects:udr2 [2015/03/16 14:42] – [Process] wedgehaas:spring2015:unix:projects:udr2 [2015/03/30 16:39] (current) – [Errata] wedge
Line 11: Line 11:
 Typos and bug fixes: 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===== =====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**). 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 232: Line 234:
   * session-201303051015.raw (511190 bytes) -- nap   * session-201303051015.raw (511190 bytes) -- nap
  
-Session files are named with the date and time of the start of the particular sleep session, encoded as follows:+Session files are named with the date and time of the start of the particular sleep session, encoded as follows (YYYYMMDDhhmm):
  
   * YYYY - 4-digit year (2012)   * YYYY - 4-digit year (2012)
   * MM - 2-digit month (11)   * MM - 2-digit month (11)
   * DD - 2-digit day (02)   * DD - 2-digit day (02)
-  * HH - 2-digit hour (24-hour time, so 03 means 3am) +  * hh - 2-digit hour (24-hour time, so 03 means 3am) 
-  * MM - 2-digit minute (09)+  * mm - 2-digit minute (09)
  
 So, 201211020309 means 2012/11/02 at 3:09am was the recorded time of the start of this particular sleep session (I was exploring with a dual core sleep schedule around this time, so this would have been my 2nd core). So, 201211020309 means 2012/11/02 at 3:09am was the recorded time of the start of this particular sleep session (I was exploring with a dual core sleep schedule around this time, so this would have been my 2nd core).
  
 =====Task===== =====Task=====
-With the provided data files, I'd like for you to do the following:+With the provided data files, I'd like for you to do the following (be sure to provide commands for each as well as the answer you got):
  
   * determine the number of data packets in each file   * determine the number of data packets in each file
Line 252: Line 254:
     * what is the timestamp (as a 32-bit value)     * what is the timestamp (as a 32-bit value)
     * what is the calendar date and time of that timestamp, when appropriately translated?     * what is the calendar date and time of that timestamp, when appropriately translated?
 +  * which file had the most deep sleep?
 +    * how much took place?
 +    * how did you figure this out?
 +    * what was the approximate time?
 =====Useful tools===== =====Useful tools=====
 You may want to become familiar with the manual pages of the following tools (in addition to tools you've already encountered): You may want to become familiar with the manual pages of the following tools (in addition to tools you've already encountered):
Line 257: Line 263:
   * **dd**(1)   * **dd**(1)
   * **bc**(1)   * **bc**(1)
-  * **du**(1) +  * **od**(1) - as I've said to others, **od** is like **cat**, but for binary data
-  * **bash**(1) shell scripting +
-  * **od**(1)+
   * **bvi**(1)   * **bvi**(1)
   * **hexedit**(1)   * **hexedit**(1)
 +  * **grep**(1) - can be contorted to cooperate
 +  * **date**(1) - might be useful for time/date manipulations
 +  * **bgrep** (see below for usage)
  
 ... along with other tools previously encountered. ... 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' 
 +533b:12 34 
 +29af3:12 34 
 +29dff:12 34 
 +29f85:12 34 
 +2a8a9:12 34 
 +2aa2f:12 34 
 +2abb5:12 34 
 +2aec1:12 34 
 +2b353: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' 
 +3326: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.' 
 +1cf4:12 ee 
 +206d:12 e0 
 +3325:12 e0 
 +3907:12 e0 
 +4077:12 e0 
 +4795:12 e0 
 +50a1:12 e0 
 +552b:12 e0 
 +5edb:12 e0 
 +73e7:12 e0 
 +81b9:12 e0 
 +8df9:12 e0 
 +8fcf:12 e0 
 +aae3:12 e0 
 +aae7:12 e0 
 +b859:12 e0 
 +3415c:12 e9 
 +4e11f:12 e0 
 +6bd5b:12 ed 
 +796f7:12 e0 
 +7b877:12 e0 
 +7d3df:12 e0 
 +7e7e1:12 e0 
 +7e7f5:12 e0 
 +7ecf7: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' 
 +91c1:3c 34 
 +29029:8c 34 
 +297e5:0c 34 
 +322d3:ec 34 
 +6152b:dc 34 
 +6a683:0c 34 
 +6ef95: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===== =====Submission=====
 Successful completion will result in the following criteria being met: 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==== ====Submit====
 Please submit as follows: Please submit as follows:
  
 <cli> <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 SUCCESSFULLY SUBMITTED
-lab46:~/src/unix/udr1$ +lab46:~/src/unix/udr2$ 
 </cli> </cli>
haas/spring2015/unix/projects/udr2.1426516976.txt.gz · Last modified: 2015/03/16 14:42 by wedge

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki