search

kd8bny / LiMEaide

A python application designed to remotely dump RAM of a Linux client and create a volatility profile for later analysis on your local host.
https://kd8bny.github.io/LiMEaide/
GNU General Public License v3.0
161 stars 45 forks source link

Fedora 24 LiME/insmod error #15

Closed fligi7 closed 7 years ago

fligi7 commented 7 years ago

Me thinks I've done this correctly, but apparently not...

$ git clone https://github.com/kd8bny/LiMEaide $ mkdir LiMEaide/tools/ $ wget https://github.com/kd8bny/LiME/archive/v1.7.8.zip $ unzip v1.7.8.zip -d LiMEaide/tools/ $ mv LiMEaide/tools/LiME-1.7.8/ LiMEaide/tools/LiME $ python3 LiMEaide/limeaide.py <IP>

Please download LiME and place in the ./tools/ dir

$ ls -l LiMEaide/tools/

drwxrwxr-x. 4 user user 4096 Jun 15 02:21 LiME

What have I done wrong here?

kd8bny commented 7 years ago

ahhh do this cd LiMEaide python3 limeaide.py <IP>

The directories work by relative path at this moment

fligi7 commented 7 years ago

Got it, but now have another issue:

...

4.10.10-100.fc24.x86_64 x86_64 building kernel module make -C /lib/modules/4.10.10-100.fc24.x86_64/build M="/home/user/.limeaide" modules make[1]: Entering directory '/usr/src/kernels/4.10.10-100.fc24.x86_64+debug' make[2]: No rule to make target '/home/user/.limeaide/tcp.o', needed by '/home/user/.limeaide/lime.o'. Stop. Makefile:1494: recipe for target 'module/home/user/.limeaide' failed make[1]: [module/home/user/.limeaide] Error 2 make[1]: Leaving directory '/usr/src/kernels/4.10.10-100.fc24.x86_64+debug' Makefile:33: recipe for target 'default' failed make: *** [default] Error 2 Error deploying LiMEaide :(

kd8bny commented 7 years ago

Sorry about that. I didnt have a proper LiME release tagged Remove the LiME directory in ./tools/ and replace it with version 1.7.8.1 https://github.com/kd8bny/LiME/releases/tag/v1.7.8.1 Ill update the readme soon.

I feel like there needs to be a better naming convention to differ my LiME from upstream. Thanks for the issue!

fligi7 commented 7 years ago

Done. Now the following error:

building kernel module make -C /lib/modules/4.10.10-100.fc24.x86_64/build CONFIG_DEBUG_INFO=y M="/home/user/.limeaide" modules make[1]: Entering directory '/usr/src/kernels/4.10.10-100.fc24.x86_64+debug' CC [M] /home/user/.limeaide/disk.o CC [M] /home/user/.limeaide/main.o LD [M] /home/user/.limeaide/lime.o Building modules, stage 2. MODPOST 1 modules CC /home/user/.limeaide/lime.mod.o LD [M] /home/user/.limeaide/lime.ko make[1]: Leaving directory '/usr/src/kernels/4.10.10-100.fc24.x86_64+debug' Installing LKM and retrieving RAM

insmod: ERROR: could not insert module ./.limeaide/lime-fedora-24-workstation-edition-4.10.10-100.fc24.x86_64-x86_64.ko: Invalid module format Error deploying LiMEaide :(

Looks like it's related to: https://github.com/kd8bny/LiMEaide/blob/2e50ade71b7de6324ceb68b70ffd735fd14361ea/lib/deploy_lime.py#L49 Perhaps the single quotes aren't what it's expecting for the path and format options, the variables aren't being expanded properly, or something is in there that's not getting properly escaped?

As an aside, you don't need to specify 'dio=0' as 0 is the default when not specified.

kd8bny commented 7 years ago

hmmmm. Well that is a installment error for the LKM using insmod. Typically it means that the compiled module was built using source of a different kernel version.

Sometimes yum will install older kernel headers then what the running kernel version is. Do you have the kernel headers installed? You can check the version with yum info kernel-headers

You can install them via this command sudo yum install "kernel-devel-uname-r == $(uname -r)" and sudo yum install "kernel-headers-uname-r == $(uname -r)"

Let me know the result!

fligi7 commented 7 years ago

Seems it may not be a tool issue, as I can't seem to run it natively on the target either. KO builds fine, just like we saw with this tool, but I get the same error when doing the insmod collection myself manually.

$ uname -r

4.11.12-100.fc24.x86_64

$ dnf info kernel-headers

Fedora 24 - x86_64 - Updates 1.7 MB/s | 24 MB 00:13 CERT Forensics Tools Repository - Splunk 298 kB/s | 71 kB 00:00 Fedora 24 - x86_64 3.1 MB/s | 47 MB 00:14 CERT Forensics Tools Repository 1.6 MB/s | 570 kB 00:00 Installed Packages Name : kernel-headers Arch : x86_64 Epoch : 0 Version : 4.11.12 Release : 100.fc24 Size : 4.0 M Repo : @System From repo : updates Summary : Header files for the Linux kernel for use by glibc URL : http://www.kernel.org/ License : GPLv2 and Redistributable, no modification permitted Description : Kernel-headers includes the C header files that specify the interface : between the Linux kernel and userspace libraries and programs. The : header files define structures and constants that are needed for : building most standard programs and are also needed for rebuilding the : glibc package.

$ dnf info kernel-devel

Last metadata expiration check: 0:14:32 ago on Fri Sep 8 18:17:18 2017. Available Packages Name : kernel-devel Arch : x86_64 Epoch : 0 Version : 4.11.12 Release : 100.fc24 Size : 11 M Repo : updates Summary : Development package for building kernel modules to match the kernel URL : http://www.kernel.org/ License : GPLv2 and Redistributable, no modification permitted Description : This package provides kernel headers and makefiles sufficient to build modules : against the kernel package.

$ ls -l /lib/modules/4.11.12-100.fc24.x86_64/

total 14448 lrwxrwxrwx. 1 root root 47 Sep 8 17:22 build -> /usr/src/kernels/4.11.12-100.fc24.x86_64+debug/ ...

$ ls -l /usr/src/kernels/

total 12 drwxr-xr-x. 23 root root 4096 Sep 7 20:02 4.10.10-100.fc24.x86_64+debug drwxr-xr-x. 23 root root 4096 Sep 6 22:16 4.11.12-100.fc24.x86_64+debug drwxr-xr-x. 23 root root 4096 Apr 24 16:04 4.9.13-100.fc24.x86_64+debug

$ ls -l /usr/src/kernels/4.11.12-100.fc24.x86_64+debug/

total 5028 drwxr-xr-x. 33 root root 4096 Sep 6 22:15 arch drwxr-xr-x. 3 root root 4096 Sep 6 22:15 block drwxr-xr-x. 2 root root 4096 Sep 6 22:16 certs drwxr-xr-x. 4 root root 4096 Sep 6 22:15 crypto drwxr-xr-x. 129 root root 4096 Sep 6 22:15 drivers drwxr-xr-x. 2 root root 4096 Sep 6 22:16 firmware drwxr-xr-x. 74 root root 4096 Sep 6 22:16 fs drwxr-xr-x. 30 root root 4096 Sep 6 22:16 include drwxr-xr-x. 2 root root 4096 Sep 6 22:16 init drwxr-xr-x. 2 root root 4096 Sep 6 22:16 ipc -rw-r--r--. 3 root root 252 Apr 13 01:09 Kconfig drwxr-xr-x. 16 root root 4096 Sep 6 22:16 kernel drwxr-xr-x. 12 root root 4096 Sep 6 22:16 lib -rw-r--r--. 1 root root 59267 Jul 21 17:32 Makefile drwxr-xr-x. 3 root root 4096 Sep 6 22:17 mm -rw-r--r--. 1 root root 1216942 Jul 21 17:32 Module.symvers drwxr-xr-x. 67 root root 4096 Sep 6 22:16 net drwxr-xr-x. 26 root root 4096 Sep 6 22:16 samples drwxr-xr-x. 14 root root 4096 Sep 6 22:16 scripts drwxr-xr-x. 10 root root 4096 Sep 6 22:16 security drwxr-xr-x. 24 root root 4096 Sep 6 22:16 sound -rw-r--r--. 1 root root 3770564 Jul 21 17:32 System.map drwxr-xr-x. 27 root root 4096 Sep 6 22:16 tools drwxr-xr-x. 2 root root 4096 Sep 6 22:16 usr drwxr-xr-x. 4 root root 4096 Sep 6 22:17 virt -rw-r--r--. 1 root root 41 Jul 21 17:32 vmlinux.id

kd8bny commented 7 years ago

interesting... I did notice something. origianlly you were building for 4.10x kernel. Now the output is from 4.11x kernel. Is insmod outputting the same error when building manually? Would you mind outputting that? So then we can see were LiME is pulling its source from. (In the output above LiME is pulling src from 4.10.../build) I cant seem to recreate on Fedora 24 or 25

fligi7 commented 7 years ago

Yeah, that was just because I'd done a kernel update but hadn't rebooted yet. Upon rebooting, I'm now on 4.11x.

Kernel headers were installed for both kernels at the time (plus some manual re-symlinking as the /lib/modules//build links didn't point to the correct /usr/src/ folder). Not sure why I have to do that, nor why the source kernels are in a *+debug folder (don't recall seeing that before). But, I still get the same error when attempting to insmod manually after building the LiME KO myself on the box. So, it's obviously a system issue and not the tool.

kd8bny commented 7 years ago

That is certainly an interesting behavior. I have not yet experienced anything like it. Please let me know what the solution is that you find.

fligi7 commented 7 years ago

Ooook, so... somehow I apparently had the kernel-debug-devel package installed instead of the kernel-devel, thus leading to the source kernels having a "+debug" appended to them and further thus why insmod wasn't liking our KO insertion to grab memory. A little dnf removal, reinstall of the kernel-devel package, making a new KO, and insmod seems happy now.

However, while insmod works locally, it still fails using LiMEaide with the same error...

... 4.11.12-100.fc24.x86_64 x86_64 building kernel module make -C /lib/modules/4.11.12-100.fc24.x86_64/build CONFIG_DEBUG_INFO=y M="/home/user/.limeaide" modules make[1]: Entering directory '/usr/src/kernels/4.11.12-100.fc24.x86_64' Makefile:923: "Cannot use CONFIG_STACK_VALIDATION, please install libelf-dev, libelf-devel or elfutils-libelf-devel" CC [M] /home/user/.limeaide/disk.o CC [M] /home/user/.limeaide/main.o LD [M] /home/user/.limeaide/lime.o Building modules, stage 2. MODPOST 1 modules LD [M] /home/user/.limeaide/lime.ko make[1]: Leaving directory '/usr/src/kernels/4.11.12-100.fc24.x86_64' Installing LKM and retrieving RAM

insmod: ERROR: could not insert module ./.limeaide/lime-fedora-24-workstation-edition-4.11.12-100.fc24.x86_64-x86_64.ko: Invalid module format Error deploying LiMEaide :(

kd8bny commented 7 years ago

That makes sense now. Just to clear it up a tad more are you using my version of LiME manually on the system?

fligi7 commented 7 years ago

Yes, sir. Downloaded, extracted, and using your version as specified in the instructions on the tool page. Currently using the version you referred to here: https://github.com/kd8bny/LiMEaide/issues/15#issuecomment-327934009

kd8bny commented 7 years ago

Whats the dmesg output after the install attempt?

fligi7 commented 7 years ago

Just looked at dmesg, saw the following line:

lime: version magic '4.11.12-100.fc24.x86_64+debug SMP mod_unload ' should be '4.11.12-100.fc24.x86_64 SMP mod_unload '

On a hunch (that for some reason LiMEaide was reusing an already built/old KO instead of rebuilding it each time it's run), I deleted the target's .limeaide/ directory, re-ran the tool, and it seems to be working now.

SUCCESS!

So, from a tool dev perspective, looks like you may also want to include some logic that the target .limeaide directory is deleted/rebuilt each time the tool is run to avoid using stale KO's.

fligi7 commented 7 years ago

Also, for proper cleanup, make sure you are removing the KO post-capture. I don't see an "rmmod lime" in your deploylime.py code, but perhaps it is occurring somewhere else?

Or, better yet, include a CL option for the tool that specifies whether or not the user wants to attempt the rmmod for cleanup (sometimes you may not want to for system stability issues).

kd8bny commented 7 years ago

Great! Im glad it worked ahhhh that makes sense now. It was using the old ko. the --force-clean attribute will do cleaning for you and rmmod the module. Currently the cleanup functions exist in the session class. I definitly need to catch a failed depolyment and cleanup

Please let me know of any other feedback you have! If you find the tool useful contact me if needed/wanted -> kd8bny at gmail dot com