 Welcome back everyone. Today we're talking about the utility Android triage, and it is already built into Soryug Linux, so I'm going to be demonstrating it in there. If you don't want to use Soryug Linux and you have macOS or another version of Linux, then you can also just download the Android triage and even iOS triage utilities from github.com slash reality net and they have the Android triage repository. It's written in shell code, but apparently it works in macOS X, and it does work in Linux. You will need the ADB Android debugging bridge installed and configured properly in your system, which is basically the reason that I'm using Soryug Linux is because all of that's already set up for us. And when you first run it, all you have to do is type Android underscore triage, or if you're downloading it from the repository Android underscore triage.sh. And that's it. You don't have to give it any any arguments or anything like that. If you don't have a phone installed, then it will say no device connected. Click Okay. Whenever you're connecting your phone, make sure you set the phone into debugging mode that way the computer can actually communicate with your phone. So now I've connected my phone, it's in debugging mode. I can just type Android triage, press Enter. So once you successfully connect to the phone, then you should see this window pop up with several different options, a list of options that you can run, it'll have a blue background and tell you the version number. First, I'm going to run collect basic information, just select number one, an option number one is selected. Are you sure you want to proceed? Say yes. And then it's connecting to the device, it's pulling out all the information it can from the phone. And it has the Android ID. And this is important, because once we get the Android ID, that is going to create a folder in the directory that we were in whenever we ran the acquisition or the analysis. So if we double click onto this folder that was just created with the Android ID, if we go into the info folder, now we have the text files that have information about the device itself. There's a lot more than just shows up in the interface. Go check that folder for additional text files that have additional information that was extracted. Next, execute live commands, this would be something like if I wanted to collect RAM acquisition from the device, for example, I could execute live commands manually and maybe do a RAM dump. Okay, so we will skip that for now. Next is execute package manager commands. So if I hit enter, and option three selected, do you want to proceed? Yes. Now it's going through and going into the package manager, basically listing all the information that the package manager has. Now we're back into the menu, go check that an original folder with the Android device ID. And now we have a file called package manager. If we go into that, we see a lot of text files that basically have all of the output of the package manager for that phone. So next we have execute bug report dumpsys commands hit yes, basically going out and doing the same thing. Okay, so now dumpsys acquisition has completed and we're back to the menu. So let's go back to our Android ID folder. And we have the dumpsys folder that was created. All of this was extracted from either dumpsys or app ops, we also have the bug report. And whenever we were generating the bug report, the bug report was actually generated on the phone, and then transferred over, which means that this zip file would have been created on the device. I don't know if it's actually saved to disk, but it would at least be created in memory. But look at this, it's 2.9 megabytes. So there is a lot of memory transactions going on here. So you might, for example, in terms of a process, collect the basic information first, because that gets you some really quick information directly from the system, really minimal changes to the device itself, but some still, and then execute live commands. If memory is interesting to you, do this second, that way you're collecting RAM acquisitions and things like that. And then after that, you can execute package manager and not have to worry about overriding some of the user's data in memory. I think they're probably actually set up in order of the way that you should actually run them whenever you're working on the device itself. That's what it looks like to me. So from this, we're going to get a lot of really interesting things like backups, battery stats, battery sets are used a lot for establishing times that things happened and locations. Clipboard could be very interesting. CPU information might be interesting. Distats could be. So actually all of these, depending on what you're looking for in the investigation, you might have some leads coming from here. Next, acquire an ADB backup. ADB backup is going to give you anything that the user essentially can access. Go ahead and try that. And you can see the command ADB backup all shared system key value APK dash backup dot AB. Like it says, you will have to unlike your device and confirm the backup operation, and then it will start and it is currently backing up, but it's not updating here. So just wait until that backup finishes from the suspect device. Okay, so our ADB backup completed just hit okay. Now let's go back to our folder. And we have our backup folder that was created and then we should have the dot AB Android backup backup file created. We also have the log file, which should have this hash in it. All right, so going on next, we have acquire the system folder. Okay, so system acquisition completed that basically it's just copy over and then they create a tar file and copy the tar file over. Yeah, so the system acquisition log plus the tar file that was copied over and I don't know, maybe they do decompress everything. So next, we have the SD card folder if it exists. So just like the system folder, we have the SD card extraction folder with the log and all of the files that were extracted from it. So next is extract APK files from the data folder. So just like the others, we have an APK folder that was created and then we have everything from data app, and then all of the apps and we should have the APKs inside of there. So now, if there was a malicious APK or something, we should be able to analyze them next is extract data content or data from content providers. So that's the first time we got errors, one of we were doing our extraction specifically with permissions to access the data. Let's see if the content provider, okay, it just has whenever it started, but it doesn't have the errors in the log file. But we still were able to get some things like contacts, calendars, media, browsers, settings from the system, things like that. So it's still useful even if you don't have permissions for everything. And then the last one I think is the file system dump no root. And this is also going to be useful because we can run this through other tools later. So let's go ahead and start that. Okay, the file system dump completed. Let's look at we're already in file system, but we have the whole tar and then we have the file system. And looks like everything got under there. So now we could basically just feed this file system folder into something like a leap, and then try to do some analysis on it. Now, notice that we didn't get everything from system because some things had permission or access issues, but we have enough to at least start with. So it's not a full acquisition because we don't have root. So we weren't able to copy everything from the disk, but it is a very, very quick way to get a lot of really interesting things. So that was all the different features of Android triage. I think this tool is a little bit misnamed. It's not actually doing triage analysis on all of these things. It's doing logical acquisitions in several different ways. So it's pulling out some system information that we can use to make decisions, but it has almost full logical acquisition capabilities. So I think that's really interesting. And the second thing that I think is interesting is that it looks like the authors were thinking about the order of volatility while they were actually creating this. So if you just go from one to 10, then you're essentially getting the least invasive to the most invasive processes, depending on what your live commands are. So like I said, I would probably be trying to do something maybe like memory acquisition at step number two, but definitely collecting the basic information is a great way to start. Number two, let's just say it's memory acquisition. And then number three, executing the package manager where we're starting to change more things in memory, bug reports, things like that. Basically, everything after this is requiring a tar file to be created, which means that we're going to be modifying more of the suspect device because it is a live environment. These tools are awesome because we don't have to memorize every single switch and command to do all of these useful features. Second, it is respecting the order of volatility or at least appears to be. And third, after you do all of these steps or all the steps that you need, you have a really comprehensive dump of all of the data from the suspects device. Now, do you have everything? No, probably not. A rooted device is going to give you more information. But do you have enough to start an investigation and do quite a lot of normal investigations? Yeah, definitely. Would I call it triage? Not necessarily, I would call it acquisition. So I would probably say this is Android logical acquisition tool 1.3 or something like that. But I definitely recommend that you take a look at it. Everything is going to be dumped into the same folder that was created with the original Android ID. So it's very easy to parse through. Like I said, once you get the file system and possibly even the backup, you might throw other tools like a leap at it. Everything else you can probably parse out just using command line. Really interesting tool, easy to use, respects the order of volatility. Highly recommend it. That's it for today. Thank you very much.