Hack Like a Pro: Linux Basics for the Aspiring Hacker, Part 19 (Linking Files)

Linux Basics for the Aspiring Hacker, Part 19 (Linking Files)

Hack Like a Pro: Linux Basics for the Aspiring Hacker, Part 19 (Linking Files)

Welcome back, my aspiring hackers!

As you have probably discovered by now, the file system in Linux is structured differently from Windows. There are no physical drives—just a logical file system tree with root at the top (yes, I know, roots should be at the bottom, but this is an upside-down tree).

In addition, filenames are often very long and complex with lots of dashes (-), dots (.), and numbers in their names. This can make typing them difficult for those of us with limited keyboard skills (remember, you can always use the tab key to autocomplete if you are in the right directory).

Sometimes we want to simplify the names of a file or we want to link a file in one directory with another in a separate directory. Linux has at least two ways to do this—symbolic (or soft) links and hard links. To understand how these two work and how they are different, we need to delve into some basic background on the Linux file system's internal structure.

Linux File Structure

We know that the Linux file system hierarchical structure is different than the Windows hierarchical structure, but from the inside, Linux's ext2 or ext3 file system is very different from Windows NTFS. Linux stores files at a structural level in three main sections:

  • The Superblock
  • The Inode Table
  • Data Blocks

Let's take brief look at each of these.

Superblocks

The superblock is the section that contains the information about the file system, in general. This includes such things as the number of inodes and data blocks as well as how much data is in each file. It's kind of a overseer and housekeeper of the file system.

Inode Table

The inode table contains several inodes (information nodes) that describe a file or directory in the file system. Essentally, it is simply a record that describes a file (or directory) with all its critical information such as date created, location, date modified, permissions, and ownership. It does not, however, contain the data in the file.

It's important to understand from a forensic perspective that when a file is deleted, only the inode is removed.

Data Blocks

Data blocks are where the data that is in the file is stored, as well as the file name. Now with that understanding, let's introduce two ways of linking files, the hard link and the soft or symbolic link.

Hard Links

Hard linked files are identical. They have the same size and the same inode. When one hard linked file is modified or changed, it's linked file changes as well. You can hard link a file as many times as you need, but the link cannot cross file systems. They must be on the same file system as they share an inode.

Soft or Symbolic Links

Symbolic or soft links are different from hard links in that they do not share the same inode. A symbolic link is simply a pointer to the other file, similar to links in Windows, and they have different file sizes too. Unlike hard links, symbolic links do NOT need to be on the same file system.

Step 1: Viewing Links

Let's take a look at what links look like in our filesystem on Kali. Let's navigate to the /bin directory. Remember that the /bin directory is just below the root of the file system and contains most the commands that we use on a daily basis in Linux.

kali> cd /bin

Now, let's look at the files in the bin directory.

kali > ls -l

Notice that several files here show an arrow (->) pointing to another file. These are symbolic links. Also, note how small they are. Each is only 6 bytes. That's because they are only pointers, pointing to another file. The data block of the link simply contains the path to the file it is linked to.

When you edit the symbolically linked file, you are actually editing the target file as the symbolic file is only that path to the target file. Hope that makes sense.

Step 2: Creating Symbolic Links

Now, let's create some links. Let's start with symbolic links as they are probably the most common on most people's systems. Although symbolic links can be created anywhere, we will be creating them in the metasploit-framework directory to make starting the msfconsole a touch easier.

Move to the /usr/share/metasploit-framework directory, first.

kali > cd /usr/share/metasploit-console

Now, let's take a look at the this directory..

kali > ls -l

To create a symbolic or soft link, we use the ln (link) command with the -s switch (symbolic) and the name of the file we want to link to (the target) and the name of the link we want to create. You can use either relative paths or absolute paths to link the two files.

Usually, when we want to enter the Metasploit console, we type msfconsole, remember? Now, let's say we want to change it so that we can simply type metasploit to enter the console rather having to remember msfconsole. We can link a new file, metasploit, to the old file, msfconsole, so that whenever we type metasploit it links or redirects to msfconsole.

Here is how we would do that.

kali >ln -s msfconsole metasploit

Note how small the symbolic link file, metasploit, is. It's just 12 bytes, because it is only a pointer. A path to the file it is linked to.

Now, to get into the msfconsole, I can type either metasploit or msfconsole and both will take me to the same place—the Metasploit Framework console.

Step 3: Creating Hard Links

To create a hard link, the syntax is very similar with the exception that we use the ln (link) command without the -s (symbolic) switch, then the existing file to hard link to, and finally, the target file that will be created to the existing file.

Back to our msfconsole example, let's add a hard link between msfconsole to a simpler command, msf. We can do this by typing:

kali > ln msfconsole msf

As you can see above, now we have created a hard link called msf. Remember, hard links share an inode with the linked file, so they are exactly the same size. Notice that our new file, msf, is exactly the same size as msfconsole, 4103 bytes. Now, when we want to invoke (start) the msfconsole, we have the option to type metasploit, msf, and the original msfconsole. All will work equally well.

Cover images via Shutterstock (1, 2)

10 Comments

When I create these links and try them out I get the following errors(one each):
bash: metasploit: command not found
bash: msf: command not found

This happens no matter what directory I'm in.

What could be causing this? I have followed the tutorial correctly, and I actually already knew how to do this, but I don't get why the links don't work here. Typing msfconsole still works as normal

EDIT:

I realised that for some reason just typing 'metasploit' or 'msf' doesn't work, I have to type './metasploit' or './msf' AND be in the right directory for them to work... I still don't get how this is meant to work like OTW writes above.., any help much appreciated.

WILEY KAT :

This is happening because the link is not in your PATH(See the environment variables post). If the executable(or any other file) is not in your path you must provide it's path to shell . so by typing ./ you tell the shell that the link is in your current directory.

You could have also typed the full path to file ie . ./home/username/executable

So to use your link like Master OTW did you just add that directory in your path. In master otw's case the link must have already been in his PATH.

Sir OTW :

you said that whenever a file is deleted ONLY the inode is removed . that should mean that only the description of the file is removed.right ?

So , when is the data actually deleted ?

And what if i do cp oldfilename newfilename , this wouldn't be equivalent to ln oldfilename newfilename as they now don't share a common inode .right ?

By the way how & where can i take advantage of this shared inode , i mean what is the advantage of hard links ?
Thank You

Pranav:

The data remains until it is overwritten by another file. Copying the file (cp) makes two copies while ln (link) there is only one file with a pointer.

OTW

Hi, thanks for sharing !
So I followed the tutorial and I have a question.

Concerning hard linking, we create a pointer to an existing file so they have same size. But it's not a new file so the size of the directory we are in won't change at all (I used the "du" command to check for it).

We just add a new reference known as "msf" in Inode Table for msfconsole without changing Data Blocks content. Then the command "unlink" allows me to remove this hard link without removing the file it's linked to (msfconsole still working after that). My question is : if i type "rm msf", does it remove msf and msfconsole from Inode Table AND data related to msfconsole in Data Blocks ?

Edit: No big deal but in step 2 you wrote "cd /usr/share/metasploit-console" instead of "cd /usr/share/metasploit-framework" if I got this right !

A little late but i think he put the one /../../metasploit-console because it is different on some systems.

And to answer your question removing msf would not result in the loss of msfconsole as it's just a link.

Remember you may create practice directories and files to test things out on if you're unsure of things

Soft links: You may use them across file systems, They are only pointers to the file you are wanting (they only hold the path to a file, or directory or program) but it's all the same. IF you rename the original file or move the file your soft link will be broken, if you choose to rename it or move it through the soft link i don't think it would break.

Hard links: they copy the original file, even if you delete the original file AND still have the hard link you will still have access to that file. If you choose to edit, or move the original file that's linked to a hard link the hardlink will not be broken. You may not use hardlinks across file systems

When you delete the original file you do not delete the links, whether they're hard or soft links.

If i got anything wrong feel free to correct me

What's the use to know the hard link and soft link? Is anyway to delete both inode and data of a file?

Indeed there is. Check the following manual-page

man shred

The "shred" program, which is part of the GNU coreutils, which nearly all linux distros use, will overwrite a file 3 times (default setting) with pseudorandom data, which makes it extremely hard to recover any of it, even with expensive data forensics equipment.

(By setting the "-z" flag, shred does a last pass with all-zeroes, making it even hard to detect that a shredding took place)

Note that shred will not, by default, unlink (delete) the files it shreds, and it will leave their inode entries (filename, permissions) intact. One can either use rm for that job, or set the "-u" flag of shred, which is even more secure because shred now also overwrites the bytes in the inode entry.

Note that this may not work as expected on journaled file systems like ext3 if they are mounted in journal mode (which on most desktop systems they wont be but it doesn't hurt to check). One can consult the man-page for more information.

Warning: unwisely used, shred can quickly destroy a users data and/or make a system unusable. Usage of common sense at all times is required when working with powerful utilities such as this. You have been warned.

is file system means directories?

Share Your Thoughts

  • Hot
  • Latest