.+:::::::::::::::::::::::::::::::::::::::::/
.//`+++++++++++++++++++++++++++++++++++++// 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
-++-yo////////////////////////////////////y`s
-+o-:--------------------------::::-:://:---s
-+/ :-.: +:oo- s
-+/```````````````````````````````````:-````s
./o//////////+o:::::::::::::::::s+/////////::
``://////////+s:::::::::::::::::y+/////////:.
s .::::/osso::::. .+
`.y +yyyyhNNNmyyyy+ .+
`:h:::::/+:::::::::::::+:///////////////////+--------------------
.o s s::::::::::::s.+ - +
-/y .o s ::::::::::::oss+::.+
`-y .o y `+//: .+
`.+/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.
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.
https://julianoliver.com/output/remote-install.html
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.
Now let's start the VM and boot up the system.
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".
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 root:x:0:0:root:/root:/bin/bash --- snip --- install:x:1000:1000:install,,,:/home/install:/bin/bash # cat etc/shadow root:$6$PP0JCTeL$SvFieKdMJV0r0Sw0DDb.qOD3iQ/WVyuaQ65M0MtWh71uHq4kUuChI8lJM2tKw8eCZyq3qq.IQZqH34og/1Upz0:15745:0:99999:7::: --- snip --- install:$6$E6iRlMhq$PPtmIVokIfVno4oZp17KO3XJehTRc.DKmCn1mfEJWeaTKUA17SRZlQ7JvrhuphAfPOctGZfYbFU.D46ceMWZY.:15746:0:99999:7:::
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.
Let's see what art looks like....
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
$6$1ESnJ02o.eWOWDQw$ULlVfQmoPRV0jNyy2y4wmwmbTsfXtmVofJlOjc8UAPnNbvngl7yeYnKGCxrXX4aFX.7a.hSBDRfkXMrB05/Ki1
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...
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.
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