How to Create Service Files with Systemd

Firstly let me start by giving credit to Lucid for their guide on Evilzone which inspired this idea, as well as the recent talk of anonymity on here.

As the Archwiki states:

Systemd is a system and service manager for Linux, compatible with SysV and LSB init scripts. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons , keeps track of processes using Linux control groups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic.

Today we will:

• Create a systemd .service file
• Create a bash script tampering with a file

Systemd service files are found in either /lib/systemd/system or symbolic linked from /etc/systemd/system. The template we will be using for the service file today is;

Allow Me to Explain

Description=Entering Time Machine

The description is what will be displayed during boot, feel free to change this to whatever you prefer.

After=logRuin@user.service

Here we are telling the script to run after the logRuin service has exited. We could also use Before=logRuin@user.service if we wanted.

Edit: Note this service file was one I created last night and therefore will not be available to yourself. Use systemctl to find a pre-existing service to where it would make sense to initiate this file.

Type=simple

Simple services are considered to start up immediately, and is this by default. We could use Type=fork for daemons if your service required it. I would suggest reading the man page for systemd.unit for all options regarding systemd, as well as the archwiki page linked above.

ExecStart=/bin/sh /root/Desktop/Boot/timeMachine.sh

We are declaring here that the script to be used will be a /bin/bash script, followed by providing a link to where the system should search for it. In this case the script is on my desktop inside the Boot folder.

WantedBy=default.target

default.target controls where we boot into by default. I'm certain using default.target for service files would be considered bad practice. Here we should specify which service requires your .service file. This then creates a symbolic link in the .wants/ directory.

The Process

Firstly, we will be creating a file suitable for testing our script against, so that we can test it before executing on start-up. I found a tutorial Here which lead me to this command.

/dev/urandom provides pseudo-random output. /dev/random would have probably been cryptographically better for us if we were say; overwriting large files with the dd command as /dev/urandom does not block waiting for more entropy.

This will output 10 lines of 15 pseudo-random charactors 'a-zA-Z' into a file named pseudo.txt in the documents directory.

Using the stat command, we can view information regarding a file which can be used later in digital forensics. The Blocks and Inode refer to the location of the file on the hard drive, as well as the user account, and three dates;

• Access
• Modify
• Change

Looking into the touch command previously for date modification and noticed that when you touch a file with a specified date and time using the -t flag; the Access and Modify date change, but the Change date is still present.

Wondering how to bypass this feature, this article explains that you should change the system time to the imposing time, touch the file, then restore the system time. This is where our bash script comes in. Save this as timeMachine.sh

The #! /bin/bash is indicating which interpreter to run on, in our case; bash/

Line 3 is using the date command to set the system date to the 1st Jan 2000 at 1pm.

Line 4 touches the document with the current (imposed) time

Line 5 uses the Hardware clock to restore the system date/time

Line 7 waits for user input. This line WILL be removed prior to placing it in the systemd directory later. Im not certain what will happen if the system is waiting for user input like that during boot, and do not wish to try it out at this time.

You should run the script at this point to ensure it works as expected prior to setting it up as a service. Now we can do another stat of the file. Notice the Change time is now set to 1st Jan 2000

The Service File

Now we have everything in place, lets begin. First, remember to REMOVE line 7 from the bash script we created. Next, move the .service file to /etc/systemd/system using the following command

chmod the .service file to provide executable permissions, I believe chmod 644 would be suffice but for this example 755 is being used.

Our service is in the correct location with executable permissions. All that is left is to enable the service, informing the system to run it during boot up. Systemctl is used to introspect and control the state of systemd.

Running systemctl status informs us that our service is disabled and inactive (dead), which is no good for what we need. First we must enable our new service, this automatically creates the symbolic we spoke about earlier to the ./wants folder

Looking at our service status now, it is loaded and enabled, but remains inactive.

Running systemctl start will fix this problem. systemctl status once more so that we can see the script worked. It was given a process ID when it ran, so I am assuming that the service executes successfully and all the files are in now place.

All there is left to do is to touch the file once more, restoring it to system time to test our service. Reboot your machine and if all went well using stat on the file once more should display 1 Jan 2000 as presented below.

Now my question to the community;

Would something like this completely invalidate forensic evidence should they allow the system to boot? Say we truncated certain files/directories on start up before editing the date to a previous time, that surely would not be able to hold up in court?

If the forensic expert takes a md5 hash of the hard drive with the file times as they are here, even if there was some way to recover the previous Change time, that would change the final md5 Hash used in court, and therefore invalidating any evidence that may be held. Possibly claiming corruption of disk?

If this is the case, as forensic experts could we view the hardware clock or force the hardware clock time stamp onto a file so that something as simple as this cannot work?

I hope we have scraped the surface of service files and have had a little bit of fun using the touch command along the way. As always there is much much more to systemd than we are able to show here, but hopefully this should give you a rough idea of how we can use it to make us more efficient at our jobs in the field.

Thanks for reading

Spawn