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:
for1); 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
for2); 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.
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
for4); 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: