Trying to attack this one step at a time. The first task is:

determine the number of data packets in each file

for session-201211020309.raw I ran:

cat session-201211020309.raw | bgrep “A4” | wc -l

and got 2922. I was wondering if that would be correct? I belive this
would be correct because it searches for every instance of A4 which
indicates the start of a pack and count how many times it appears.

Chris,

0xA4 represents a single hex value, the binary being: 10100100 (1 byte)

EEG packets start with a byte containing an 'A' (0x41) followed by a byte containing '4' (0x34), in binary:

  'A' (0x41): 0100 0001
  '4' (0x34): 0011 0100

0xA4 is 1 byte

“A4” is a 0x41 followed by a 0x34 (2 bytes).

So while there is certainly validity to your approach to getting a count, you're actually not searching for the correct data packet starting sequence. That would be:

  "41 34" (byte containing a 0x41 'A', followed by a byte containing 0x34

'4').

Which would get a more accurate result.

So then why won't

cat session-201211020309.raw | bgrep '……….. 00 15'

it gives me error: malformed pattern

Chris,

It isn't working, because you're not describing a minimally complete set of information.

We know that the data packets start with a byte containing a 'A' (0x41), immediately followed by a '4' (0x34)… if we were to look for 0xA4, that would NOT be the same thing (0xA4 describes one byte, where 'A' followed by '4' describes two consecutive bytes: 41 34)

The '.' pattern matching symbol I provide matches any single hex digit… but, as each hex digit only occupies 4-bits, that is merely half a byte. If we want to describe a whole byte (using the '.' character), we need to describe all 8-bits, so we'd use two '.''s in sequence: ..

My bgrep tool is flexible though, allowing for scenarios when we might also JUST want to match ONLY upper-order 4-bits, or ONLY the lower-order 4-bits… hence why only a single '.' can be used, so long as it is paired with the hex digit you ARE interested in for the other 4-bits of the byte.

So, when you're saying the above:

that's saying I don't care what the first 11 bytes are I just want to know
what when I see those for the 12th and 13th byte.

You're actually not saying this at all, you're saying:

      .. .. .. .. .. . 00 15
      1 2 3 4 5 ^ 6  7

To try and match 7.5 bytes, which is an ambiguous request (as the tool was designed to process in units of entire bytes)

I'm just trying to find away to help narrow it down. when I bvi the
session i noticed a patteren in the begging and then latter on in the file
there is no pattern that I notice so not really too sure how to attack
this project.

Each data packet IS a pattern… a pattern of bytes that conforms to the packet and sub-field information that you will find in any valid packet in the session files.

Aside from things like the 'A' '4' starting sequence, though, the data in the packet is meant to be interpret as one group.. the checksum byte is only useful in the context of the data type and data block fields.. the msglen informs us as to the total size of the data type and data block fields… there's a lot of data interdependence going on, to help ensure information is valid… this exists across any serious communications protocol… TCP, USB, ATA… there has to be some way of verifying what we just received is information, and to have some means of determining if an error has taken place. While MOST of the time the data comes across just fine (as I expect to be the case in the session files), all the other data must still come along for the ride, as there's no way to be absolutely sure if an error will occur or not (especially in transit).

Your approach is not incorrect… you're just running into the sort of conceptual issues that I am expecting everyone to run into (so everyone can become more familiar with binary data, how it is represented, etc.) In fact, as has become a recognized pattern with you– you continually are demonstrating an established troubleshooting mentality, which is quite advantageous, and once you calibrate yourself to this particular project, will see you making some impressive inroads very quickly (you just don't like working with unfamiliar concepts, which is certainly not a “just you” sort of thing… it is a “general human tendency” sort of thing.. your ability to more quickly voice your uncertainty/confusion/frustration is less common, and is what has given you specific advantages and led to impressive accomplishments ever since you started doing so all those weeks ago).

So: do you understand why '..' is representative of ANY (full) byte, and '.' is only describing half a byte? Can you rewrite your desired line above to perform your intended search?

And then: how can you make it even better, so you know that the 00 15 occurs at their desired byte offsets on a legitimate data packet?

I don't expect this to come easy to most people… as I've said… this stuff has been progressively hidden from our view over the years. Computer hardware used to be ALL ABOUT this (ever play with hardware that could ONLY be configured with jumpers– and NOT with “plug and play”? Sound cards used to have rows of jumpers allowing you to configure their address, IRQ, etc., and if you set it wrong, the hardware could lock up or be unstable.. managing computer hardware required a detailed understanding of resource usage, where today we expect the computer to do it all for us (plug and play)… which most are happy with, so long as things work as they are supposed to).

And not only that, but the “data” we've come to know over the years has been predominantly “text” in nature… coming to understand that 'A' is 0x41, and “41” is 0x34 0x31 (as far as how the computer is ACTUALLY storing it)… and then when we have something like 0xDC, that is 8-bits, where the 0xD is the upper 4-bits (1101) and 0xC is the lower 4-bits (1100)… yet to interact with them on the screen, they are visualized as characters “DC” is 0x44 0x43 (but only to display the 0xD and 0xC to the screen)… lots of discrete uses of abstract concepts. But exactly the same thing exists which makes a Hardware and Networking person specialized as compared to the general population… you understand concepts that are “greek” to others, for the same reason everyone is now having trouble with this (even though this is a far more real representation of what the hardware/networking you know uses to operate for you, day after day).

Keep up the good work, you're a lot closer than you think, and currently a lot farther ahead than most of the rest of the class (I've only heard from 1-2 others, so there'll likely be a lot of panic as everyone else scrambles to learn in far too little time what you have fortuitously chosen to allocate more time towards), and I do keep notice of such things.

so cat session-201211020309.raw | bgrep '.. .. .. .. 00 15'

would be looking at the lower half for the packet.

Chris,

Technically, you are only looking for a 6 byte sequence where 00 15 are the last two bytes.

There's nothing to guarantee that the matches actually conform to a valid packet (you'd have to search for the valid starting bytes, at the very least).

It gives me three options. Should there be only one that returns?

It will give you the number of valid matches it finds, of which there are 3 in that particular session file for that pattern.

There's nothing really stopping multiple sessions from occurring within a single file, so no, I'd say it isn't unreasonable to see a situation with more than one such match, however: as I said in an earlier e-mail, there are no “session_end” events that occur in that file (nor some of the others I have checked).. and that's because session_end is not the only (nor the definitive) way to indicate a session session has finished (it is merely one way, and one that apparently doesn't show up within reasonable amounts of time when finished).

but if I look at the three options it returns I think I can get ride of
the first two. the first one has 05 before the the 00 15 wich i would
interperut to session start and the second has which would indicate
headset engaged.

Your line probably got you these results:

1d9c7:a0 0f 80 05 00 15 12310c:50 17 70 0f 00 15 2217d0:40 0d c0 0b 00 15

If you're aiming for the second half of the packet, you're banking on 00 (the data type field) being an event, which means the following byte (15) would be the event type, which is “session_end”.

The byte before the data type is the sequence number (for the given slice), of which that would be 5 (sequence number 5)… a 'session_start' event would have looked like: 00 05 (it would have taken the place of the 15).

Each byte has a specific role it plays in the organization of the data packet.

Also, as I said, none of these are valid packets, because I saw no session_end events take place in this file. You'd want to improve your pattern to better identify valid packets (your previous attempt, before you understood what the '.' did, was considerably closer), and also remember: what byte sequence denotes the start of a valid data packet? You'll want to incorporate those into your pattern to get the best results.

The third has ob which doens't seem to have any specific meaning. I would
assume that I would pull that packet and start analizing it and would think that it would have time stamp and all that. Just by the quick look
i took at that packet it appears to me that would be so. It has alot more
bytes in it to included time stamp and etc. Am I getting closer now?

In that you are starting to reason and analyze the data you are seeing, yes… as I said, focus on getting it to match valid packets (from their start clear through to where you are interested), and bgrep will act as a natural filter for you, excluding things that are not valid matches.

cat session-201211020309.raw | bgrep '41 34 .. .. .. .. .. .. .. .. .. 00

07'

Which would give you:

68242:41 34 07 06 00 f9 ff bc 74 00 82 00 07

from the start of a packed give me the event of sleep start.

Yes. Although, you don't quite have the entire packet. I'll tell you more below…

which appear to be a vaild packet because byte 4 and 5 (06 00) are inverts
of bytes 6 and 7 (f9 ff).

Yep- check 1 cleared.

Check 2 is the checksum, your second test of a valid packet… it is the sum of the datatype byte (byte #12) along with the sum of each of the bytes making up the data block (bytes #13-whatever).

The total length of the data block can be calculated via the msglen bytes, bytes 4 and 5… when we look we have 06 00, but as they are in little endian order, we rearrange them as we'd expect to read a number, and get: 00 06

So, the data type + data block bytes span a total of 6 bytes. We know that the data type is 1 byte, which means the data block is 5 bytes in length.

The 07 is merely one of five bytes (or, there are four additional bytes following the 07)… The 07 is merely the lowest-order byte in the 5 byte sequence (once again, little endian). Also, before we forget, to get the checksum, add up the data type byte plus the 5 datablock bytes: 00+07+00+00+00+00 = 07 … we see this matches byte #3, so the packet checks out as valid.

So, armed with the knowledge of the msglen, we can adjust the search pattern appropriately, and get the full packet displayed:

cat session-201211020309.raw | bgrep '41 34 .. .. .. .. .. .. .. .. .. 00 07 .. .. .. ..' 68248:41 34 07 06 00 f9 ff bc 74 00 82 00 07 00 00 00 00

If we want to do an extra check, we could add on yet two more bytes (if the packet is done, we should see the start of the next packet– ie a 41 followed by a 34):

cat session-201211020309.raw | bgrep '41 34 .. .. .. .. .. .. .. .. .. 00 07 .. .. .. .. .. ..' 6824a:41 34 07 06 00 f9 ff bc 74 00 82 00 07 00 00 00 00 41 34

And we do… so, the pattern you had with just 4 additional bytes is what you need to display that packet in its totality (note the msglen will change depending on what type of packet it is).

Plus, for this file, we can also reliably say there is only one 'sleep start' event.

so that seems to me like I should pull that one out and it would tell me
lots more when i start to decode it.

Actually, that's pretty much it for that packet. What is of interest, though, is once you have identified that packet, you're now more interested in other packets in the general neighborhood: there will likely be a timestamp packet nearby, along with sleep state packets…

Still pretty clueless to find the stopping point though.

I can think of three things that would be a pretty defining indication of the end of the session:

  1. headset_disengaged (if the user takes the headband off, no more data

can be recorded)

  2. sleep stage is conscious following a state of actual sleep
  3. the session file ends

(Also possibilities: when conscious, the brain will be in an alpha or beta state, which is also being reported; when moving about, the signal quality may suddenly start changing)

None are downright guarantees, but that's the strategy we often have to take when interacting with the real world and data acquisition. More than likely, these events, if all present, will be in close proximity to one another (all near the end of the file).

It seems that the more pertaint problem is to figure out the time stamp.

Did I miss something about that beacuase the only thing I see for help on
that part is that the 7th byte is the time stamp. Not seeing how this
makes sense… We know from the file name the date and time you began,
but how with one byte of data can we extract all that exact information?

Chris,

The byte you refer to would correspond to the lowest-order byte of the overall time (a 32-bit value storing the number of seconds since “the start of time/the epoch”)… as only a byte, byte #7 would only be useful for a maximum of 256 seconds (~4.2 minutes).

And while the file name does contain pertinent information, all that (and more) can be found within the file itself… there are data packets containing full time stamps (data type of 0x8a), which can be used to extract more precise information (especially once you get beyond the 4.2 minute mark, of which all of those files are longer than in duration).

ahha, think I have an educated guess now thanks to google, would it
perhaps be 188 seconds from the start of the recording?

More like 188 seconds out of 256 seconds (at which point, 255+1 = 0, we'd have an odometer-like roll-over because a byte can only store 8-bits). It isn't aligned with the start of the session (although it could conceivably happen accidentally), it is more the state of the system clock when the session was taking place.

But some good exploration and reasoning.

well actually that doesn't make since either because the higest with the

two digits would be ff. Which latter on in the file they do all turn to ff
but that remains constant so I've looked ahead some. but unix time is a
32 bit number but which ones? A clue in the objectives section date(1), no
apprent help that I can figure.

Chris,

Yes, UNIX time is stored in a 32-bit value, where each unique value is reflecting a quantity of seconds since the start of the UNIX epoch.

The date command can offer some help… here I will show you how we can retrieve the current time:

  $ date +%s
  1427113003

I ran this just a few minutes ago (Monday, March 23rd, sometime after 8:10am), and got that value.. it is in decimal.

Let's take a look at it in hex:

  echo "obase=16; 1427113003" | bc

which would give us:

  5510042B   ->  55 10 04 2B

2B is the least significant (lowest-order) byte… where the “1s place” would be… this is the same byte value we'd see in byte #7 (the lowest-order byte of the current unix time at the time of session recording).

If we were to run and convert the date to hex exactly one second later, we'd have:

  55 10 04 2C

Notice how the 2B changed to a 2C? That is because 1 second went by, so time incremented by one. A data packet taking place 1 second later in a session file would also have reflected an increment (comparing byte #7)… but again, as that byte can really only track a duration of ~4.2 minutes, it is not useful for longer durations of time… that's what the entire timestamp is needed for (and that is why there are specific timestamp packets).

With the entire timestamp, we can convert it back to an actual calendar+clock time (March 23rd, 2015 8:12:36am, etc.), which a command like date can assist with (not that there aren't other ways to go about it).

It would be on a new packet corret? I would use bgrep '41 34…..' and
adjust as I decide how to search for it. Make sense to me just checking
my logic I guess.

What would? The next 41 34… ? Yes, they would be indicative of the start of an entirely new packet.

so started to look at a nap session like you suggested in class but now

i'm stuck at finding the start of sleep

cat session-201301041418.raw | bgrep '41 34 .. .. .. .. .. .. .. .. .. 00
07'

gives me no results?

Chris,

It would appear that there are no specific sleep_start event in that data file. Maybe there was a patch of invalid/bad signals or low signal strength… who knows.

If I take of lets say the last byte to verify that it works, it does. It
give me three one of which is headset engaged and one is headseat
disengaged not sure of the third but wouldn't that be the pattern to in
fact find the start of sleep?

348:41 34 0f 06 00 f9 ff e5 20 00 84 00 0f ←- event (00), headset engaged (0f) f391:41 34 05 06 00 f9 ff 8b 16 00 29 00 05 ←- event (00), session start (05) 57982:41 34 0e 06 00 f9 ff 87 58 00 58 00 0e ←- event (00), headset disengaged (0e)

It is certainly not unreasonable to expect to find a sleep_start event taking place after indications that the session has started, which in and of itself wouldn't be recorded if the headset wasn't in use.

unless there is no sleep in that session is the only thing I can think of.
I guess I'm going to go back to the original file I was working on for now

Also a possibility, but as I hinted at, could have just been a lost packet due to noise.

Just as with session ending, there are multiple approaches to evaluating the start of a session (or sleep)… for one, does the sleep state EVER change from undefined or conscious?

It could have been one of those flukey sessions where the headband wasn't on properly, or fell off.

I tried looking at the regular grep page to try and answer my question but

didn't really see what I was looking for. Is there away when using bgrep
to make it just show a page at a time?

Chris,

Well, that is neither a feature grep nor bgrep innately have (nor should have).

If you want to stop output per page, you'd want to use a pager: more or less are good choices…. head and tail may also be of occasional value.

  cat thing | bgrep stuff | more

> What I did on the first session was found the start of sleep

bgrep '41 34 .. .. .. .. .. .. .. .. .. 00 07' looked at whole packet
after that to verify that it in fact was a good packet, which we confirmed
earlier it was.

gave me the address of 68242. So I need to find a packet with a time
stamp as close as possible to that so I ran

bgrep '41 34 .. 05 00 fa ff.. .. .. .. 8a .. .. .. ..' then looked for the
closest one next to 68242 that was a good packet took the last 4 bytes
invereted them because of little endian and came up with 509341bc
converted to decimal and got 135182790 then I ran

date -d@1351827900

which gave me Thu Nov 1 23:45:00 EDT 2012
seems to fit really close to what it should be.

Most excellent. You're definitely getting the grasp of things and are making some excellent investigative steps (exactly what I wanted to see).

I was then going to find the trigger for the end of sleep do the same
thing subtract the times to find the total sleep time. Would this be the
most productive lazy approach or am I missing something?

I'd certainly think so.

You could possibly make a mild enhancement with the use of regular grep to search for nearby addresses that conform to the desired address (within some reason):

  cat session | bgrep 'pattern' | grep '^startofaddr'
  
  We are to find the time the total time that you slept for each session,

> that would be sleep not conscious state correct? I hope I'm looking

deeper into this than I should be, it's gonna be a lot of calculations
and extractions if so.

apears to be all vaild packets with both checks and start of new packet at
right time and all conscious state.

lab46:~/src/unix/projects/udr2$ cat session-201211020309.raw | bgrep '41
34 .. .. .. .. .. .. .. .. .. 00 0e .. .. .. .. .. ..'
58174d:41 34 0e 06 00 f9 ff 6f 04 00 1f 00 0e 00 00 00 00 41 34

looks like the end of session and the begining was like 64282 or
something. that's 19 different conscious state packets?

Yes– a sleep state packet can be generated probably every 30 seconds… so if I were to have lay down and was awake for 2 minutes before falling asleep, that would mean 4 'conscious' sleep state packets.

19 would mean there were about 19 minutes of being conscious.

In general, for total sleep, once you mark the start of sleep (ie non-conscious) and the end, I wouldn't worry about any blips of consciousness in the middle… sometimes we briefly wake up in the middle of the night (2-3 minutes at a time) at the end of a sleep cycle. Especially at such an early date as that (early Nov 2012), so that sleep will likely more closely resemble what everyone usually experiences.

On 3/25/15 07:43 PM, Christopher M. Booth wrote:

well I thought that maybe that would be a time of no sleep but there is
def rem sleep mixed in when there is conscious state is going on. I know
that it could be just a roll or a movement but there is no way for me to
know that I just have to take what the data shows and that's alot of
calculations.

Chris,

Yeah, like I said- don't worry about blips… basically, find the first actual sleep (light, REM, deep), and the last (light, REM, deep), and just compute the duration between those two points… 19 conscious sleepstate packets is around 9 minutes of consciousness, and I suspect most of that will be at the beginning and the end… anything in the middle will not skew the results that greatly (I won't be looking for spot-on exactness).

Well, seeing it has been extended until after break, that's certainly no problem :)

Two final questions, 1) why are some of my times est and edt, 2 the
session name has the correct start of time right? because the ones I
figured out are a few hours off. Just checking before I went back and
re-did all my work.

My guess: the timestamp is just in seconds, an absolute count from the start of time.

But, we have a history of monkeying with how we interpret time… time zones, and then a bi-annual hour-shifting “Daylight Saving Time”… I suspect you'll see that when crossing some threshold in March, when we've been turning the clocks back.

Ultimately, if you're off by an 1, 4, or 5 hours, that is nothing to worry about.

Why 1? Daylight Saving Time being in effect (or not– I forget how I had the device set, and I rarely change my clocks when such events come about).

Why 4? UTC (we're four hours… ahead?) Sometimes time may manifest like this.. but again, it is a constant offness.

Why 5? UTC with Daylight Saving Time (or is 4 UTC with daylight saving time).

At any rate… being “off” by 1, 4, or 5 would be perfectly reasonable, because you are extracting time data (whose clock could ultimately have been set to any of these), and you are comparing that time to the current time zone as set on Lab46. It isn't in error, just more of differently set clocks.

So continuing that logic, to find where the session ended wouldn't it be

cat session-201211020309.raw | bgrep '00 15'

Chris,

In an ideal world where everything always worked the way it should and nothing was ever missed (no power outages, no signal losses, no user error, no post-processing), yes, that could be a way. But: citing reality, it is by no means the only way.

A “session” is basically when I started saving the device output to a file, and stopped when I interrupted it. There's a chance the headset could have already been picked up or replaced by the time this happened, so the session may not even provide the expected “I think a session is starting”-type packets (and/or their counterparts at the end).

Now, what I think you're after here is the “session_end” (0x15) event (0x00).

When you ran that line, you likely saw the 387 matches generated in that file. However, it would appear (at least in that file) that there are NO packets with session_end events in them… which is a perfect example of needing to be mindful of the whole data packet.

00 15 are of particular value only when the 00 is aligned with the data type byte of the packet (the 12th byte of the packet), and 15 is immediately following that (as the 13th byte). If the typical packet start bytes are not there, and if other things do not check out (mismatched msg_len with its inverted inverse, or the checksum doesn't compute properly) then it cannot be validated as a correct packet. 00 15 clearly occur in other places (387 other times, in would seem), but as none of them appear to line up with a specific session_end packet, they are just other pieces of data.

Results

Commands used are at bottome of document

session-201211020309.raw

1) Total packets 126778 2) Total time 5 hr 36 min 3) Total time slept 3 hr 45 min 4) 1351841070

 fri nov 2 03:24:30 edt 2012

session-201301041418.raw

1) Total packets 7488 2) Total time 16 min 3) Total time slept 12 min 4) 1357313191

 1/4/13 10:26:31

session-201301311909.raw

1) Total Pakets 102710 2) Total time 8 hr 6 min 3) Total time slept 3 hr 26 min Thurs Jan 31 15:16:01 est 2013 1359663361 session-201302010218.raw

1) Total packets 56818 2) Total time 5 hr 35 min 3) Total sleep time 1 hr 15 min Thurs Jan 31 22:25:00 est 2013 1359689100

session-201302200614.raw

1) Total Packets 10876 2) Total Time 1 hr 35 min 3) Total time slept 12 min Wed feb 20 02:20:00 est 2013 51247920

session-201303051015.raw

1) Total Packets 10578 2) Total time 4 hr 2 min 3) Total time slept 22 min tues Mar 5 06:19:41 est 2013 1362482381

session-201301311909.raw Had the most deep sleep cat 3 | bgrep '41 34 .. .. .. .. .. .. .. .. .. 9d 04 .. .. .. ..' cat 3 | bgrep '41 34 .. .. .. .. .. .. .. .. ..$ It had the most deep sleep packets by double the others it had about 3 hr 25 min from 15:16 to 18:41 on jan 31

Commands used to get the information needed

1) cat file-name | bgrep '41 34' | wc -l 2) cat file-name | bgrep '41 34 .. .. .. .. .. .. .. .. .. 9d .. .. .. .. ..' | more

      Use this to find the start of sleep then last
      once you get the address of when sleep starts find datestamp cloest to them when running the command for t$

3) cat file-name | bgrep '41 34 .. .. .. .. .. .. .. .. .. 8a .. .. .. .. ..' | more use this to find the first time stamp and the last and closest to you start and stop of sleep 4) use your favorite hex to dec converter to get the decimal number, use date -d@########## to get the date and ti$

Had some very difficult challenges using dd to get it to do the right thing.

-rw-r–r– 1 cb007748 lab46 51912 Mar 14 15:25 file This appears to be the reversed file (the second part).

-rw-r–r– 1 cb007748 lab46 203 Mar 15 13:52
udr2.txt

And this the first part. Okay…

I did notice mistakes in my bash script, think I have
fixed it still without appending, it is as follows:

for¹⁾; do
dd if=udr2.txt of=udr1.txt bs=1 count=1 skip=$i
done

You might want to back everything back a value (since things start at 0, the 203rd byte will actually be #202):

  for((i=202; i>=0; i--)); do

Now… you are extracting a byte at a time from udr2.txt… right now each byte is being stored in udr1.txt before it gets overwritten by the next byte.

So we have access to each byte.

What if we were to take that byte, after each dd extraction, and add it to a results file of some sort?

      cat udr1.txt >> results

What impact might that have, or problem that would mitigate, that is currently being experienced?

Sorry I sent all those messages last night I just got

all your emails I wasn't ignoring what you said.

No problem, I was just noticing a theme worth focusing on…

So I'm trying my script on the first file we pulled
form the data.file before I try to do the second big
one.

If I'm reading you right: you've already pulled udr1.text out of data.file? Or you are looking to write a script that pulls udr1.txt out of data.file?

Also: I see no information of any value at offset 1624, in data.file… there are only zeros to speak of in that neighborhood.

And if you've already extracted udr1.text, 1624 bytes is off, by a factor of 8 (the embedded text indicates how big udr1.text will be) – again, as far as I've been able to determine.

so to get them with no script would be as follows but
it would not still append the the file it would just

so the last byte i pulled.

dd if=udr2.txt of=udr1.txt bs=1 skip=1623 count=1
dd if=udr2.txt of=udr1.txt bs=1 skip=1622 count=1
dd if=udr2.txt of=udr1.txt bs=1 skip=1621 count=1
dd if=udr2.txt of=udr1.txt bs=1 skip=1620 count=1

So, what other step could be added to handle the append you are seeking to do? As in- keep what you have, add additional line(s) to accomplish the task.

!/bin/bash

for²⁾; do
# echo “Iteration $i”
dd if=gizmo1 bs=1 count=1 skip=$i » gizmo
done

So I thought changing the i>0 to i=0 but that didn't
work…

Chris,

VERY close:

  i>=0

I thought I had it but I'm one byte short.

!/bin/bash

for³⁾; do
# echo “Iteration $i”
dd if=gizmo1 bs=1 count=1 skip=$i » gizmo

Also, dd may produce additional (status) output that may get in the way of your resulting file being a proper reversal… you may want to break it up:

  dd if=gizmo1 of=out bs=1 count=1 skip=$i
  cat out >> gizmo

My script ending up being

#!/bin/bash

for⁴⁾; do # echo “Iteration $i” dd if=gizmo1 bs=1 count=1 skip=$i » gizmo

  done

lab46.corning-cc.edu/~cb007748/unix/udr0.meme0531.png TACOCAT IS A PALINDROME take the original memdump.ram and either use the string command or hexedit to find t$ once you find the table of contents take all the values and convert them to decimal. toc-part2:0x1800,204240;part10x13ca0,110350;part3:0x1e188,104440 so extract the 3 parts using dd dd bs=1 skip=81056 count=37096 if=memdump.ram of=part1 dd bs=1 skip=6144 count=67744 if=memdump.ram of=part2 dd bs=1 skip=123272 count=35104 if=memdump.ram of=part2

you find out part1 is compressed file mv part1 part1.xz unxz part1

uudecode part2

cat part1 part2 part3 > meme0531

you find out meme0531 is a .rle file

mv meme0531 meme0531.rle

convert meme0531.rle meme531.ppm

then you need to resize

pnmscale 2 meme531.ppm meme0531.ppm

then use netpbm to change it to a png

cp meme0531.png ~/public_html/unix/udr0/meme0531.png

Name dd - convert and copy a file Synopsis dd [OPERAND]… dd OPTION Description

Copy a file, converting and formatting according to the operands.

bs=BYTES

  read and write BYTES bytes at a time (also see ibs=,obs=) 

cbs=BYTES

  convert BYTES bytes at a time 

conv=CONVS

  convert the file as per the comma separated symbol list 

count=BLOCKS

  copy only BLOCKS input blocks 

ibs=BYTES

  read BYTES bytes at a time (default: 512) 

if=FILE

  read from FILE instead of stdin 

iflag=FLAGS

  read as per the comma separated symbol list 

obs=BYTES

  write BYTES bytes at a time (default: 512) 

of=FILE

  write to FILE instead of stdout 

oflag=FLAGS

  write as per the comma separated symbol list 

seek=BLOCKS

  skip BLOCKS obs-sized blocks at start of output 

skip=BLOCKS

  skip BLOCKS ibs-sized blocks at start of input 

status=noxfer

  suppress transfer statistics

BLOCKS and BYTES may be followed by the following multiplicative suffixes: c =1, w =2, b =512, kB =1000, K =1024, MB =1000*1000, M =1024*1024, xM =M GB =1000*1000*1000, G =1024*1024*1024, and so on for T, P, E, Z, Y.

Each CONV symbol may be:

ascii

  from EBCDIC to ASCII 

ebcdic

  from ASCII to EBCDIC 

ibm

  from ASCII to alternate EBCDIC 

block

  pad newline-terminated records with spaces to cbs-size 

unblock

  replace trailing spaces in cbs-size records with newline 

lcase

  change upper case to lower case 

nocreat

  do not create the output file 

excl

  fail if the output file already exists 

notrunc

  do not truncate the output file 

ucase

  change lower case to upper case 

swab

  swap every pair of input bytes 

noerror

  continue after read errors 

sync

  pad every input block with NULs to ibs-size; when used with block or unblock, pad with spaces rather than NULs 

fdatasync

  physically write output file data before finishing 

fsync

  likewise, but also write metadata

Each FLAG symbol may be:

append

  append mode (makes sense only for output; conv=notrunc suggested) 

direct

  use direct I/O for data 

directory

  fail unless a directory 

dsync

  use synchronized I/O for data 

sync

  likewise, but also for metadata 

fullblock

  accumulate full blocks of input (iflag only) 

nonblock

  use non-blocking I/O 

noatime

  do not update access time 

noctty

  do not assign controlling terminal from file 

nofollow

  do not follow symlinks

Sending a USR1 signal to a running 'dd' process makes it print I/O statistics to standard error and then resume copying.

CW$ dd if=/dev/zero of=/dev/null& pid=$!

  CW$ kill -USR1 $pid; sleep 1; kill $pid 

18335302+0 records in

  18335302+0 records out 9387674624 bytes (9.4 GB) copied, 34.6279 seconds, 271 MB/s

Options are:

–help

  display this help and exit 

–version

  output version information and exit

Author Written by Paul Rubin, David MacKenzie, and Stuart Kemp.

find and locate the next puzzel box and copy it to your home folder to begin the wonderful joy of unraveling the mystery that lies with in.

vi the file to find the password for the first two is 1337 or something like that lol then you can get out a couple of the files

Puzzle Box Project

Find and copy riddle.html to home dir

/var/public/unix/spring2015/pbx0

cp riddle.html ~/src/unix/projects/puzzelbox/

file riddle.html

you find it's previous name was shiny.tar

mv riddle.html shiny.tar

tar xf shiny.tar

then do the following command to uncode

uudecode making.waves

then unzip it

unzip leaf_on_the_wind.wav

nano new file and remove the first line

then echo base64 -d test » results

and follow the directions

arc0

to find file archive.tar.xz

cd /var/public/UNIX/spring2015/arc0

You need to make a dir in you homepage to store the file. I used the suggeste ~/src/unix/projects/arc0

once you create your dir using the mkdir command go to the location of the file mention above.

Once in the proper locaction issue the following command

cp archive.tar.xz ~/src/unix/projects/arc0/

you can do a ls once you get back into that dir to verify

cd ~/src/unix/projects/arc0/ ls -l

you need to decompress the file with the following command xz -d archive.tar.xz

then you need to extract the files using the following command tar xf archive.tar

next use bing to solve the riddles Pips 3 Loneliest number 1 Compass 4 Moons 2

Then you need to rename the files with the corresponding number using the mv command. If you start your command and instead of typing the whole file name out you can highlight in then left click and it will put the file name in the cli for you.

tar -cvr myarchive1.tar test1 test2 test4 test4

to compress with gzip

gzip myarchive1.tar

changes file name to myarchive1.tar.gz

zip all files

to submit submit unix arc0 myarchive1.tar.gz myarchive2.zip

logged into email and sent first email using pine.

Downloaded putty and installed

For the hostname used lab46.corning-cc.edu

started pine by typing pine at prompt

Typed my password in and promted to save password

Hit c to compose massage

Typed email addresse and subjet, then typed in my message.

When it was complete and ready to send hit ^x (ctrl x)

then hit q to close y for yes

This is a sample format for a dated entry. Please substitute the actual date for “Month Day, Year”, and duplicate the level 4 heading to make additional entries.

As an aid, feel free to use the following questions to help you generate content for your entries:

• What action or concept of significance, as related to the course, did you experience on this date?
• Why was this significant?
• What concepts are you dealing with that may not make perfect sense?
• What challenges are you facing with respect to the course?