 Thank you for coming. Today we're going to be talking about ECFS, extended core file snapshot technology. How many people here know what a Linux Elf core file looks like? So today we're going to be talking about extended core files. This is a technology that helps aid in process memory forensics in Linux. So what that is is an extended version of a typical core file that is specifically designed for memory analysis. And that is what we'll be discussing. I've taken everything that I know about the Elf binary format, reverse engineering, process infection, Linux viruses, exploitation, and imbued that knowledge into the design of this software or technology or core file format. So quick history. In 2011, I had designed a prototype for a DARPA CFT. It's called VMA voodoo for live process analysis in Linux and it detected runtime infection. So that could be anything, a memory resident virus, shared library injection, PLT got hooks, strange segment permissions, anything that would constitute a process being infected, any type of VMA anomalies, hence the name VMA voodoo. This was just a prototype and it worked on 32-bit Linux about five years ago. And fast forwarding in time, about six months ago, I was thinking it would be really cool to rewrite that software, put it in more of a production ready state, but I thought it would be cool to have a native snapshot format because the way VMA voodoo worked is it analyzed live process memory or it took these raw memory snapshots of the process, nothing real special. So I was thinking a native snapshot format specifically designed for forensics analysis of a process. And so I wrote ECFS about six months ago and I quickly realized that it was very useful even on its own and especially it could be used with other people's technologies because there's already a lot of forensics technology out there and this is kind of a complimentary piece. Lotan is a product, this is advanced technology for detecting exploitation through crash dump analysis. So this actually looks at mini dumps in windows or core files in Linux and is able to detect whether or not that was the result of an exploit. So ECFS is actually now in the process of being merged into the Linux component of this product. So it is being used and so check that out if you get a chance. Very cool stuff. So moving on, just kind of getting into the problem space here. So a process address space is, it's like a little, it's very complicated on its own. You have full system memory, you've got kernel memory. What about just a singular process? Because a process, especially these days in Linux is relatively complicated. It is heavily constructed from the ELF binary format, of course, because you have ELF executable, you've got the shared libraries. There are a lot of structural nuances within ELF. Say it's dynamically linked, then you've got the dynamic segment, which exists within the data segment. You've got the global offset table. You've got a lot of different types of data structures. And not everybody knows how all of these work. So you have to be a real expert in the area of understanding how a process is laid out and understanding the ELF format to be really successful in reverse engineering a process. A process is a little different than just an executable because it's got the executable and then everything else mapped into it. So ECFS, as we'll see, brings a lot of this stuff together and it makes navigating a process image extremely easy. So it's no secret that hackers have been infecting processes for a long time. So of course you have hackers infecting kernel memory, kernel root kits. But there are a lot of hackers who infect processes. And there's not a whole lot of automated stuff to detect this stuff. I can think of a few cases from the last couple years in particular, but these processes can get infected and it's stealth. It's typically more stealth than if you're infecting the binary because it's only resident in memory. And just a few examples of these types of infections would be memory resident viruses. So maybe a virus that copies itself from process to process will steal in credit card information from Firefox. Maybe a virus that infects the LDAP daemon and siphons information out about users. So a lot of different reasons to infect the process. Root kits as well. People are familiar with Jinx or Azazel. These are like LD preload root kits. Hackers use these. And any type of backdoor. So later we'll use an anti-forensics exec to inject a backdoor into a process address space. And then of course exploitation, which tend to leave behind residuals. Maybe a patch, C tours or D tours section. Modified gut, corrupted heap. And these are all things that we want to be able to look at and very quickly identify. So there are a lot of process, there are a lot of forensics tools available that also do some process stuff. So the three major ones, you've got volatility, recall, and then second look, which is commercial. And primarily these do full system memory dumps. And of course in full system memory dumps eventually the process is in there somewhere. But they tend to get really nice structural access to the kernel through something like dwarf debugging symbols. Well, you don't have dwarf debugging symbols for every single process. So these full system memory dump analyzers tend to lose resolution the closer they get down to the process level. So ECFS isn't meant to replace these tools. It's hopefully a supplementary thing or something that could be integrated within them for specific to process analysis. And then of course you have Ptrace, GDB, and just regular core dumps. And these are all tools that can be used. So I originally had a few slides to discuss volatility in more depth, but because of time constraints I'm going to have to skip those. But they are in the slide deck so that you know. So extended core file snapshot technology. So it is a custom core file format. It's an elf format based on original core files. It is backwards compatible with original core files so you can still use them for debugging. So if you have this thing hooked up on your system like I do, you know, you can still use the core files for debugging. But you can also use them for detection and malware analysis. And as we'll see later, you can even relaunch these snapshots back into memory. In other words, you can pause a process and restart it where it left off two weeks later. So quick little diagram here to get people reacquainted with a process. This is a really high level overview. But of course you have in memory, you've got the executable which has a text segment, data segment, BSS at the end of the data segment, the heap, then the functions are in the text segment, aka the code segment. In the data segment you have the PLT got. So the global offset table gets patched with function pointers. As you can see, the arrow points down to the functions in the libc shared library. Then the libc shared library has a text segment, data segment of its own. All separate mappings. And then the glibc syscall wrappers which point to the VDSO and V syscall page mapped into the process. You've got any anonymous memory mappings, file mappings, stack segment, and there's other stuff. But this is just a high level overview to let you visualize a little bit what we're going to be looking at. So quick overview of our attack surface. So these attacks are kind of like, there's a myriad of different ways to attack a process. But a lot of what we're looking at is different types of injections. So dynamic injection, so that would be injecting shared objects into a process or a position independent executable into a process. Relocatable code injection, so injecting an object file into a process. Then the hacker would patch all the relocations and it would be like runtime relinking. And you can even execute fully dynamically linked executables into an existing process. This is an anti-forensics exact technique that we'll look at later. And oftentimes these types of injections are accomplished through means like LD preload. It's a real basic one. Lib C DL open mode which is a DL open that is resident in Lib C always and tends to be used for injection. CISP Trace of course which is often used as a means to accomplish some of these other things such as shell code based loading, VDSO manipulation. And once we get this code, once the parasite code is inserted into the process through whatever means, oftentimes control flow needs to be hijacked. So this could be redirecting of functions through the PLT got, through inline hooks like trampolines, patching function pointers. So sometimes people will patch constructors and destructors. Also known as in it array and finny array on 64-bit architecture. And any type of modification to the code segment. And any anomalies beyond this of course as well such as strange segment permissions. Maybe the tech segment gets marked writable or the data segment gets marked executable to defeat depth. Of course packs and protect would stop this. But there's just a lot of different types of attacks we're looking at. And this is the general building blocks. So here is a ugly diagram that I put together a long time ago. And it just kind of shows you visually what we just looked at. This is essentially right here a binary in memory. You got the tech segment, data segment. Of course the section header table doesn't get mapped into memory. And you can see in red the different infection points. So the procedure linkage table, the jumps could be hooked. Function trampolines get placed in the code. Function pointers can be overwritten in the constructors. Global offset table can be patched. Global data variables, these things, it varies whatever is in there. But it could be interesting things that an attacker may modify such as function pointers. And of course you have the BSS where all the uninitialized global data goes. And one thing that's missing from here, and it's not in red, but see the dynamic section. The dynamic section has tags. So like the DT needed tag, that can get modified as well for another form of shared library injection. So the definition of process memory forensics and analysis. And this is pretty broad. But people want to do this to either understand the process layout and structure for whatever reason. It might not even be because they're trying to detect an attacker. But it is necessary when we are doing that. And we want to learn the runtime characteristics. So is there dynamic linking involved? If so, then, okay, what type of relocations are we going to be looking at? What type of symbol tables do we want to reconstruct? Typically, forensics analysts want to identify anomalous code or data. And there are many different ways to do that. ECFS actually does a lot of heuristics on the back end and we'll see that. Does a lot of the work for us. But ultimately, we want to identify process infection, which could be a back door. Root kits like Azazel or Jinx, key loggers, memory resident viruses, or it could even be a virus that infected the binary, but then it shows up in memory. And then protected binaries. So ECFS is actually really useful for helping reverse engineer encrypted binaries as it can reconstruct symbol tables and help you map out the entire process. And of course malware oftentimes is protected or packed, has a lot of obfuscation layers and things of that nature. ECFS is useful for this as well. So let's just take a quick look at what a traditional core file looks like. So regular core files, essentially a snapshot of a process. It's an elf file. It has an elf file header. From the elf file header, you find the program segments. Program segments are of type PT load. They're loadable segments and they just represent all the different memory mappings in the entire process. So the text segment, data, heap, stack, shared library mappings and so forth. But there's not a whole lot of metadata associated with these. It just has the raw segments. Not super useful for forensics analysis. And in addition to the PT load segments, there's one segment that's a PT note. The note segment contains all the metadata about the core file that, say, GDB uses when debugging. Such as what the register state was, the auxiliary vector, which is what the top of the stack looks like when a process starts. Signal information and the paths to the shared libraries that are mapped in. Now, these core files are generally created when a process crashes, when it's delivered a seg v or a sig bus, different signals will cause a core dump. To look and see how the core dump code is created, you can look at binfmt underscore elf dot c. This is a kernel source file, which is pretty interesting. All the elf loading code is in there and in particular the code that creates a core file. So arguably at best, core files are useful for debugging. Some people will state otherwise. Now, they're not particularly useful for forensics and here's why. They are highly dependent on the original executable and shared library files still being on your computer. So when you load a core file into a debugger, you have to have the original executable, right? And you have to hope that executable has symbols and maybe even some dwarf debugging information. Now, the other problem is that the tech segments are truncated and this is to save space. So the tech segment of the executable, the tech segment of all the shared libraries are all truncated to 4K. And Linus says this is to save space and that makes a lot of sense because the tech segments are still in the original files, which is fine for debugging. But as we know in forensics, many times the tech segment gets marked writable and it's self-modifying and it changes. So we need to actually have the full tech segment as it was reflected in memory on disk. So ECFS makes sure to do that optionally. And overall core files just don't really give you the kind of high resolution insight into a process that would be nice for forensics analysis. So let's just do a quick recap here on the forensics goals. Overview, of course. Detect shared library injection. We want to be able to detect any type of control flow hijacking. This could be done through the PLT got hooks. We want to detect any type of injected L file. Could be an object file. Shared library injection. Could be executable injection. Pi injection. Any type of shell code that's been inserted into the process. Which could then in turn load an L file. And any strange segment permissions such as a writable data set or writable code segment or an executable data segment. And the list goes on. But once again these are kind of some of the building blocks. We want to be able to quickly identify this stuff. Typically it's not very easy to identify just a raw process. So in the end we might be looking for user land memory root kits, say Jinx, Zazel, more sophisticated ones that are out there. Exploitation residuals. And runtime malware or memory resident viruses. So the ECFS technology essentially it can either A snapshot a process and keep the process running but then you have a snapshot of it, an ECFS core file of it. Or as we'll see in a minute it can hook into the core handler and essentially it transforms the core file into a very special type of core file. Specifically for this type of analysis. And the analogy here with these images is that the core file is this kind of black and white or monochrome image of a process. So it's kind of flat zeros and ones. Then on the other side we've got the high resolution core file. That's the ECFS file. And that's just a little analogy. So what are the ECFS use cases? And this is kind of redundant here. So live malware analysis. There's a suspicious piece of malware that's running and you want to snapshot it. And maybe you want to then take that snapshot, put it in an isolated environment and then relaunch it back into memory. And it'll start where it left off. And this is something ECFS allows you to do. Process necromancy is what some of the guys around the office call it. And any type of process forensics which could mean a lot of things as we already went over. Also helping break protected binaries. A very powerful binary protector was protecting a program on my system and it crashed. So ECFS caught it. And I was amazed that ECFS fully reconstructed all the symbol tables. Even though all the functions were individually encrypted. Only one decrypts at a time. And it does this through a very special type of symbol table reconstruction we'll talk about shortly. So now let's just get into the ECFS features. So this is a list of the features but I do have a slide for each one. So I'll go over them individually. So ECFS plugs into the kernel's core handler. It's actually a user land application. You don't need to modify the kernel. Proxys kernel core pattern. This is also the file that like a bunch of Abort modifies. And essentially if you use the pipe symbol you can tell the kernel core handler to pipe the core file it's creating. So it will pause the process that's crashing. It will pipe the core file into the standard input of whatever program you want it to. So we tell it to pipe it into the standard input of the ECFS handler. Which then essentially dazzles that core file up, totally transforms it and then spits out an ECFS file. So that command right there is just a basic command of how you would enable ECFS on the system. You can also snapshot a process without killing it, without having to core it. And so that's obviously handy as well for when you don't want to kill a process. So symbol table reconstruction. In my opinion this is perhaps the most useful feature, one of them at least that ECFS does. So as reverse engineers you probably know it's very nice to have symbols. Well what ECFS can do is even if the original binary was totally stripped, has no section headers, no symbol tables. When that binary gets snapped, when that process gets snapshotted, ECFS fully reconstructs both of the symbol tables. And there's two symbol tables in a binary. You've got the local symbol table, SIM tab, the one we're looking at here. And that's all the functions that were in the binary, not the dynamically linked functions. And it turns out that GCC compiles all binaries by default with a segment called PTGNU-EH frame. There's a section called .eh frame in the L-sections if you look. This contains the exception handling frame description information. And you can parse this door FIMFO, the common information entries, and then you get the FDEs. And you can use this to locate the address and size of every single function in the binary. So even if all the functions are encrypted, let me give you an example with IDA-PRO. IDA-PRO uses control flow analysis or fingerprinting to find all the functions. Well, what if all the functions are encrypted or packed or obfuscated? Then that's not going to work. So essentially what ECFS does is it uses that approach. Let me go back real quick. If you see that link there, that link will take you to some code on my site. Because I came up with this method about eight months ago. And you can use that code to rebuild symbol tables. A friend of mine did it in a CTF and he won it way before everybody else because he quickly reconstructed the symbol tables. So that's how we reconstruct local symbol tables. And it's powerful. I haven't had it actually fail on anything. As long as that EH frame segment is there. And the only time it ever wouldn't be there is when a binary is explicitly told not to have it. Usually if you compile it with like no STD lib, even then it still may be there. But very nice. Clang does it too. So anyhow. Let's look at the dynamic symbol table. So the dynamic symbol table, this is like symbols for what, printf, fgit, stir copy. And the way we do this is the dynamic segment of a program is in memory. Because it's needed by the dynamic linker. So you can locate the dynamic segment. ECFS does this of course. Find the DTSim tab. Then it resolves the address of every single shared library function and it plugs the addresses into the corresponding symbols. So very nice feature as well. Complete symbol table. Reconstruction. Next thing you see it rebuilds. Anybody know what else section headers are? Okay. I'll assume some of you guys do. Well, section headers are very nice because they allow making navigation of the binary much easier. They're not necessary for runtime. But they're usually there because they're used by linkers and debuggers. Well, even if the original binary had no section headers, let's say it was stripped by a hacker. When ECFS snapshots that process, it still fully reconstructs all the section headers. And all the original section headers, just about all of them, and it reconstructs and builds a lot of new section headers that are totally custom and pertain to ECFS forensic stuff. So let's just look at some of those sections. So there's a section for the heap. So you can quickly access the heap data. There's a section for the stack or stacks if there are multiple stacks. The VDSO virtual dynamic shared object. The vSyscall page. Now text and data, they're in capital letters, those actually point to the text segment and the data segment. Those are different than the text and data sections. Now some people know that the PROC PID directory has a lot of information about a running process. So when this ECFS snapshot is created, ECFS captures the PROC PID directory, compresses it and stores it in a section, PROCFS.TGZ. Very nice to decompress and look at. PR status, contains register information. FD info is nice because it retains all the file descriptor information, the offsets, the files, the socket information, IPC, all of that stuff about the process. And that's one reason why snapshot or process necromancy works. Why you can bring the process back because it restores all of that information. Files that were opened, wherever the process was at. The auxiliary vector, the executable path, and the personality is very ECFS specific. It contains information that pertains to ECFS such as where the symbol table is fully reconstructed. Basically the personality of the ECFS file, what components were turned on, where heuristics enabled, things like that. And then the last two is the ARG list which contains the ARG V vector of the program and then the FP reg set, floating point register. So all very easy to access through section headers. Now more importantly is there are three custom section types because you have section names but then you have section types. So for example, sections that have code in them or data are usually of type PROG bits, means program bits. Well, what we have is three custom types. So SH lib, anytime there's a shared library mapping it gets marked with the type SH lib. It's very fitting. But what's even cooler is if a shared library was determined by ECFS to have been injected unnaturally, such as by an attacker, it will actually mark it as injected. So you can just use read-elf, look at the file and be like, oh, this was injected. If it determines that a shared library was preloaded, then it will actually mark it as preloaded. So those are very handy for quickly identifying injection. Now if we move on, talk a little bit about the injection detection heuristic. So what is a normal shared library? It gets loaded by the dynamic linker. So how do you differentiate when that is normal versus not normal? I won't go too deep into the detail, but getting this, it's not too difficult, but getting it to be accurate every time takes a little bit of work. And essentially the idea is that a library can legally be loaded by DL open, can legally be loaded by the dynamic linker, or by preload. But if it was loaded by some other means, such as libcdl open mode or ptrace or the VDSO, then we can assume that it's been injected. And a lot of work goes into analyzing a lot of different parts of the process to determine that. And we can not just detect shared library injection, any type of injected code. And we'll see that in a quick demo shortly here. So libcfs, this is actually an API I designed that I wrote so that people can very easily integrate ECFS support into their malware analysis tools. And it makes process analysis or let's say you take a snapshot of a process that you know some malware was running in. You could write a really sophisticated tool using libcfs very quickly. One thing we'll look at shortly here is I wrote a tool that detects shared library injection, PLT hooks, and that usually takes about 3,000 lines of code to detect the PLT hooks and shared library injection reliably, say 3,000 lines of C code. And this tool is like 50 lines of code because it's using ECFS and the libcfs API. It's very easy to use. And you don't even really have to know ELF too much to know how to use it. There is some documentation. So read ECFS, if you're familiar with the tool read ELF, read ECFS is kind of like read ELF but it's specifically designed to read ECFS files. It is designed using the libcfs API and that is why I designed read ECFS to show how to use libcfs. It can do things such as extract the parasite, if a parasite is found in the process. It can parse any of the sections, show all the file descriptor, socket information, et cetera. It's still in early development. It's a work in progress like all of this. So the last kind of thing I'm going to talk about here before we get into a demo is ECFS re-execution. So to my knowledge, there was only one other thing that could actually do this. I believe it was called cryo PID in maybe 2008. I don't know if there's a more modern version. But the idea of being able to snapshot a process or pause a process, completely take it out of memory and then resume its execution where it left off is something that a lot of people would like to have. And ECFS is so fecund with information within the file, all the information about the process. And because it is essentially an ELF file, why not be able to execute these and relaunch them back into memory where they left off? So if anybody remembers Grux user land exec, I wrote a user land exec, except it's specifically designed for loading ECFS files, not just regular ELF executables. And it will restore the file streams. It doesn't work on the IPC yet. So I wrote ECFS exec and here's the GitHub for it because it's separate from the regular ECFS repo in about a day, days time. So it needs a lot more work to actually go anywhere at this point. It's a prototype. So what I'm going to do now is I'm going to do a demo. So I'm going to do a demo of Saramon. So Saramon is an anti-forensics exec technique. So people know about like threat injection, maybe being able to inject some shell code into a process, position independent shell code. Well, what I wanted to do was take a fully dynamically linked executable and be able to inject that into a process. So basically be able to, it's an anti-forensics exec because Saramon allows you to execute any program you want just a regular dynamically linked program inside of an existing address space. So it doesn't create a new process. That's why it's anti-forensics. So what this does, we'll inject, in our case, we're going to inject a backdoor that I wrote when I was 14 that I still have the code for. We're going to inject it into an existing process and it will run concurrently with that process. This is a difficult technique to detect just by, you know, whatever means it would take some reverse engineering and it's not anything real apparent. So we're going to use this as kind of a use case for showing how ECFS can help quickly identify the backdoor, et cetera. So let's do that real quickly here. Let's go into Saramon. So first, for simplicity, we're going to run the simple program host. It just prints I am a host. And then we're going to launch, we're going to use this anti-forensics exec. And our backdoor, it's a remote backdoor, binds to a port, it's called server. So we just injected that into this process. Okay? And we go over here. You see that process is still running, but if we tell that local host 31337, we actually got a backdoor. So there's a backdoor running inside of that other process. It's like password and bam, we're in this awesome little backdoor from 99. And now I'm going to go back over here and I'm going to get a snapshot of that host program. So I'm going to go just use the core handler. Now if we look in cores, we got two snapshots because there was thread injection. So there were two threads. So we can look at any one of them. So let's just first use redcfs. Host.2848. And a lot of information, register state. But what we're looking at here is if we look at the file description information, we see that host, why would a program that just prints I am a host over and over have this port right here that's being bound to? It's because we injected the program into it, the backdoor program. So that's just the first kind of anomalous thing. Now what we're going to do is we're going to use just the standard read elf utility. Read elf, we're going to look at the section headers of this ECFS core file. So as you can see, and it's important to know regular core files do not have section headers. So this is a nice feature and you can see there are many section headers for every single part of the process you would want to access. If you wanted to look at say the got, the PLT got, you would just go there. You could open up in IDA, you could open it in object dump. You've got the heap. Now here's what's anomalous. You see this? It says injected. So these other ones just say SHLib. But this just says it's injected and it says elf.DIN.0. Says DIN, that means dynamic because the executable we injected was position independent. So we've spotted something here. Now the next step would be we want a sample of that parasite. So we're going to do read ECFS minus O, kind of like object copy dash capital O. That's where I got the dash O from. And then we go 2848. It's called elf.DIN.0 is the section we want to extract. And we'll call the file parasite. So now we are looking at the program headers for parasite. We have a full sample of the executable that was injected into the process. So we were able to very quickly kind of perform surgery, if you will, on the ECFS file and quickly isolate where the parasite was. We saw that it was bound to a port because all the socket information is included in the ECFS file. And we see that it's a position independent executable. See that? It says dynamic. But it's not a shared library. And that's that server backdoor. So that's just one quick example. Next, oh, well, yeah. So next what I'm going to do, let me just see here. We're going to look at, so the jinx and azazel root kits that people use is an LD preload type root kit. And what that does is it preloads the azazel shared library into a process that the hacker wants to infect and then hijacks certain functions. So we're going to run another simple program host and we're going to infect it with the azazel shared library. So that's just saying hello. We go over here. Let's do kill-11 pit of host. Actually, let me get rid of the other one so I don't get confused. Now, we've got that. So what we're going to do here is let's just look at the section headers again with read-elf. Keep in mind I'm just using open source object utilities. Read-elf is totally compatible with our ECFS. So looking at the section headers again, okay? Now let's go all the way down. There's all the shared libraries. And now suddenly look. We see that the azazel shared libraries and ECFS detected them as being preloaded. So immediately that looks suspicious. You know, the libraries were preloaded. And furthermore, let's say we want to investigate the global offset table. See if there were any functions that were hooked. Well, the long way to do that would be to use read-cfs. And you have to really kind of know what you're looking at here. Look at the global offset table. It shows the got value. It shows that it should either be the shared library or it should be the PLT stub. If it's not one of those or those, then it's off. But that's ‑‑ I'm not going to confuse you guys. What I'm going to do is I'm going to show you a tool I wrote using lib ECFS. It's a malware analysis tool that would typically be pretty sophisticated to write and see. And not that you can see all this, but this is essentially ‑‑ this is the code for it. It's like 55 lines of code. This can detect shared library was injected if it was preloaded. And then if the functions were hijacked in the global offset table. So let's run that. Detect PLT hooks on cores. And so you can see it found the preloaded shared libraries. And it found function hooks. So it says that unlink, open dir, and f open were all hooked. We're all hijacked. So very quickly, in both scenarios, you know, it took about 30 seconds to take an ECFS snapshot and identify that there was an infection. And as somebody who has done a lot of reverse engineering and analysis of process memory by hand, I can tell you that this makes it much, much easier. And this particular ECFS core technology is reliable. So it doesn't do all the work for you, but it does a lot of it for you. And I could see it being adopted heavily by memory analysis tools, forensics tools, and things that want to have a more accurate and colored view of a process. So lastly here, what I would like to show, well, yeah, I've already kind of talked about the Libby CFS, but I'm going to move forward here. So snapshot execution. So what I'll demo here is a simple program, because this can just kind of show you that we're going to snapshot a process. The process is going to be reading and printing from the password file. So we'll snapshot it about halfway through, and then we'll restart it, and it'll continue where it left off. So this demonstrates that it was restoring the file streams, essentially. Now, let's see here. Okay. So this program read pass. I'm just going to run it, see it printing. It's doing its thing. Now here we'll deal kill-11, pit of read pass. Okay. I'll go over here. So it printed out, you know, the first eight or so. And we've got the snapshot. So we're going to use ECFS exec. So we've got to first copy it over. Let's see here. These files are all root because they were created by ECFS. So cores read pass and we'll copy it to ECFS exec. Example. And so we see that read pass dot 2926. So that was a process. We snapshotted it. Now we want to run it and let it begin where it left off. So we'll do exec, read pass. There's a little debugging output. Oh, we got to pseudo that. Exec. We'll do exec, read. Read pass dot 2926. And it started where it left off. So essentially what that did is, you know, that dot fd info section has all the file descriptor information, pipe information, socket information. Now if that password file was removed from the system, this wouldn't work because it doesn't keep state of all the actual files. It only keeps the state of where it was accessing within the file. Now further research and development into this project, it wouldn't be too difficult to come up with some interesting ways of retaining that state like virtual machines do. Virtual machines have everything. It's a little different with the process because processes aren't self-contained. They rely on the environment. But this has implications of doing things like live process migration or high availability computing or different types of fuzzing or if you want to be able to snapshot a piece of malware like I mentioned earlier and then relaunch it on a system that's sandboxed and safe to run it on. Let it start where it left off. So open source project as well. Something I plan to get more time on eventually and take to the next level. So these are the get hubs. So ECFS, that is the straightforward ECFS code, the core handler, the snapshot utility. It's pretty easy to install and set up on your system. So you can just start collecting ECFS core files instead of core files. And ECFS exec is at a separate repository and it's just a small bit of code. And then Saruman was the anti-frenzics exec tool. And anyway, does anybody have any questions at all? You can also come up to me after the talk. But I will be happy to answer any if there are any right now. Yes, in the white. I believe the question was how specific is this to Linux and could it be ported to other unixes? So the answer to that is this should be able to be ported to other unixes such as free BSD. Most of the stuff that makes this specific to Linux, because it is just the elf format, it's the elf core format. But what makes it specific to Linux is the procpid directory is set up a little bit differently than the free BSD proc file system. Because ECFS does get information from procpid. Also, I don't think the snapshot utility uses ptrace and the implementation is slightly different in free BSD. But this should be able to be ported to all other unixes that are using the elf file format provided on one level or another. Linux has a very fruitful proc file system. Free BSDs is okay. So should definitely be portable. I think there was a couple other questions. The blue right there. Thank you. Do I just start from the beginning? Sure. So the question was related to the exec functionality and namely whether it works with processes that generate code dynamically like a JIT or some antivirus engine that are loaded dynamically? Yeah. That's a really good question. And I don't totally know. I do know that the JCR section in an elf binary contains a lot of Java classes and things like that. I think that that would be something that is definitely on the path for exploration. I haven't gone that far yet. But I think it would be something worthwhile looking into and could probably be worked on. But yeah. So I don't know. Sure. Yes. Sorry. Can you hear me? Yes. So by your statement that it's elf specific, is that architecture, is it CPU architecture agnostic? It is. Not this particular implementation. But it could be ported. Yes. Yeah. Right there on the, right there. First of all, thank you. This is amazing. And do you, with your research and writing this library, do you see a path to automatically remove injected code at run time? Well, I would typically see that being more the role of the software that's using ECFS. Since ECFS tends, my vision for it anyways is it is a piece that should be implemented into existing tools that may be already do that. So my DARPA project detected and disinfected. So it actually did remove the injection. And ECFS would be something that I would want to use for that. So ECFS is more like use this with your project for the detection components and then your project would maybe do the disinfection. Yeah. Any final questions? So when you were reading the password file and then you killed the process and then you have a new process that picks up where it left off. Yes. So is ECFS or was the exec it? It saw the FD info. But then it has to make a new open call. But then it uses the existing information to pick up. Like I was just wondering is that a new socket or a new file descriptor? Well, I did make sure to use the actual same file descriptor number. So it actually pays attention if it's FD3, FD4. Then it does do an open and an L seek to get to the offset. Yeah. But you still have to go to the kernel to say like, hey, do an open sys call, right? Yes. Okay. Yep. Yes. In the blue right there. I partially heard if you could clarify one more time. Sorry on the mic. Thanks. The question was whether you can snapshot and then restart pairs of processes like a parent that creates that forks to a child and then you want them both snapshotted and restarted. And particularly if they communicate using say pipes, anonymous pipes. I have thought about how to go about performing the implementation of that. I have some notes on that, but I haven't actually done it yet. So the possibility is there. It's just not implemented yet. And I think we're virtually out of time here. So thank you. Please exit out the back. Straight out the back. Thank you.