.//`+++++++++++++++++++++++++++++++++++++// s
-+/.h+..................................-os s
-+/.h/                                   ss s
-+/.h/                                   ss s
-+/.h/                                   ss s
-+/.h/                                   ss s
-+/.h/                                   ss s
-+/.h/                                   ss s
-+/.h/                                   ss s
-+/.h/                                   ss s
-+/.h/                                   ss s
-+/.h/                                   ss s
-+/.h/                                   ss s
-+/.h+                                   ss s
-+/                            :-.: +:oo-   s
  s                        .::::/osso::::. .+
`.y                        +yyyyhNNNmyyyy+ .+
 .o                    s s::::::::::::s.+ - +
-/y     .o             s ::::::::::::oss+::.+
`-y     .o             y            `+//:  .+


In his book *Protocol*, Alexander Galloway describes a performance by Heath Bunting at the "Net - Art - World: Reception Strategies and Problems" conference in Berlin, 1998. Bunting came on stage to show a web page that was supposed to be accessible at www.castro.cu. While the audience waited for the page, and thus the art project, to be downloaded, Bunting continued to talk about other of his works. After a minute or two, an error appeared on the screen. Somewhat embarrassed, Bunting quickly typed another page under the domain into his browser and tried to gloss over the situation. The fact that Bunting appeared to have cooperation with the Cuban government attracted additional attention from the audience. But the second attempt to reach the site also failed and Bunting left the stage after a short summary of his presentation.

"What may not have been immediately clear to the audience", Galoway writes to enlighten the reader, "was that Bunting's presentation was in fact a performance. He deliberately attempted to load nonexistent Web pages – artworks that didn't exist at all – in a radical expression of solidarity with the network itself. No art object, Web page or otherwise, was necessary for Bunting. Letting the artwork disappear was the very means by wich the audience could experience the network protocols themselves."

Every day when we surf the Internet, we wait for something to finish loading, even though it's getting faster and faster now. Typically, it's about finally finishing the download and then starting the actual work or looking at the actual work. But what if, as just described, waiting for a download itself becomes a performative act?

Maybe Julian Oliver had something similar in mind when he came up with the idea of turning waiting for a download to finish into art itself.

His work Remote Install consists, to put it simply, (more on the details in a moment) of a program that is started on the day of the opening of an exhibition and begins to download "art". The download is specially timed so that the last bit is downloaded only in the last second of the exhibition. This means that the visitors never get to see the "finished", "complete" downloaded "art". Instead, they wait the whole time for the download.

Image from Julian Olivers Website, shows his installation

remote install (Image from here: here)

But Julian Oliver is also concerned with another aspect. On his website Oliver writes:

A remote install in the media-arts world refers to the artist not being physically present at the gallery during the installation process. Rather, they send a link to download the software and work with a local team to set it up on hardware already provided.

To make this as straightforward as possible, he has created a file that you can simply burn onto a USB stick, then plug into a computer and boot as an operating system.

The now started system then automatically logs into his server and starts downloading the art from a certain point. It also does other shenanigans with the local WLAN.

Let's take a closer look.

If someone doesn't know live Linux systems, I can definitely recommend to have a look at it.

You create a bootable USB stick and can use it to boot another system on a laptop or PC. If the hard disk is not encrypted, you can easily access the system's data and, for example, change your password (because you forgot it, of course) or read out all sorts of data such as browser history (because you forgot what that one cool page was, of course).

Browsing a Windows system from a Linux Live system I imagine it feels maybe a bit like cutting open an anesthetized patient and taking a look at the organs.

But there is another good way to try out systems easily and that is with so-called virtual machines. Then you can omit the USB stick and booting and just use two systems at the same time, one of them virtual. The actual operating system is the host and the virtual operating system is the guest.

I use VirtualBox in the following because it is very easy to install and use.

Now we can download Julian Oliver's ISO file and install it in VirtualBox. To do this, I first create a new virtual machine and then add the ISO file.

Screenshot of ISO installation in VirtualBox

VirtualBox interface & settings

Now let's start the VM and boot up the system.

boot up and failed login

Apparently we need a password which I don't know and did not find in the project description.

Fortunately, there are other ways to examine the ISO file. It contains the data that the system needs to work.

An ISO file is an image of a system, including all files that can be found there. This leads to the fact that we can easily mount the ISO file into the file system, much like a hard disk. For this purpose, the ISO file can be unpacked. In this case, a squashfs file will appear. This can now be mounted and then searched like a normal directory.

# ls
'[BOOT]'   install   isolinux   live   preseed
# mkdir /mnt/ri
# mount live/filesystem.squashfs /mnt/ri -t squashfs -o loop
# ls -la /mnt/ri
total 4
drwxr-xr-x 21 root root  443 Feb  9  2013 .
drwxr-xr-x  7 root root 4096 Apr 10 23:29 ..
drwxr-xr-x  2 root root 1459 Feb 10  2013 bin
drwxr-xr-x  2 root root  186 Feb 22  2013 boot
drwxr-xr-x  2 root root    3 Feb 22  2013 dev
drwxr-xr-x 81 root root 2650 Feb 22  2013 etc
drwxr-xr-x  4 root root   49 Feb 10  2013 home
lrwxrwxrwx  1 root root   28 Feb  9  2013 initrd.img -> boot/initrd.img-2.6.32-5-686
drwxr-xr-x 13 root root 3373 Feb 22  2013 lib
drwx------  2 root root    3 Feb  9  2013 lost+found
drwxr-xr-x  3 root root   28 Feb 22  2013 media
drwxr-xr-x  2 root root    3 Feb 22  2013 mnt
drwxr-xr-x  2 root root    3 Feb  9  2013 opt
drwxr-xr-x  2 root root    3 Feb 22  2013 proc
drwx------  5 root root  203 Feb 22  2013 root
drwxr-xr-x  2 root root 2175 Feb 17  2013 sbin
drwxr-xr-x  2 root root    3 Jul 21  2010 selinux
drwxr-xr-x  2 root root    3 Feb  9  2013 srv
drwxr-xr-x  2 root root    3 Feb 22  2013 sys
drwxrwxrwt  2 root root    3 Feb 22  2013 tmp
drwxr-xr-x 11 root root  187 Feb  9  2013 usr
drwxr-xr-x 13 root root  160 Feb  9  2013 var
lrwxrwxrwx  1 root root   25 Feb  9  2013 vmlinuz -> boot/vmlinuz-2.6.32-5-686

This means you can also simply search all subdirectories and files in them for specific words, such as the word "password".

grepping for password

This returns many results, all of which are unfortunately of no help (as far as I haven't missed anything)

Nevertheless, the passwords exist somewhere in the system, otherwise you could not log in. In Linux there are two files for this. One specifies the users of a system and the other stores their passwords. One is "/etc/passwd" and the other is "/etc/shadow". Even if it sounds strange at first sight, shadow is the one with the passwords.

But for security reasons, passwords are never stored in plain text nowadays. Instead, a so-called hash is generated. This is a mathematical calculation that transforms data into a sequence of numbers of the same length. This calculation only works in one direction. So a hash offers no conclusions about the original input. However, the same input always leads to the same hash.

Thus, it is possible to store passwords securely. Because without knowing the password, the hash can be used to determine whether it is correct. This is done by comparing the hash with the stored hash for each password query.

But since you can't calculate the hash back, it is not possible to find out the password easily. Instead, you have to try all possible passwords until one yields the same hash.

# cat etc/passwd 
 --- snip --- 
# cat etc/shadow 
 --- snip --- 

So this "$6$E6iRlMhq$PPtmIVokIfVno4oZp..." is the hash of the user "install". To find the password we can take a list of words, hash them all and compare with this hash here.

There is a work by Aram Bartholl, in which he has exhibited books that contain 4.7 million passwords from a leak of a socialmedia platform.

A dictionary attack takes just such "books" and tries one password after another. Unfortunately, this takes a very long time. And if the password is not in it, you can start over with a new list. Another approach would be to generate all possible passwords yourself, from every possible letter combination. Of course, this is much more time-consuming and can take years for long and strong passwords.

But let's at least try the dictionary attack.

./hashcat.exe -a 0 -m 1800 hash ./wordlists/1-million-passwords.txt ./hashcat.exe -a 0 -m 1800 hash ./wordlists/generated.txt

Unfortunately, the password does not seem to have been present in the wordlist and in one I generated out of permutation of the words "remote" and "install"...

So let's keep looking through the other files. As we have seen, there is the user "install" and the user "root". Both of them have a so-called home directory. And as you can see here below, the box was apparently created on February 9 and the last time a file was changed was on February 22.

# ls -la 
drwxr-xr-x 11 root root   419 Feb 22  2013 .
drwxr-xr-x  4 root root    49 Feb 10  2013 ..
drwxr-xr-x  2 root root    43 Feb 22  2013 art
-rw-------  1 root root  8594 Feb 22  2013 .bash_history
-rw-r--r--  1 root root   220 Feb  9  2013 .bash_logout
-rw-r--r--  1 root root  3184 Feb  9  2013 .bashrc
drwxr-xr-x  4 root root   476 Feb 22  2013 bin
 --- snip --- 
-rw-r--r--  1 root root   675 Feb  9  2013 .profile
drwx------  2 root root    34 Feb 11  2013 .ssh
-rwxr--r--  1 root root  1460 Feb 22  2013 start.sh
 --- snip --- 

With this knowledge we can search for all files that have been modified between these two dates and get a list of all files that Julian Oliver has edited.

find . -type f -newermt "2013-02-10" ! -newermt "2013-02-22" 2> /dev/null

What is also always interesting is to look into the logs (/var/logs) or to search for keys (/root/.ssh or /home/user/.ssh). Unfortunately, neither is very productive here. However, an interesting thing is the .bash_history file. Here we can trace relatively exactly which commands Oliver has used and how he has worked.

Neben ein paar anderen Kommandos, stand dort der Link zur Kunst, die im remote install projekt heruntergeladen wird: http://julianoliver.com/remote-install/payload/art. This is still online and can also be downloaded easily without the program from Oliver.

video = "downloading ART"

Let's see what art looks like....

This is how art looks like in a text editor

Art in a text editor

Looks pretty random to me. With an entropy of 7.999997 bits per byte, the art is either encrypted, or just randomly generated (cat /dev/urandom > art). By the way, is random art a thing? Or do you call it generative art?

Now, however, I want to enjoy the full interactions with the system. Therefore I still need to login after booting.

To enable login, you can replace the hash in the shadow file with your own hash.

# mkpasswd -m sha-512   
Password: test

Furthermore, you can additionally store an ssh-public-key in /home/install/.ssh/authorized_keys. This can then be used to comfortably log into the box via ssh.

To write this to the filesystem of the ISO file, we need to use some tools:

cp live/filesystem.squashfs /tmp   

unsquashfs filesystem.squashfs   
Parallel unsquashfs: Using 1 processor
41793 inodes (37808 blocks) to write

[===============================================| ] 37807/37808  99%

created 36975 files
created 4547 directories
created 4403 symlinks

---> change files... 

mksquashfs squashfs-root filesystem.squashfs

cp filesystem.squashfs ~/remote-install_v2/live  

mkisofs -o ../ri3.iso -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -J -R -V remote-install_v2 

And now...

boot and ACCESS GRANTED!!!

If someone still manages to crack the hashes, please let me know.

Next time I will take a closer look at the code and see how the programs work and interact with the network.

But until then, there is a very special exclusive offer that you do not want to miss.

Nowadays we live in a time where no one needs to download anything onto their own computer. Waiting for a download will also no longer be necessary in the age of fiber optics.

Therefore, I offer a completely new approach:

Art as a Service

Art as a service (or AaaS) is a way of delivering art over the Internet — as a service. Instead of installing and maintaining art, you simply access it via the Internet, freeing yourself from complex software and hardware management.

AaaS is sometimes called Web-based art, on-demand art, or hosted art. Whatever the name, AaaS runs on a AaaS provider’s servers. The provider manages access to the art, including security, availability, and performance.

AaaS is a cloud-based method of providing art to users. AaaS users subscribe to art rather than purchasing it once and installing it. Users can log into and use AaaS art from any compatible device over the Internet. The actual art runs in cloud servers that may be far removed from a user's location.

Icons explaining the difference between AaaS and Non-AaaS art

AaaS Advantages

Get your free trial today and register below or on https://hacking.art/as/a/service

This service is a continuous stream that displays the art directly in the browser