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 13:37] – [Example Analysis] 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 124: Line 126:
 The byte prior to the next "A4" (the next line-- **000025A8**) occurs at offset **000025AD**. The byte prior to the next "A4" (the next line-- **000025A8**) occurs at offset **000025AD**.
  
-It would seem (especially upon converting 259E and 25AD to decimal), there is a 15 byte duration to this particular packet. Let's dig deeper...+It would seem (especially upon converting 259E and 25AD to decimal), there is a 15 byte difference (so a 16-byte duration) to this particular packet. Let's dig deeper...
  
 First, to reduce analysis paralysis, let us extract specifically this byte. First, to reduce analysis paralysis, let us extract specifically this byte.
Line 215: Line 217:
  
 Pretty awesome, right? Pretty awesome, right?
-=====Obtain the file===== +=====Obtain the files===== 
-This week's project is located in the **spring2015/udr1/** directory of the UNIX Public Directory, in a file called: **data.file**+This week's project is located in the **spring2015/udr2/** directory of the UNIX Public Directory, in an archive called: **sleepfun.tar.bz2**
  
 Make a copy of this into your home directory somewhere and set to work. Make a copy of this into your home directory somewhere and set to work.
  
 **NOTE:** Hopefully it has been standard practice to locate project files in their own unique subdirectory, such as under **src/unix/**, where you can then add/commit/push the results to your repository (you ARE regularly putting stuff in your repository, aren't you?) **NOTE:** Hopefully it has been standard practice to locate project files in their own unique subdirectory, such as under **src/unix/**, where you can then add/commit/push the results to your repository (you ARE regularly putting stuff in your repository, aren't you?)
-  
-=====Process===== 
-The data you seek (2 files) is obfuscated and contained within this file. 
  
-Plain text directions give clues on how to find both pieces of information, and it is up to you to use your skills to extract the necessary data.+=====Data Files===== 
 +Upon extraction of the files in **sleepfun.tar.bz2**, you should have the following files:
  
-Some additional information:+  * session-201211020309.raw (5866460 bytes, or 5.6MB) -- core sleep session 
 +  * session-201301041418.raw (360135 bytes) -- nap 
 +  * session-201301311908.raw (4955855 bytes) -- core sleep session 
 +  * session-201302010218.raw (2719296 bytes) -- core sleep session 
 +  * session-201302200614.raw (524705 bytes) -- nap 
 +  * session-201303051015.raw (511190 bytes) -- nap
  
-  * The first file should be named **udr1.text** and be properly oriented. +Session files are named with the date and time of the start of the particular sleep session, encoded as follows (YYYYMMDDhhmm):
-  * The second (big) file runs from the starting point until the very end of the file +
-  * It should be named 'gizmo', and reside in your current working directory. +
-  * gizmo is binary data, and entirely reversed- you need to get its bytes back in order (last byte should be first byte, 2nd to last should be 2nd, etc.) +
-    * You are to write a shell script to perform the de-reversal of the data, reading from data.file and through whatever processing is needed, produce the file called **gizmo**. +
-  * The **urev** tool has some additional constraints with respect to gizmo... running it should notify you of any details you are lacking.+
  
 +  * YYYY - 4-digit year (2012)
 +  * MM - 2-digit month (11)
 +  * DD - 2-digit day (02)
 +  * hh - 2-digit hour (24-hour time, so 03 means 3am)
 +  * 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).
 +
 +=====Task=====
 +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 total time elapsed in the session file
 +  * determine the total time in a sleep state (not undefined, not conscious)
 +  * find a data packet during a time of rem or deep sleep that stores the complete timestamp, and:
 +    * extract that packet from the pertinent data file (provide command)
 +    * what is the timestamp (as a 32-bit value)
 +    * 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 241: 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.1426513079.txt.gz · Last modified: 2015/03/16 13:37 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