Mdthbs

I'm working on a public server, which offers games designed to help teach people Linux and ethical hacking skills. The goal of each level (so far) has been to find the ssh password to the following level w/ various commands suggested as possibly being useful in accomplishing this task. I'm currently working on a level, which listed the following as the goal:

The password for the next level is stored in a file somewhere under the 

inhere directory and has all of the following properties:

     human-readable

     1033 bytes in size

     not executable

The suggested commands are: ls, cd, cat, file, du, find

I read the man pages for each command, and I also searched online for help. I found two separate questions/answers on Unix & Linux StackExchange pertaining to this exact exercise. These can be found here and here. Both sets of commands output essentially the same information. For instance, from the first link, the accepted answer and output was:

bandit5@bandit:~/inhere$ find . -type f -size 1033c ! -executable -exec file {} + | grep ASCII                          

./maybehere07/.file2: ASCII text, with very long lines

I decided to play w/ this command a bit, so first, I removed grep from the command, then ran it again. I then removed the non-executable switch and the file command and ran it again.

bandit5@bandit:~/inhere$ find . -type f -size 1033c ! -executable -exec file {} +                                       

./maybehere07/.file2: ASCII text, with very long lines



bandit5@bandit:~/inhere$ find . -type f -size 1033c                                                                     

./maybehere07/.file2

As is plain to see, the shortest version of this command returns the exact information I was searching for. The second link above from Unix & Linux StackExchange is an even longer and more exacting command returning the same information as the shortest version of the command above.

I realize that I shouldn't be creating more work for myself, so the shortest command would probably be the best in this case. I also realize that this server is most likely designed in a way to not confuse issues. Therefore, my question is, is there a time when these longer commands might prove useful to retrieve output in a similar situation? Would these longer commands help to narrow down the sought after answer, while parsing out output that the shorter command might not? An example would be greatly appreciated. Thank you very much!

To answer your question (despite the downvote) yes this is just because the person who first wrote that command was trying to use all the information available to them. The question states that the file is human-readable, 1033 bytes in size, and not executable. The original command was:

find . -type f -size 1033c ! -executable -exec file {} + | grep ASCII

So lets break this down into parts:

-type f means you're looking for a file (as opposed to a directory).

-size 1033c means you're looking for a file that is 1033 bytes.

! -executable means you are looking for a file that is not executable.

-exec file {} + means you want to execute the file command on each file found by find.

| grep ASCII here you're piping the output of the previous command into grep to search for only lines containing ASCII.

I've created 3 files that are each 1033 bytes, file1 is binary data, file2 is the file you're looking for and file3 is a copy of file1 but is marked as executable. In this directory here's the output of your suggested commands:

jon@jon-HP-Pavilion-15-Notebook-PC:~/temp$ find . -type f -size 1033c ! -executable -exec file {} + | grep ASCII

./file2: ASCII text, with very long lines

jon@jon-HP-Pavilion-15-Notebook-PC:~/temp$ find . -type f -size 1033c ! -executable -exec file {} +

./file2: ASCII text, with very long lines

./file1: data

jon@jon-HP-Pavilion-15-Notebook-PC:~/temp$ find . -type f -size 1033c

./file2

./file1

./file3

As you can see with multiple files these commands behave very differently, the reason they seem the same in your test environment is because there is only one file that is 1033bytes (which to be fair is probably also the case in reality, but then again in reality you often don't know the exact size of a file).