 Welcome back everyone. Today we're talking about a mini Linux Forensics CTF that's available until the end of the year. This is produced by Cyber 5W. They have some really good forensic training and this was part of Magnet Summit that just happened, Magnet Summit 2022. For the scenario, you've been called to analyze the machine of an employee so we're looking at an internal investigation. The employee is suspected to misuse the firm machine by violating firm policies. You're requested to investigate the employee machine and find any misused artifacts. Examples of such artifacts are browsing illegal websites, downloading illegal images, illegal music files, and you have a lot of time to do it. It's until the end of the year that you can use this challenge. So we are doing an internal investigation. So in this walkthrough, I'm going to basically give you a lot of hints, but I'm not going to tell you exactly what the answer is every single time. So some I'll just eventually give you the answer, but most of them I'll just get you right up to the point where you can get the answer very easily, but not actually tell you the answer. Okay, so I don't want to spoil the fun for anyone, but I know some people do have trouble like they get caught on one question and it's very frustrating. So let's go ahead and take a look at it. So the first thing you'll need to do is click the download CTF files. You get two disk images, one Kubuntu and one Mate. These are E01 images and Kubuntu and Mate are both built on most likely an Ubuntu style system, which means we're looking at things like app package manager for installation and stuff like that, right? So whenever you're thinking about Linux, the first thing you need to think is what is the package manager? And then that might also determine what kind of blogs you're looking for. So the first thing we have to do is take these SHA-1 hashes and download the images and then verify those. So let's pop over to terminal. So I already have the data downloaded and I have our hashes. Because these are Linux images, I'm going to be using Linux to analyze them. So you could use something like Surugi Linux and then download these images to that and then basically do exactly what I'm showing you in Linux to analyze these images. You could also use a tool like autopsy and then process the images and analyze them in a, let's say, normal forensic investigation way. However, the way I'm going to show you is still forensically valid. Like we're not changing any of the data. It's a little bit faster to get access to the data and I can see it in its native view. So if I'm just doing a quick search of a suspect Linux system, this is probably how I'm going to do it rather than going through the entire processing phase unless I know that I need to recover data. This won't help me recover data. What we need to do first is actually go through and verify these images. Now I want to show you something real quick. Let's say our image for I'll do mate first is one EEB. So if I do SHA-1 sum and then the mate image, you notice that I get a different hash value whenever I'm just hashing the image directly. And that's because for E01, expert witness format files, the hash value is saved in a footer inside the disk image itself. So all of the suspect data is basically in this case compressed and then shoved into this E01 container. And at the footer of that E01 container is the original SHA-1 hash value. So we can't just use SHA-1 sum to hash this file directly. We have to use a special tool. Now a tool that I have installed is the EWF tools in Linux. It's 2014 version, but it still works just fine. If I type EWF and then tab tab, you can see all of the EWF tools I have installed, which is EWF acquire to make expert witness format file images, stream, debug, export, info, mount we're going to be using, recover to recover data and then verify. So one of the most important tools that from EWF tools is the EWF verify. And then this is a SHA-1 hash value. So let's go ahead and look at the help menu for that. EWF verify by default will only calculate an MD5 hash value. I'm not sure about the newer version, but I know in the older versions that's it. So we need to use dash D switch and then explicitly tell that we want to hash in SHA-1 because that's what we're trying to compare with. If there's a SHA-256, it also supports that. Okay, so let's go ahead and do EWF verify dash D SHA-1 and then the mate image. Now this will take quite a while and the reason for that is that this image is compressed. So it has to decompress the image, pull out the original suspect data, and then hash that image for the entire image. So that decompression phase takes a very long time. Okay, so once that's done, we have our SHA-1 hash stored in file and it's the one EEB as we expected and then the hash calculated over the date data is one EEB also as expected. So successful and you notice that it's 80 gig of data. If we do LS, LHA, we can see that the image size is actually 6.2 gig, which means that it is really highly compressed. So it's actually 80 gig of data inside the E0-1 container and compressed at 6.2 gig, but total it's about 80 gig. If you see an expert witness format file, usually E0-1, you cannot just hash it and expect to get the correct hash. So make sure you're verifying it properly. All right, so do that for your other images as well and I've already verified my images. Now the next thing I want to do, I'm going to start with mate. Let's go check out our cases. We have two case, two categories. They're basically the questions for both of the images. So I'm going to start with the mate just because it's first essentially. So I'm going to go back and I'm going to make two folders. So instead of processing the data, I just want to mount the images as they are and then be able to get kind of a native view of the data. Okay, so the first thing I'm going to make is MKDIR for make directory and then I will make a folder called physical one. I'm going to make a folder called logical one log one by one. All right, so now I have two folders and in Linux I can use those folders as mount points, which is exactly what we're going to do here. So the next thing I'm going to do for this mate image is use sudo and then a tool called EWF mount and I need to give it the image that I'm going to mount. So mate and then the location that I'm going to mount it. This image is a physical disk image and I have phi one folder, so I'm going to say phi one. So I'm going to use EWF mount to mount this E01 image container into phi one and I'll show you what that does in a second. Okay, so it doesn't give me any errors, which means most likely it mounted correctly. So I can do sudo and if I'm working on that physical container, I'm going to have to use sudo for basically everything now, sudo ls and then slash phi one and then I have this EWF one container created inside phi one and that is our physical disk image that is accessible just like the suspect's real disk. Okay, so if we hash this EWF one file, we would get our original hash value for the suspect data. Okay, but we don't want to hash it. What we want to do is actually access it. So now I have this EWF one file. I'm going to confirm that it is a disk. So I'm going to use sudo file, the file command in Linux and dot phi one slash EWF one. And we identify the file as a DOS MBR boot sector, which means that it probably is a physical disk image. So the next thing I'm going to do is use a tool from Sleuthkit called MMLS. So sudo MMLS and that shows me the partition information of a physical disk. So if you run MMLS on a disk, if it's a physical disk, it should return the partition information. If it's a logical disk image, it will return an error or nothing, which means that because there's no partition information in a logical disk image, it only works for a physical disk image. So I'm going to do sudo MMLS slash phi one slash EWF one. Okay, now there's a couple useful interesting things here, scrolling down, I'm looking for basically the largest partition that's not this meta partition. And that is this Linux partition 006 is the length is the biggest. So that means that that's the largest storage area. This is probably the partition that we're interested in. Most of the other stuff probably contains boot information. This Linux one probably contains the system files and the user data. Okay, so what we're interested in is first off the length, usually the biggest one, that's how we figure out which one we're going to look at first. And then we need the start offset, the start sector offset. Okay, so I'm going to copy 105 to 672. Copy that and that is our starting location for this partition. However, that's in sectors. Okay, now what we have to do if we need to get the byte offset, not the sector offset. Okay, well, MMLS also tells us there are 512 bytes in each sectors, we have how many sectors, we have how many bytes, now we need to calculate the byte offset in the disk image. So I'm going to run echo, and then paste in our starting point slash star for multiplication, I'm going to multiply that by 512. Okay, and then pipe that into BC, which is kind of like a calculator. So echo our start location slash star, which is multiplication 512. So multiply 512 by the start offset, pipe that into BC to do the calculation, and then we get 53896804. Okay, this is our byte offset to the partition that we're looking at in our disk image. All right, so now we can use built into Linux, sudo mount, mount is just a very standard command in Linux, give it an option for RO, loop, and then offset equals, and we need to paste in the offset that we just calculated, this is the byte offset. Then I'm going to mount the physical one slash EWF, this is our kind of physical disk that we can access directly, and I'm going to mount it to log1, the new folder that I created. Okay, now whenever I mounted that, you saw what happened this folder popped up because now we detected a new mount point on our system. I'm going to go ahead and close that because we don't we don't use GUIs around here, everything is command line. Okay, so now I have my mount point, I'm going to go into log1, and you can see if you know anything about a Linux file system, this looks like a Linux root file system, that's exactly what we're looking for. So this is the Linux root file system of the suspect image. So now we can just run any tool that we want over this mounted folder, and then we will be able to process all of that suspect data. But I don't even want to do that, I want to take it one more step and get native access or native view of the suspect's root directory. So I'm going to go back one, back one directory, so not in log1 anymore. Look at that, I have log1 here. Linux has a command which is ch root, I need to use sudo ch root. Okay, and this is change root. Now root right now I'm in a Linux operating system, and if I go into root right now, it's the slash directory, it's kind of like C drive on windows, and I would be looking at the C drive of my computer, if I'm in root right now. So I can use this command to change where the root location is. Okay, well we already have another root location, and that's the suspect's data. All right, so what I can do is sudo change root to dot slash logical one. Okay, and what I'm going to be doing essentially is logging into the suspect's computer. We'll have almost complete access to all of the features in the system except some like networking stuff. So networking and running processes, that kind of thing, none of that's running, so we won't have access to that. But we can access for example logs and different commands that are installed. So we can see everything, the way that system is configured. So this makes it really easy to do investigations. So sudo ch root log one, enter. Okay, so now you can see that Joshua Adonara changed to root Adonara because it's still the same computer. It's just now I'm root. Now if I look, I am in the user's directory. So I'm at root directory. If I go to, for example, cd home, then I have the users that were in the suspect system. So now I can just treat this like the suspect's computer. Okay, and I can just search around and look at whatever they're looking for. In Linux, this works really well. All right, so let's go back over and check out what our first question is. What is the ID of the last boot, right? So whenever the Linux system booted last, what is the ID of the last boot? There is a special tool in Linux. And this is one reason why I like to ch root into the suspect system is because I can run a tool called journal control. And it will use its own database to give us back any results that we query for. So journal control in the suspect system is actually the journal control that the suspect was essentially was using basically. So I can use journal control dash dash list boots. And this will tell me all of the times that the suspect computer booted using journal control and the database that was available in the suspect system. So we have our dates and times. And the last boot is always zero here. We have date and time, date and time, date and time. And then in this middle here, we have the ID column. Okay. So this should get you what you're looking for whenever you want to answer this question. Now, what I would have to do if I wasn't ch rooted into the suspect system is actually extract this journal control database and parse it out using a different system. Right. And that's just complicated. Instead, I can just mount the image, use journal control and list the boots in there. And we get the ID of the last boot, based on the time. How did the user install Google Chrome on Matte? Remember, I said that Matte is based on Ubuntu. So you're looking at usually apt or d package or possibly compiling from source or something like snap or flat pack. So there's several different ways to install stuff. But always check the easy ones first. Right. So the easy one, if you're talking about Ubuntu or Debian based systems is probably apt. So question two, how did the user install Google Chrome on Matte? Let's go ahead and check that. Now, where can we actually find this information in Linux in all Linux systems? Most of the data can be found in CD slash bar slash log. Okay, this is the digital investigator's best friend. So if we do LS, we see all of the different log files that are available in here. Now, there's a couple of things that are related to installation. So d package could be related. I'm going to check that in a second. But then there's also apt. And I'm guessing apt is the prime candidate for how we're going to install things on Ubuntu or an Ubuntu based system. So I'm going to go to CD apt. And then we see all of their log information. And we have a couple different history files here that we might have to extract, but we'll go ahead and look at it. So we have this history log. It is a text file. The other ones GZ are compressed. We don't have to decompress them. The question was, how did the user install Google Chrome on Matte? I suspect apt. So let's go to history. I can just do cat, which basically prints out everything that's inside a file. I'm going to do history log and then pipe that into this up and down bar is called a pipe, pipe that into grep dash I dash I means grep is to search the results. I is to not care about the case, whether it's uppercase or lowercase. So cat history.log pipe that into grep.I and I'm looking for Chrome. Okay, Chrome. And there we go. So in this bar log apt, the history.log, just the first one we had, we searched for Chrome. And then we found command line app install dash Y Google Chrome stable. Okay. That should get you pretty close to the answer. Okay. All right. What time and date did the user install it? I'm guessing that they're talking about Google Chrome, I think. And if you just do, for example, if you just have grep dash I Chrome, you notice that we have the command line, but we don't actually have the date and time here. So another important thing to do or know about whenever you're using grep is we can give a little bit of context. So I can do, for example, before the match, maybe I want three lines. After the match, I want three lines. So this dash b three dash a three will give me three lines before and after Chrome. There's a couple different ways to do it. But this is easy. So sometimes I want to see one line after and three lines before or whatever. But anyway, always remember that you can see more than just what matches whenever you're using grep. Okay. So now we have our command line app install Google Chrome stable. And then right before that, the start date, right? So start date right before that. So really, all I need is the before one. Let's go ahead and clear that before one. Okay. Chrome also matched here. So it gets that line before, but then that's the line that we're interested in. All right. So we're still in the history.log inside var log app. And that should get us pretty close to the time. So next q for the name of a repository from which more than one extra application was installed from so extra application implies like a third party app not included with the operating system. And then the name of a repository. So probably a third party repository, right? So some extra repository. Well, where can we find extra repositories in Ubuntu systems, especially if it's using apt, we can go to CD slash etc apt sources dot list. And that will tell us that'll give us the list of all the sources. But then we can also see the PPAs or extra repositories installed inside list dot D so LS. And then we have a couple different repositories that were added. This is basically the VLC. So this is the savory. This is an extra repository that was added. And then we have Google Chrome and then we have brave browser release. All right. So this looks like the VLC extra repository with some extra multimedia stuff in the, what is it, savory one, savory one repository. And there's a couple different things in there. Now, is that enough to know where they were installing it from? No, but now we know these extra repositories that they do have installed. So we probably have a good lead. If we go back down one, I can see the cat sources dot list. And this is just a list of repositories. But all of these look like the standard Ubuntu repositories. So probably not there. Okay. Although it could have been there, but probably not there. Okay. So next I'm going to go into cd slash bar log apt again. Let's do cat history log. And then grep I install. So I'm looking for any installations in the log file. There's a lot. And this is actually fairly common. If you've ever installed Ubuntu before, so command line apt install Libre office. So somebody's installed Libre office. All right. Looks fairly standard. Then we have login automatic. We have apt install VLC and then all the packages that were downloaded from that. And then apt install app transport HTTPS curl. And then brave browser. So, so Chrome stable has its own repository, brave has its own repository. App transport HTTPS and curl is probably default. So what I would guess, even if this question isn't super clear about the wording, that it's one of these were related to one of these repositories. Okay, that should get you close to what you're looking for. This entire thing is not the repository list. But you can like, for example, search for part of this. And then you'll actually find the name of the repository. Okay, so next, what is the name of the desktop session. So in Linux, whenever you log into the desktop, you get a session and you get a session name and you can see all of the session information. So if we're logging in, I always go into var log. And then I'm looking at, for example, auth first, so I'm going to do cat auth.log. And that'll give me the most recent sessions. And then I'm going to grep again, I and look for session. And then from that command, you can see the name of the session that was created. So there's always really interesting information on auth.log. It's probably one of the first places you should always check. And it does have session information there. So next question six, this one was a bit tricky. What was the name of the suspicious domain the user visited from mate? Okay, suspicious domain visited from mate. It's kind of a strange wording. But all right. If the user is doing it, let's go to cd home and then user one. And I'm going to check their bash history. And this will tell me everything that they were typing out if they were typing anything. And they got quite a bit of bash history here. Okay, if you see them installing forensic tools, that's concerning. But anyway, okay, so we have them editing the host file that's related to networking. Yep. And then everything else, I don't really see anything specifically related to networking. So let's go ahead and they were editing. I'll show you the etc host file. This file is basically setting static DNS. So you can set up a URL and then make it point to a specific IP address. So I could even point Google.com to my website if I wanted to. And then this computer, every time we went to Google.com, it would go to my website. It's just basically is the first file that your computer checks whenever it is trying to find the IP address for some sort of resource. So let's go ahead and check etc hosts. So if I do cat slash etc hosts, then there's a couple different things here. I have 192 1688 188 185 address that looks very suspicious. And that's probably going to get you close to what the answer is. Okay. All right. So that was it for question six. So hopefully, hopefully that got you close, if not 100% of the way to finding those answers. I hope that's at least enough of a hint. And if it's not put a comment down below, and I'll try to help you out a little bit more. So next is a Kubuntu case. So I need to actually log out of this system. So I'm going to do exit. Now I'm back into my system, Joshua Adonara. And then I need to dismount both the logical and physical devices. So pseudo you mount logical one. Okay, pseudo you mount physical one. Okay. So now I have completely removed this mate image from my system. And then what I would normally do is re verify the mate image because I was inside kind of messing around. I was just looking at stuff, but you never know, you still need to verify. I've already done this once, verified it was fine. So I'm not going to do it this time, but you really should every time. Okay. So the next thing I'm going to do is pseudo EWF mount slash Kubuntu. And then I'm going to put that onto physical one. So I've already dismounted mate from physical one. So now I can reuse that mount point. Okay. Okay, we got the device. Okay. So the next thing we need to do is pseudo mm, mmls and then physical one EWF one. The device inside is always called EWF one. So you can just guarantee it. It's hard set. Let's look at that. Okay, we still got our 512 byte sectors. We have our Linux partition looks the biggest. And then we have this offset. Okay, so I'm going to copy that echo a star offset slash star for multiplication by 512 BC. Okay, that's our byte offset from the beginning of the suspect disk. Copy that. And then now I can mount. I need to use pseudo pseudo mount dash O RO. I need to add it no recovery. Because this image wouldn't mount without it loop offset equals paste in the byte offset. And then physical one EWF one. And then I'm going to mount it again to the logical file one that is freed up because we unmounted the last disk. So nothing popped up, but I can see it on the other side of my screen that a new logical volume was mounted. So now we can do pseudo CH root again into dot slash log one. And then we have our root at an RA again. And if we do LS, we get back into the new Kabuntu root device. Alright, so now we're back into our suspect image for our second second round. Let's see what we got here. Okay, so question one, how did the user install Google Chrome date and time? Just because it's challenge, I assume that they're not going to use apt again, but we can still go into bar log. And then cat apt, let's do history apt history log. And then I'm just going to grep I for Chrome. Yeah, there's nothing found. It would be strange if they used apt twice, right? So what else what's another way that's commonly used in Linux systems to install to install applications is d package. I don't see any other log files right here. So probably d package. So let's do cat dpkg log. And I'm going to do star because there are two text files here, d package log and then d package log dot one. If I do d package dot log star, then I will actually search both of those at the same time. So cat them, actually print them out with cat. So I'm going to cat and then I'm going to grep I and we're just going to look for Chrome. Okay, so d package did install Chrome. And then we're looking for the date and time. So d package and then whatever the date and time that they installed it with, that should get you very close to the answer. How did the device go to sleep? How did the device go to sleep? This one is kind of a bit tricky, but basically we're looking for instances where the device went to sleep. There's a couple of different places that have sleep information. If I do, for example, syslog, the system log might have some information about sleeping. So let's go ahead and just try that cat syslog. And then there's two of them. So I'm going to do star and then grep I sleep in the syslog. These are devices in the system that are sleeping. So maybe that's not what we're looking for. What else can we have? D message might have something. This is kind of information about everything that's happening in the system. So I'm going to do cat d message star grep I sleep. And then it does talk about the sleep button, but basically it's just seeing the sleep button as an input. We could investigate that a little bit more, but it doesn't look very promising yet. So let's check out auth.log because like if you fall asleep and then you wake up, both of those might take some authentication. So cat auth.log star and then grep that into I and sleep. Operation sleep finish, that looks pretty good. So what we might do is actually look at some context around that and sleep is in quotes. So I'm going to do cat auth.log star, pipe that into grep I, and I'm going to give context like I did before. So I'm going to give before maybe three lines and then slash single quote. That way it's literal and sleep slash single quote. So grep doesn't care about the case of sleep. It's going to give me any matches and three lines before those matches. And then I'm looking for this literal expression. So let's go ahead and search for that. Okay. And then now after operation sleep finished, we can see a couple situations that might be related to the answer. So I would look at auth.log for sleep and then give some context behind that to see how the system was sleeping. How many privileged commands did the user run? So we're looking at the total number of commands that the user ran in privileged mode. Well, we're still looking probably at auth.log, right? Because to get privileged access, you need to actually authenticate yourself. So I'm going to do cat auth.log star grep I and then let's look for a command. I know that there's like a command. Yeah, so command. Notice how these are all capitalized. If we didn't use dash I, we wouldn't find that. Actually, let me just demonstrate that. So if we didn't use I and we just search for command, it would look for only the lower case version of command and we don't find anything. But with dash I, we actually do get it back. So I always use dash I just because we'll first off habit. But because it will return more results that then I can kind of filter it down from there. So these are all the commands the user was using with it looks like pseudo for each of them. Okay, so all we have to do is count all of those. Well, I could just go through and count them or I can do cat auth.log star pipe that into grep I command and then pipe that into WC, which is word count. But then if I do dash L, it will count each line. WC dash L will count each line that's returned. And the line that's returned is the number of times that that person ran pseudo and then a command. So that's probably going to get you close to to the answer. Okay, so next, what application was used to open the top devices file? This took me a long time because there is a tool called top that is basically for your top processes that are running. It tells you how how much of your processor eat all of the processes are running. So I was thinking about the top processes. And I'm like, is there a top devices like setting in Linux? And I just couldn't couldn't figure it out for a while because I was caught on a different concept. So then I just quit being silly. And I thought maybe this is actually a literal file. Okay, so what application was used to open the top devices file. So the first thing we can do is go back to the root directory. And if we think this is a file, you can do find dot and then that will find from the root directory, I'm going to grep dash I and then in quotes, top devices. And then we really quickly get dot home user random. So this is a random folder that was created inside the user's home directory, we have a file called top devices. So if I go to CD home user random, it starts with a period and in period in in Linux, if it starts with a period, it is a hidden file. So if I do cat dot top devices, then it's just a bunch of devices. Okay. So our question is, what application was used to open the top devices file? Alright, so the next thing that I searched for now that we actually know that this is a file, we're looking at who opened that file. So I'm going to go back into the user folder. And one thing I'm going to do is first off do grep dash r r I top devices star. Now, I'm using grep in a slightly different way. Instead of grepping for contents, like inside a single file, like I'm using cat to read the file, grep to get contents out of it. In this case, I am doing a very similar search, except the star means look at all of the files for top devices. I don't care about the case. And then the r means recursive. So look into each directory whenever you do that. Now, if I run that here, we don't find anything. So no files that were accessible have those top devices. However, whenever I do that, grep doesn't look through the hidden folders, right? So there's two hidden folders that I'm interested in config, and local, definitely those are two that I really want to look at. So I'm going to go into dot CD slash config. And then I'm going to run the same command again, grep r I top devices. Okay, and then we find a hit actually find two hits in the same file. The file that we found a hidden is Kate meta infos, Kate meta infos. So both hits were in that file. I didn't find any hits anywhere else. Alright, so let's go back and then go to local dot local, share. And then this is kind of where a lot of your configurations and things will be saved. And then I want to search through that really quickly. So do the same grep dash r I top devices star. And then I find again, more hits, but it's all in Kate anonymous Kate session. So what application might have accessed the file or opened the file, you should have enough information now to know which one it was. And then finally, what was the UU ID of the main root volume. This one's super easy. Going back into slash bar log. So the log directory for for Linux, this is where most things are going to be for logging, we can do. I know, for example, that D message has information about booting up. Yeah, so we're just going to search that. So cat D message, and I'm going to do star. So that way we get this D message and the dot zero, this is the older log that's kind of rolled over. Now we might have some more interesting information in these G zip files, we might have to go into there later if we don't find anything interesting. So cat D message, all of the plain text stuff, and then pipe that into grep dash I, and then I'm just going to search for you ID, why not. So we have command line and then the boot image and the boot image that's loading. And then we have root UU ID. And this is the root device that it's looking for. Okay, so the root device that is looking for to be able to boot that is the UU ID. You notice that the root device is D 131 C, D 131 C. So I'm going to go ahead and use the, the grep R I UID star trick against all the log files, just looking for UU ID and see if I can find the root file and anything else. So we also have it in three one C in the x org, we also have it in sys log, specifically six sys log one, and they all look like the same UU ID. And then we have it in the kernel log, and then a couple binary matches. D package log is not relevant because that's the package to install. D message has it bootstrap log doesn't look like it has it. And then boot log didn't look like it had anything at least not directly matching, but we could also search just for that UU ID and see if we find any interesting files. So I'm going to just copy that and see if we can find it. So doing the same search. This is just to see what other files might have traces of that log. So x org against sys log kernel log. D message. Yeah, so just those. Okay, but that's still several different places you can look. So like the way that I'm getting these answers, there's there's lots of different places that store information in a very redundant way. So you do what you feel like that was the last question that should get you pretty far on the ECTF. I just need to exit. Right. And then I need to do sudo umount.log1 to dismount the logical volume. And then sudo umount physical one to dismount the physical volume. Okay. And then that's pretty much it. I can go ahead and clean up those log files log one. If you're in Sarugi Linux in the, I think it's either slash mount or slash opt folder, they've already pre created these these mount points for you. So it's super handy the way that they've done it. You don't have to clean anything up. You just use what they have there and that's it. All right. So that's pretty much it. The cyber 5w CTF is pretty interesting. Some good questions about Linux. And I know a lot of people don't have experience or much of experience with Linux. So I really recommend that you go through, you know, I didn't give you exactly the answer. So at least you still have to do a little bit of work to look around. But that should give you enough hints to get you very close to what the answer should be. I will have a blog post on this with all of the commands typed out so you can go check out that. So I hope that helps. Thank you very much.