已归档项目!仓库和其他项目资源均为只读
autopsy
-
- autopsy == sleuthkit + java GUI (以netbeans为骨架?) + solr搜索 等各种库,甚至有用到testdisk,可以说是各种大杂烩
-
- sleuthkit == cpp 解析各种文件系统 等功能 + java包装(jni+java调用jni)
autopsy 整体上是java GUI项目,调用sleuthkit的java包装以实现磁盘能力
理论上,按照 Linux下autopsy安装手册 安装 autopsy后,
启动 autopsy GUI后 用netbeans打开autopsy的源码目录,应该可以用netbeans远程attach到autopsy GUI进程
但注意 autopsy GUI不是直接以java.exe启动的 而是以 autospy安装目录/platform/lib/nbexec 启动的,
注意同样有netbeans暗黄目录/platform/lib/nbexec
autopsy 安装、启动过程 (Ubuntu22.04x64)
0. 下载autopsy Linux 安装包
mkdir app/autopsy-home/; cd /app/autopsy-home/
wget https://github.com/sleuthkit/autopsy/releases/download/autopsy-4.20.0/autopsy-4.20.0.zip
unzip autopsy-4.20.0.zip
file /app/autopsy-home/autopsy-4.20.0.zip
#/app/autopsy-home/autopsy-4.20.0.zip: Zip archive data, at least v1.0 to extract, compression method=store
ls /app/autopsy-home/autopsy-4.20.0/
#autopsy CoreTestLibs etc icon.ico LICENSE-2.0.txt NEWS.txt README.txt unix_setup.sh
# bin docs harness java linux_macos_install_scripts platform Running_Linux_OSX.md
1. Installing Prerequisites (jdk8)
bash -x /app/autopsy-home/autopsy-4.20.0/linux_macos_install_scripts/install_prereqs_ubuntu.sh
#安装了bellsoft-java8-full, 据说是带了javaFX. autopsy用的JAVA GUI即javaFX?
/usr/lib/jvm/bellsoft-java8-full-amd64/bin/javac -version
#javac 1.8.0_372
2. Installing The Sleuth Kit
- 下载Sleuth Linux .deb安装包
cd /app/autopsy-home/
wget https://github.com/sleuthkit/sleuthkit/releases/download/sleuthkit-4.12.0/sleuthkit-java_4.12.0-1_amd64.deb
sudo apt update && sudo apt install /app/autopsy-home/sleuthkit-java_4.12.0-1_amd64.deb
#安装结果
ldconfig -p | grep tsk
# libtsk_jni.so.0 (libc6,x86-64) => /lib/x86_64-linux-gnu/libtsk_jni.so.0
# libtsk_jni.so (libc6,x86-64) => /lib/x86_64-linux-gnu/libtsk_jni.so
# libtsk.so.19 (libc6,x86-64) => /lib/x86_64-linux-gnu/libtsk.so.19
# libtsk.so (libc6,x86-64) => /lib/x86_64-linux-gnu/libtsk.so
3.Installing Autopsy
######sudo rm -fr ~/.autopsy/
/app/autopsy-4.20.0-install/linux_macos_install_scripts/install_application.sh -z /app/autopsy-home/autopsy-4.20.0.zip -i /app/autopsy-home/ -j /usr/lib/jvm/bellsoft-java8-full-amd64/
4.启动autopsy
export JAVA_HOME=/usr/lib/jvm/bellsoft-java8-full-amd64/
export PATH=$JAVA_HOME/bin:$PATH
which java
#/usr/lib/jvm/bellsoft-java8-full-amd64//bin/java
sudo bash -x /app/autopsy-home/autopsy-4.20.0/bin/autopsy
#等同于以下命令:
sudo /app/autopsy-home/autopsy-4.20.0/bin/../platform/lib/nbexec --jdkhome /usr/lib/jvm/bellsoft-java8-full-amd64/ --clusters /app/autopsy-home/autopsy-4.20.0/autopsy:/app/autopsy-home/autopsy-4.20.0/CoreTestLibs:/app/autopsy-home/autopsy-4.20.0/harness:/app/autopsy-home/autopsy-4.20.0/java: --userdir /root/.autopsy/dev --branding autopsy -J-Xms24m -J-Xmx4G -J-Xverify:none -J-XX:+UseG1GC -J-XX:+UseStringDeduplication -J-Dprism.order=sw -J-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=0.0.0.0:5005
#有打印:
#SleuthkitJNI: loaded libtsk_jni
#说明找到了libSleuthkitJNI.so
#正常启动
#need:
chmod +x /app/autopsy-home/autopsy-4.20.0/platform/lib/nbexec
注意 :
可能要注意这几点
- 启动一个autopsy后 ,第二个autopsy肯定启动报错
- 同理,若启动了netbeans ,很可能autopsy也启动不了?
- Linux下 , 如果要选真磁盘(比如u盘), 启动autopsy必须 sudo /app/autopsy-home/autopsy-4.20.0/platform/lib/nbexec .... ,否则没权限选择真磁盘
提前执行:
chmod +x /app/autopsy-home/autopsy-4.20.0/platform/lib/nbexec
提醒
autopsy启动了哪些进程? 3个nbexec、1个jvm
ps auxf
#手工找到autopsy的进程们(3个nbexec、1个jvm),如下:
root 58819 | \_ sudo /app/autopsy-home/autopsy-4.20.0/platform/lib/nbexec --jdkhome /usr/lib/jvm/bellsoft-java
root 58820 | \_ sudo /app/autopsy-home/autopsy-4.20.0/platform/lib/nbexec --jdkhome /usr/lib/jvm/bellsoft-
root 58821 | \_ /bin/sh /app/autopsy-home/autopsy-4.20.0/platform/lib/nbexec --jdkhome /usr/lib/jvm/be
root 58889 | \_ /usr/lib/jvm/bellsoft-java8-full-amd64/bin/java -Djdk.home=/usr/lib/jvm/bellsoft-j
ps auxf | grep java #这些进程的完成命令行如下:
root 58819 sudo /app/autopsy-home/autopsy-4.20.0/platform/lib/nbexec --jdkhome /usr/lib/jvm/bellsoft-java8-full-amd64/ --clusters /app/autopsy-home/autopsy-4.20.0/autopsy:/app/autopsy-home/autopsy-4.20.0/CoreTestLibs:/app/autopsy-home/autopsy-4.20.0/harness:/app/autopsy-home/autopsy-4.20.0/java: --userdir /home/zz/.autopsy/dev --branding autopsy -J-Xms24m -J-Xmx4G -J-Xverify:none -J-XX:+UseG1GC -J-XX:+UseStringDeduplication -J-Dprism.order=sw
root 58820 sudo /app/autopsy-home/autopsy-4.20.0/platform/lib/nbexec --jdkhome /usr/lib/jvm/bellsoft-java8-full-amd64/ --clusters /app/autopsy-home/autopsy-4.20.0/autopsy:/app/autopsy-home/autopsy-4.20.0/CoreTestLibs:/app/autopsy-home/autopsy-4.20.0/harness:/app/autopsy-home/autopsy-4.20.0/java: --userdir /home/zz/.autopsy/dev --branding autopsy -J-Xms24m -J-Xmx4G -J-Xverify:none -J-XX:+UseG1GC -J-XX:+UseStringDeduplication -J-Dprism.order=sw
root 58821 /bin/sh /app/autopsy-home/autopsy-4.20.0/platform/lib/nbexec --jdkhome /usr/lib/jvm/bellsoft-java8-full-amd64/ --clusters /app/autopsy-home/autopsy-4.20.0/autopsy:/app/autopsy-home/autopsy-4.20.0/CoreTestLibs:/app/autopsy-home/autopsy-4.20.0/harness:/app/autopsy-home/autopsy-4.20.0/java: --userdir /home/zz/.autopsy/dev --branding autopsy -J-Xms24m -J-Xmx4G -J-Xverify:none -J-XX:+UseG1GC -J-XX:+UseStringDeduplication -J-Dprism.order=sw
root 58889 /usr/lib/jvm/bellsoft-java8-full-amd64/bin/java -Djdk.home=/usr/lib/jvm/bellsoft-java8-full-amd64 -classpath /app/autopsy-home/autopsy-4.20.0/platform/lib/boot.jar:/app/autopsy-home/autopsy-4.20.0/platform/lib/org-openide-modules.jar:/app/autopsy-home/autopsy-4.20.0/platform/lib/org-openide-util-lookup.jar:/app/autopsy-home/autopsy-4.20.0/platform/lib/org-openide-util-ui.jar:/app/autopsy-home/autopsy-4.20.0/platform/lib/org-openide-util.jar:/usr/lib/jvm/bellsoft-java8-full-amd64/lib/dt.jar:/usr/lib/jvm/bellsoft-java8-full-amd64/lib/tools.jar -Dnetbeans.dirs=/app/autopsy-home/autopsy-4.20.0/autopsy:/app/autopsy-home/autopsy-4.20.0/CoreTestLibs:/app/autopsy-home/autopsy-4.20.0/harness:/app/autopsy-home/autopsy-4.20.0/java: -Dnetbeans.home=/app/autopsy-home/autopsy-4.20.0/platform -Xms24m -Xmx4G -Xverify:none -XX:+UseG1GC -XX:+UseStringDeduplication -Dprism.order=sw -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/zz/.autopsy/dev/var/log/heapdump.hprof org.netbeans.Main --cachedir /home/zz/.autopsy/dev/var/cache --userdir /home/zz/.autopsy/dev --branding autopsy
#注意看此进程 是真java进程(jvm进程)
autopsy的jvm进程用的jar和so
autopsy的jvm进程pid
#autopsy的jvm进程命令行中有openide字符串 ,据此 找到autopsy的jvm进程id:
for pid in `pidof java `; do grep openide /proc/$pid/cmdline && autopsy_pid=$pid; done
#比如,autopsy_pid 为 87542
autopsy的jvm进程用的jar
#autopsy的jvm进程用的jar
sudo lsof -p $autopsy_pid | grep app | grep ".jar" |tr -s " "| cut -d" " -f 9 > ./autopsy_process_open_jars.txt
autopsy的jvm进程用的 so
#autopsy的jvm进程用的 so: libtsk.so、libtsk_jni*.so 的完整路径
sudo lsof -p $autopsy_pid | grep "\.so" | grep "tsk"
#java 10846 root mem REG 259,7 1168752 274026 /usr/lib/x86_64-linux-gnu/libtsk.so.19.2.0
#java 10846 root mem REG 259,3 1132688 80 /tmp/libtsk_jni_root.so
autopsy 中 jni.so依赖 (linux)
cd /app/autopsy-home/autopsy-4.20.0/
find . -name *.jar | xargs -I% sh -c "jar -tvf % |grep NATIV && echo %"
# NATIVELIBS/amd64/linux/libtsk_jni.so
#./autopsy/modules/ext/sleuthkit-4.12.0.jar
unzip ./autopsy/modules/ext/sleuthkit-4.12.0.jar -d /tmp/t/
readelf -d /tmp/t/NATIVELIBS/x86_64/linux/libtsk_jni.so | grep tsk
# 0x0000000000000001 (NEEDED) 共享库:[libtsk.so.19]
ldconfig -p | grep tsk
#libtsk_jni.so.0 (libc6,x86-64) => /lib/x86_64-linux-gnu/libtsk_jni.so.0
#libtsk_jni.so (libc6,x86-64) => /lib/x86_64-linux-gnu/libtsk_jni.so
#libtsk.so.19 (libc6,x86-64) => /lib/x86_64-linux-gnu/libtsk.so.19
#libtsk.so (libc6,x86-64) => /lib/x86_64-linux-gnu/libtsk.so #关注这一条
/lib/x86_64-linux-gnu/libtsk.so 是被 autopsy下载页面 中的 安装包 sleuthkit-java_4.12.0-1_amd64.deb 安装到ubuntu22.04中的 所以 linux下的libtsk.so 对应 windows下的什么?
调试autospy(java)
以调试模式启动autopsy
# 以调试模式启动autopsy ,
# 注意 跟上面的启动命令相比 只是在后面加了 -J-agentlib:jdwp=....
sudo /app/autopsy-home/autopsy-4.20.0/bin/../platform/lib/nbexec --jdkhome /usr/lib/jvm/bellsoft-java8-full-amd64/ --clusters /app/autopsy-home/autopsy-4.20.0/autopsy:/app/autopsy-home/autopsy-4.20.0/CoreTestLibs:/app/autopsy-home/autopsy-4.20.0/harness:/app/autopsy-home/autopsy-4.20.0/java: --userdir /root/.autopsy/dev --branding autopsy -J-Xms24m -J-Xmx4G -J-Xverify:none -J-XX:+UseG1GC -J-XX:+UseStringDeduplication -J-Dprism.order=sw -J-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=0.0.0.0:5005
#注意 -agentlib:jdwp=... 前面加了 -J 显然 这是表示 当前的程序nbexec 传递给jvm的参数
#注意 sudo ... /root/.autopsy 正常启动 , 而 sudo ... /home/zz/.autopsy 会启动到一半并卡住不动 即启动失败
#autopsy正常启动
以jdb或netbeans或idea等连接到上面的调试端口
#以jdb或netbeans或idea等连接到上面的调试端口,
# 下面以jdb为例
export JAVA_HOME=/usr/lib/jvm/bellsoft-java8-full-amd64/
export PATH=$JAVA_HOME/bin:$PATH #这两行export应该是不必要的,加上只是保险起见
jdb -attach 5005 #注意调试方不需要root权限,因为连接的是tcp端口号 而非进程号
最好以同样的jdk(bellsoft-java8-full-amd64) 运行idea
idea附加到调试运行的autopsy 见: idea_debug_autopsy
#运行idea前,也需要设置:
export JAVA_HOME=/usr/lib/jvm/bellsoft-java8-full-amd64/
export PATH=$JAVA_HOME/bin:$PATH
/app/idea-IU--2021.2.3--212.5457.46/bin/idea.sh
编译sleuth(c++)并gdb attach到java以调试libtsk_jni.so
编译准备
统一使用bellsoft-java8-full:
export JAVA_HOME=/usr/lib/jvm/bellsoft-java8-full-amd64/
export PATH=$JAVA_HOME/bin:$PATH
正式编译 调试版 libtsk.so
编译过程
注意只有Makefile.am 如何构建, 参考:概念:GNU构建系统和Autotool
cd /pubx/disk-recovery/sleuthkit/
rm -fr configure
autoreconf --install
#产生文件configure
./configure CPPFLAGS=" -g -O0"
make
查看编译结果:
cd /pubx/disk-recovery/sleuthkit/
find . -name *tsk*.so.* -o -name *tsk*.so | xargs -I@ ls -lh @
lrwxrwxrwx 1 zz zz 16 7月 1 09:53 ./tsk/.libs/libtsk.so -> libtsk.so.19.2.0
lrwxrwxrwx 1 zz zz 16 7月 1 09:53 ./tsk/.libs/libtsk.so.19 -> libtsk.so.19.2.0
-rwxrwxr-x 1 zz zz 8.8M 7月 1 09:53 ./tsk/.libs/libtsk.so.19.2.0
-rw-rw-r-- 1 zz zz 1.1M 7月 1 10:00 ./bindings/java/build/NATIVELIBS/x86/linux/libtsk_jni.so
-rw-rw-r-- 1 zz zz 1.1M 7月 1 10:00 ./bindings/java/build/NATIVELIBS/i686/linux/libtsk_jni.so
-rw-rw-r-- 1 zz zz 1.1M 7月 1 10:00 ./bindings/java/build/NATIVELIBS/amd64/linux/libtsk_jni.so
-rw-rw-r-- 1 zz zz 1.1M 7月 1 10:00 ./bindings/java/build/NATIVELIBS/i386/linux/libtsk_jni.so
-rw-rw-r-- 1 zz zz 1.1M 7月 1 10:00 ./bindings/java/build/NATIVELIBS/x86_64/linux/libtsk_jni.so
-rw-rw-r-- 1 zz zz 1.1M 7月 1 10:00 ./bindings/java/build/NATIVELIBS/i586/linux/libtsk_jni.so
lrwxrwxrwx 1 zz zz 19 7月 1 09:53 ./bindings/java/jni/.libs/libtsk_jni.so -> libtsk_jni.so.0.0.0
-rwxrwxr-x 1 zz zz 1.1M 7月 1 09:53 ./bindings/java/jni/.libs/libtsk_jni.so.0.0.0
lrwxrwxrwx 1 zz zz 19 7月 1 09:53 ./bindings/java/jni/.libs/libtsk_jni.so.0 -> libtsk_jni.so.0.0.0
作为对比 看一下 前文安装sleuthkit-java_4.12.0-1_amd64.deb 后 所产生的libtsk*.so:
ldconfig -p | grep *tsk*
libtsk_jni.so.0 (libc6,x86-64) => /lib/x86_64-linux-gnu/libtsk_jni.so.0
libtsk_jni.so (libc6,x86-64) => /lib/x86_64-linux-gnu/libtsk_jni.so
libtsk.so.19 (libc6,x86-64) => /lib/x86_64-linux-gnu/libtsk.so.19
libtsk.so (libc6,x86-64) => /lib/x86_64-linux-gnu/libtsk.so
ls -lh /lib/x86_64-linux-gnu/libtsk*.so*
lrwxrwxrwx 1 root root 19 1月 31 2018 /lib/x86_64-linux-gnu/libtsk_jni.so -> libtsk_jni.so.0.0.0
lrwxrwxrwx 1 root root 19 1月 31 2018 /lib/x86_64-linux-gnu/libtsk_jni.so.0 -> libtsk_jni.so.0.0.0
-rw-r--r-- 1 root root 179K 1月 31 2018 /lib/x86_64-linux-gnu/libtsk_jni.so.0.0.0
lrwxrwxrwx 1 root root 16 1月 31 2018 /lib/x86_64-linux-gnu/libtsk.so -> libtsk.so.19.2.0
lrwxrwxrwx 1 root root 16 1月 31 2018 /lib/x86_64-linux-gnu/libtsk.so.19 -> libtsk.so.19.2.0
-rw-r--r-- 1 root root 1.2M 1月 31 2018 /lib/x86_64-linux-gnu/libtsk.so.19.2.0
替换系统自带release版*tsk.so为编译的debug版so
查看启动后autopsy所用的so文件
#启动安装好的 autopsy
for pid in `pidof java `; do grep openide /proc/$pid/cmdline && autopsy_pid=$pid; done
#autopsy_pid:87542
sudo lsof -p $autopsy_pid | grep "\.so" | grep "tsk"
#java 10846 root mem REG 259,7 1168752 274026 /usr/lib/x86_64-linux-gnu/libtsk.so.19.2.0
#java 10846 root mem REG 259,3 1132688 80 /tmp/libtsk_jni_root.so
ldconfig -p | grep *tsk*
# libtsk_jni.so.0 (libc6,x86-64) => /lib/x86_64-linux-gnu/libtsk_jni.so.0
# libtsk_jni.so (libc6,x86-64) => /lib/x86_64-linux-gnu/libtsk_jni.so
# libtsk.so.19 (libc6,x86-64) => /lib/x86_64-linux-gnu/libtsk.so.19
# libtsk.so (libc6,x86-64) => /lib/x86_64-linux-gnu/libtsk.so
#但是 启动的autopsy使用的却是 /usr/lib/x86_64-linux-gnu/{libtsk.so.19.2.0,libtsk_jni_root.so} ,而非 目录 /lib/x86_64-linux-gnu/下的同名so
ls -lh /usr/lib/x86_64-linux-gnu/libtsk.so /usr/lib/x86_64-linux-gnu/libtsk_jni.so
#lrwxrwxrwx 1 root root 41 7月 1 11:27 /usr/lib/x86_64-linux-gnu/libtsk_jni.so -> /lib/x86_64-linux-gnu/libtsk_jni.so.0.0.0
#lrwxrwxrwx 1 root root 38 7月 1 11:27 /usr/lib/x86_64-linux-gnu/libtsk.so -> /lib/x86_64-linux-gnu/libtsk.so.19.2.0
奏效的替换
替换:
sudo mv /usr/lib/x86_64-linux-gnu/libtsk.so.19.2.0 /usr/lib/x86_64-linux-gnu/libtsk.so.19.2.0.release
sudo cp /pubx/disk-recovery/sleuthkit/tsk/.libs/libtsk.so.19.2.0 /usr/lib/x86_64-linux-gnu/libtsk.so.19.2.0
gdb附加
gdb attach:
for pid in `pidof java `; do grep openide /proc/$pid/cmdline && autopsy_pid=$pid; done
sudo gdb -p $autopsy_pid
#打开了gdb调试jvm进程的命令终端
gdb调试(断点)
本小节 基于 上一节 "gdb附加" 打开的gdb调试jvm进程的命令终端
gdb命令终端中遇到自己停止的如下情形一律
continue
过去:
- Thread 1 "java" received signal SIGINT, Interrupt.
- __futex_abstimed_wait_common64
break fatfs_open
backtrace
#0 fatfs_open (a_img_info=0x7fbb8c03e510, a_offset=0, a_ftype=TSK_FS_TYPE_FAT_DETECT, a_test=1 '\001') at fatfs.c:34
#1 0x00007fbcc4b303af in tsk_fs_open_img_decrypt (a_img_info=0x7fbb8c03e510, a_offset=0, a_ftype=<optimized out>, a_pass=<optimized out>) at fs_open.c:186
#2 0x00007fbcc4bac620 in TskAuto::findFilesInFsRet (this=0x7fbb74010cb0, a_start=0, a_ftype=<optimized out>) at auto.cpp:578
#3 0x00007fbcc4bac7de in TskAuto::vsWalkCb (a_ptr=0x7fbb74010cb0, a_vs_part=0x7fbb740120d0) at auto.cpp:306
#4 TskAuto::vsWalkCb (a_vs_part=0x7fbb740120d0, a_ptr=0x7fbb74010cb0) at auto.cpp:279
#5 0x00007fbcc4b29ca7 in tsk_vs_part_walk (a_vs=0x7fbb740101a0, a_start=0, a_last=3, a_flags=3, a_action=0x7fbcc4bac750 <TskAuto::vsWalkCb(TSK_VS_INFO*, TSK_VS_PART_INFO const*, void*)>, a_ptr=<optimized out>) at mm_part.c:272
#6 0x00007fbcc4bac8f7 in TskAuto::findFilesInVs (this=this@entry=0x7fbb74010cb0, a_start=a_start@entry=0, a_vtype=a_vtype@entry=TSK_VS_TYPE_DETECT) at auto.cpp:374
#7 0x00007fbcc4baca1b in TskAuto::findFilesInVs (this=this@entry=0x7fbb74010cb0, a_start=a_start@entry=0) at auto.cpp:395
#8 0x00007fbcc4baca42 in TskAuto::findFilesInImg (this=this@entry=0x7fbb74010cb0) at auto.cpp:268
#9 0x00007fbcc4c1759b in TskAutoDbJava::addFilesInImgToDb (this=this@entry=0x7fbb74010cb0) at auto_db_java.cpp:1364
#10 0x00007fbcc4c177f6 in TskAutoDbJava::startAddImage (this=this@entry=0x7fbb74010cb0, img_info=img_info@entry=0x7fbb8c03e510, deviceId=deviceId@entry=0x7fbb74010170 "effccf24-4ba4-4974-9242-0a6415ec3ba6") at auto_db_java.cpp:1463
#11 0x00007fbcc4c104cf in Java_org_sleuthkit_datamodel_SleuthkitJNI_runAddImgNat (env=0x7fbb8c036260, obj=<optimized out>, process=140443081837744, deviceId=0x7fbca77e36a0, a_img_info=<optimized out>, img_id=<optimized out>, timeZone=0x7fbca77e3678, imageWriterPathJ=0x7fbca77e3670) at dataModel_SleuthkitJNI.cpp:1060
#12 0x00007fbd95020a08 in ?? ()
#13 0x00007fbca77e3678 in ?? ()
#14 0x00007fbca77e3670 in ?? ()
#15 0x00007fbcc50abed0 in ?? ()
#16 0x0000000000000000 in ?? ()
info signals SIGSEGV
#Signal Stop Print Pass to program Description
#SIGSEGV Yes Yes Yes Segmentation fault
handle SIGSEGV nostop
#忽略 信号SIGSEGV ,否则即使continue了也一样还会停下来
continue
gdb调试脚本
安装、启动autopsy ,详见: 本文 磁盘数据恢复软件开发计划 和 idea_debug_autopsy
1. 启动autopsy
sudo bash -x /app/autopsy-home/autopsy-4.20.0/bin/autopsy
等同于以下启动命令:
sudo /app/autopsy-home/autopsy-4.20.0/bin/../platform/lib/nbexec --jdkhome /usr/lib/jvm/bellsoft-java8-full-amd64/ --clusters /app/autopsy-home/autopsy-4.20.0/autopsy:/app/autopsy-home/autopsy-4.20.0/CoreTestLibs:/app/autopsy-home/autopsy-4.20.0/harness:/app/autopsy-home/autopsy-4.20.0/java: --userdir /root/.autopsy/dev --branding autopsy -J-Xms24m -J-Xmx4G -J-Xverify:none -J-XX:+UseG1GC -J-XX:+UseStringDeduplication -J-Dprism.order=sw -J-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=0.0.0.0:5005
2. 找到刚刚启动的autopsy的jvm进程pid
for pid in `pidof java `; do grep openide /proc/$pid/cmdline && autopsy_pid=$pid; done
3. gdb带调试脚本附加到该autopsy的jvm进程
sudo gdb -p $autopsy_pid -command=/pubx/disk-recovery/idea_debug_autopsy/gdb_debug_script/autopsy_jvm_libtsk_so.gs
4. 调试脚本产生的日志输出文件
调试脚本产生的日志输出文件: /pubx/disk-recovery/idea_debug_autopsy/autopsy_gdb.log
数据恢复sleuthkit+GUI(msWin10X64)
基于sleuthkit的磁盘或分区列出、文件写db
自己基于autopsy的sleuthkit_jni整理的
手工写好的:idea_debug_autopsy的标签tag_diskOrPartition_list_then_save_file_list_to_sqlite3db_by_jni_sleuthkit
sleuthkit自带的tsk_loaddb.cpp
但后来发现sleuthkit中有现成的:tools/autotools/tsk_loaddb.cpp
编译sleuthkit(win10下vs2017 )
JDK_HOME
JDK_HOME 被 sleuthkit\win32\tsk_jni\tsk_jni.vcxproj 用到 win10设置-->高级系统设置-->环境变量
JDK_HOME=D:\bellsoft-jdk8u372+7-windows-i586\jdk8u372
编译错误解决: NuGet package(s) that are missing
开始菜单 -> "Developer Command Prompt for VS 2017", 执行
d:\disk-recovery\sleuthkit\win32>msbuild tsk-win.sln
, 报错如下:
d:\disk-recovery\sleuthkit\win32\libtsk\libtsk.vcxproj(480,5): error : This project references NuGet package(s) that are missing on this computer. Use
NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is ..\packages\opens
sl-vc140-vc141-x86_64.1.1.5\build\native\openssl-vc140-vc141-x86_64.targets.
报错解决: vs2017安装nuget包生成和管理工具
调试 tsk_loaddb.exe
- vs2017打开 sleuthkit\win32\tsk-win.sln
- vs2017 右击 "Solution 'tsk-win' " --> Rebuild
- vs2017 tsk_loaddb右击-->"Set as Startup Project"
- 调试目标:
tsk_loaddb.exe -d e:\tmp\g.db \\.\G:
, 注意 -d e:\tmp\g.db 和 \.\G: 位置不能换,否则tsk_loadb.exe解析不出来。 - vs2017 tsk_loaddb右击-->Property-->Debugging-->Command Arguments:
-d e:\tmp\g.db \\.\G:
- 用sqlite-db-browser打开e:\tmp\g.db, 其中表tsk_files中若干行记录,每条记录表示一个文件
调试 tsk_recover.exe
- vs2017打开 sleuthkit\win32\tsk-win.sln
- vs2017 右击 "Solution 'tsk-win' " --> Rebuild
- vs2017 tsk_recover右击-->"Set as Startup Project"
- 复制任一文件(这里为adv3.csv)到G:, 再shift delete删除该文件
- 调试目标:
tsk_recover.exe \\.\G: d:\tmp\recover
- vs2017 tsk_recover右击-->Property-->Debugging-->Command Arguments:
\\.\G: d:\tmp\recover
- 目录 d:\tmp\recover\下有被恢复出的文件_dv3.csv,经比较,_dv3.csv和adv3.csv的内容是相同的。即正常恢复。
- 可见,给sleuthkit\win32\tsk_recover\tsk_recover.vcxproj套上一层GUI 就是一个最简易的数据恢复软件。
tsk_recover.dll
- 直接从tsk_recover.exe 改造为 tsk_recover.dll
qt5
pyside2(pyqt类似物)
#打开anaconda 命令行
pip install pyside2
%appdata%\Python\Python310\Scripts\pyside2-designer.exe
#即可打开qt界面设计器 qt designer
物理磁盘列表 (sleuthkit无此代码、autopsy不全且恶心)
简介:
- sleuthkit 中只有 拿某磁盘的分区列表 的代码(就在本文中),没有 拿物理磁盘列表 的代码
- autopsy中以java且很偷懒的样式 :windows下拿不到物理磁盘列表、只拿到分区列表;linux下枚举/dev/下文件以拿到磁盘列表、分区列表
结论: 拿物理磁盘列表 代码 得自己写了
拿物理磁盘列表 以及 某磁盘下分区列表的 代码 只能自己写了
详细描述 sleuthkit、autopsy关于 拿物理磁盘列表 :
1. sleuthkit中 没有拿物理磁盘列表 的代码,
2. autopsy中用java且偷懒且windows不全、linux全
但autopsy以java: win32下拿分区列表(没有物理磁盘列表)、linux下拿物理磁盘列表和分区列表,但样式很偷懒,基本没法用。具体如下:\Core\src\org\sleuthkit\autopsy\coreutils\PlatformUtil.java
//PlatformUtil.java
public static List<LocalDisk> getPhysicalDrives() {//第384行
List<LocalDisk> drives = new ArrayList<>();
// Windows drives
if (PlatformUtil.isWindowsOS()) {
//如果是windows操作系统, 直接依次读文件 \\.\PhysicalDrive0 , \\.\PhysicalDrive1, \\.\PhysicalDrive2, ...
//人为拍脑袋认为,当发生4次读异常,则所有分区都读出来了。
// windows下 文件路径 \\.\PhysicalDriveK 表示 第K个分区(第K个逻辑盘),如果读该路径能读出内容,则间接表示有该分区,这是很偷懒的办法
//应该调用某个api完成才是正道
int n = 0;
int breakCount = 0;
while (true) {
String path = "\\\\.\\PhysicalDrive" + n; //NON-NLS 第K个分区 \\.\PhysicalDriveK
if (canReadDrive(path)) {
try {
drives.add(new LocalDisk("Drive " + n, path, SleuthkitJNI.findDeviceSize(path))); //NON-NLS
} catch (TskCoreException ex) {
// Don't add the drive because we can't read the size
}
n++;
} else {
if (breakCount > 4) { // Give up after 4 non-existent drives
break;
}
breakCount++;
n++;
}
}
// Linux drives
} else {
//如果是Linux操作系统,直接列出设备目录 /dev/下所有文件,找hd、sd、disk开头的 且可读的 且 长度小于5的,
//这些是 磁盘或分区, 磁盘 比如 /dev/hda ,分区比如 /dev/hda1 ,
//Linux下这样是可以拿到磁盘列表、分区列表的,但这显然很偷懒,应该调用某个api完成才是正道。
File dev = new File("/dev/");
File[] files = dev.listFiles();
for (File f : files) {
String name = f.getName();
if ((name.contains("hd") || name.contains("sd") || name.contains("disk")) && f.canRead() && name.length() <= 5) { //NON-NLS
String path = "/dev/" + name; //NON-NLS
if (canReadDrive(path)) {
try {
drives.add(new LocalDisk(path, path, SleuthkitJNI.findDeviceSize(path)));
} catch (TskCoreException ex) {
// Don't add the drive because we can't read the size
}
}
}
}
}
return drives;
}
自己写的 物理磁盘列表、分区列表
某磁盘的分区表
struct TSK_VS_INFO {//第65行
//...
TSK_VS_PART_INFO *part_list; //第75行 ///< Linked list of partitions //分区链表
//...
};
//...
int
main(int argc, char **argv1)//第42行
{
TSK_VS_INFO *vs; //第44行 //vs->part_list 是 分区链表
TSK_PNUM_T pnum; //第50行 //uint32_t pnum; //pnum 分区编号
const TSK_VS_PART_INFO *vs_part; //第52行
if (tsk_parse_pnum(argv[argc - 1], &pnum)) {//第150行 pnum是命令行中给定的
exit(1);
}
/* process the partition tables */
if ((vs = tsk_vs_open(img, imgaddr * img->sector_size, vstype)) == NULL) {//第156行 //拿分区表
//...
exit(1);
}
if (pnum >= vs->part_count) {//pnum是命令行中给定的
//...
exit(1);
}
vs_part = tsk_vs_part_get(vs, pnum); //第171行 //拿分区
if (vs_part == NULL) {
tsk_fprintf(stderr, "Error looking up partition\n");
exit(1);
}
//...
tsk_vs_close(vs);
tsk_img_close(img);
//...
}//第209行 //main结尾
目录遍历、文件遍历(带动作)
samples\callback-style.cpp
- tsk_fs_dir_walk : 遍历目录 ,对每个目录执行动作函数
- tsk_fs_file_walk : 遍历文件, 对每个文件执行动作函数
sleuth/win32/下基本是应用程序,都有main函数,其中许多应用程序的main基本是近距离调用 目录遍历tsk_fs_dir_walk 、文件遍历tsk_fs_file_walk ,即这些应用可以看作是 目录遍历时的动作、文件遍历的动作 组成的。
具体如下:
static uint8_t
proc_fs(TSK_IMG_INFO * img_info, TSK_OFF_T start)
{
//...
/* Walk the files, starting at the root directory */
if (tsk_fs_dir_walk(fs_info, fs_info->root_inum,
(TSK_FS_DIR_WALK_FLAG_ENUM) (TSK_FS_DIR_WALK_FLAG_RECURSE),
dir_act, NULL)) {//从根目录root_inum开始遍历文件系统fs_info的目录,对每个目录执行动作函数dir_act
//错误处理
return 1;
}
//...
}//proc_fs结尾
目录的动作函数dir_act
static TSK_WALK_RET_ENUM
dir_act(TSK_FS_FILE * fs_file, const char *path, void * /*ptr*/)
{//目录的动作函数dir_act
/* Ignore NTFS System files */
/* If the name has corresponding metadata, then walk it */
if (fs_file->meta) {
proc_file(fs_file, path);//内部调用了遍历文件
}
return TSK_WALK_CONT;
}
static uint8_t
proc_file(TSK_FS_FILE * fs_file, const char *path)
{
/* Note that we could also cycle through all of the attributes in the
* file by using one of the tsk_fs_attr_get() functions and walking it
* with tsk_fs_attr_walk(). See the File Systems section of the Library
* User's Guide for more details:
* http://www.sleuthkit.org/sleuthkit/docs/api-docs/ */
if (tsk_fs_file_walk
(fs_file, (TSK_FS_FILE_WALK_FLAG_ENUM) myflags, file_act,
//遍历目录fs_file下的文件,对每个文件执行动作函数file_act
(void *) &md)) {
//...
}
return 0;
}
sleuthkit代码理解
Nat==native (jni方法名)
bindings\java\jni\dataModel_SleuthkitJNI.cpp
//...
JNIEXPORT jlong JNICALL
Java_org_sleuthkit_datamodel_SleuthkitJNI_openVolNat(JNIEnv * env, //第1394行, 末尾的Nat是native的缩写。
//native是java的关键字 ,java中native表示本地方法,即c++写的jni方法。
jclass obj, jlong a_vs_info, jlong vol_id)
{
//...
}
//...
jopen==JournalOpen
//...
int
main(int argc, char **argv1)
{
//...
if (fs->jopen == NULL) {//第178行
tsk_fprintf(stderr,
"Journal support does not exist for this file system\n"); //从这里可以看出jopen中的j意思是Journal
//...
}
//...
}//main结束
//...
pool volumes
pvol_block == pool_volume_block,
cd /d D:\disk-recovery\sleuthkit\win32\Release\
blkstat
#...
#usage: blkstat [-vV] [-f fstype] [-i imgtype] [-b dev_sector_size] [-o imgoffset] [-P pooltype] [-B pool_volume_block] image [images] addr
#...
-P pooltype: Pool container type (use '-P list' for supported types)
-B pool_volume_block: Starting block (for pool volumes only)
#...
blkstat -P list
#Supported file system types:
# auto (auto-detect)
# apfs (APFS container)
# lvm (Linux LVM volume group)
由此可见 所谓 pool volumes ,就是指 volume group 即 volume 列表,只有LVM和apfs能支持 volume列表
数据恢复sleuthkit+GUI(macos-10.13.6)
"# 数据恢复sleuthkit+GUI(msWin10X64)" 表述过的,这里不再重复表述
vbox安装macos-high-sierra-10.13.6.iso
md5sum.exe macos-high-sierra-10.13.6.iso
#af8d962f691cc615d28e1f2498aaf882 *macos-high-sierra-10.13.6.iso
注意 : macOS High Sierra 10.13.6 是2017年发行的
- macOS安装过程中报错"应用程序副本已损坏",解决:
修改真机win10系统时间为2017年,且vbox中建立的虚拟机"macos-10.13.6"的网络要断开,否则
#vbox启动macos-high-sierra-10.13.6.iso 卡在"end randomseed"解决:
D:\VirtualBox\VBoxManage modifyvm "macos-10.13.6" --cpu-profile "Intel Core i7-6700K"
#启动iso,大致停在 "Mac /Libaray/LauchAgents error=2 no such file or directory",后循环重启:
D:\VirtualBox\VBoxManage setextradata "macos-10.13.6" "VBoxInternal/Devices/efi/0/Config/DmiSystemProduct" "iMac11,3"
D:\VirtualBox\VBoxManage setextradata "macos-10.13.6" "VBoxInternal/Devices/efi/0/Config/DmiSystemVersion" "1.0"
D:\VirtualBox\VBoxManage setextradata "macos-10.13.6" "VBoxInternal/Devices/efi/0/Config/DmiBoardProduct" "Iloveapple"
D:\VirtualBox\VBoxManage setextradata "macos-10.13.6" "VBoxInternal/Devices/smc/0/Config/DeviceKey" "ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc"
D:\VirtualBox\VBoxManage setextradata "macos-10.13.6" "VBoxInternal/Devices/smc/0/Config/GetKeyFromRealSMC" 1
-
启动虚拟机,选中文,分区工具 --> 磁盘抹除,关掉分区工具,安装OS, 正常进入apple 安装界面,自己重启后,继续安装,结束
-
注册apple id: prg,rmz,prgrmz07@163.com, (PWD*xxx)0
-
安装xcode
适合mac-10.13.6的xcode版本: xcode10.1
搜索Xcode 10, 往下拉,找到 下载地址Xcode_10.1.xip
识别不了的.iso
vbox直接拒绝启动:
- ISO 格式原版可引导镜像Install-macOS-Catalina-10.15.7_19H15.iso
- macOS镜像列表页面 , macOS High Sierra 10.13.6 (17G66) 下载
其他
正式编译 调试版 libtsk.so
不需要的更好:在build目录下构建,走到ant步会失败
如果想在给定目录build下构建,.so会构建出来,但最终会遇到错误:“Buildfile: build.xml does not exist!“
cd /pubx/disk-recovery/sleuthkit/
mkdir build; cd build
#`pwd` == /pubx/disk-recovery/sleuthkit/build/
rm -fr ../configure
autoreconf --install /pubx/disk-recovery/sleuthkit/
../configure CPPFLAGS=" -g -O0 -I/pubx/disk-recovery/sleuthkit"
make
#构建一段时间后,错误:“Buildfile: build.xml does not exist!“, 具体如下:
#make[2]: 进入目录“/build/pubx/disk-recovery/sleuthkit/build/bindings/java”
#ant dist
#Buildfile: build.xml does not exist!
#即: cd /build/pubx/disk-recovery/sleuthkit/build/bindings/java; ant dist 后报错 "Buildfile: build.xml does not exist!"
find `pwd` -name *.so
#/pubx/disk-recovery/sleuthkit/build/tsk/.libs/libtsk.so
#/pubx/disk-recovery/sleuthkit/build/bindings/java/jni/.libs/libtsk_jni.so
"autoreconf --install" : 从Makefile.am生成configure
如何从Makefile.am生成configure? 用"autoreconf --install", 见下图: 图来自:概念:GNU构建系统和Autotool
替换系统自带release版*tsk.so为编译的debug版so
不奏效的替换(看着挺好,但不奏效)
替换:
sudo unlink /usr/lib/x86_64-linux-gnu/libtsk.so
sudo unlink /usr/lib/x86_64-linux-gnu/libtsk_jni.so
sudo ln -s /pubx/disk-recovery/sleuthkit/tsk/.libs/libtsk.so.19.2.0 /usr/lib/x86_64-linux-gnu/libtsk.so
sudo ln -s /pubx/disk-recovery/sleuthkit/bindings/java/jni/.libs/libtsk_jni.so.0.0.0 /usr/lib/x86_64-linux-gnu/libtsk_jni.so
ls -lh /usr/lib/x86_64-linux-gnu/libtsk.so /usr/lib/x86_64-linux-gnu/libtsk_jni.so
#lrwxrwxrwx 1 root root 73 7月 1 11:29 /usr/lib/x86_64-linux-gnu/libtsk_jni.so -> /pubx/disk-recovery/sleuthkit/bindings/java/jni/.libs/libtsk_jni.so.0.0.0
#lrwxrwxrwx 1 root root 56 7月 1 11:29 /usr/lib/x86_64-linux-gnu/libtsk.so -> /pubx/disk-recovery/sleuthkit/tsk/.libs/libtsk.so.19.2.0
还原:
sudo unlink /lib/x86_64-linux-gnu/libtsk.so
sudo unlink /lib/x86_64-linux-gnu/libtsk_jni.so
sudo ln -s /lib/x86_64-linux-gnu/libtsk.so.19.2.0 /lib/x86_64-linux-gnu/libtsk.so
sudo ln -s /lib/x86_64-linux-gnu/libtsk_jni.so.0.0.0 /lib/x86_64-linux-gnu/libtsk_jni.so
ls -lh /lib/x86_64-linux-gnu/libtsk.so /lib/x86_64-linux-gnu/libtsk_jni.so
#lrwxrwxrwx 1 root root 41 7月 1 11:27 /lib/x86_64-linux-gnu/libtsk_jni.so -> /lib/x86_64-linux-gnu/libtsk_jni.so.0.0.0
#lrwxrwxrwx 1 root root 38 7月 1 11:27 /lib/x86_64-linux-gnu/libtsk.so -> /lib/x86_64-linux-gnu/libtsk.so.19.2.0
未验证autopsy在 高版本jdk运行是否正常( jdk17、jdk13、jdk11)
rm -fr ~/.autopsy
rm -fr /app/autopsy-home/autopsy-4.20.0
- 使用 bellsoft-java17-full-amd64 : 最后运行autopsy是否报错未验证
sudo apt install bellsoft-java17-full-amd64
/app/autopsy-4.20.0-install/linux_macos_install_scripts/install_application.sh -z /app/autopsy-home/autopsy-4.20.0.zip -i /app/autopsy-home/ -j /usr/lib/jvm/bellsoft-java17-full-amd64
bash -x /app/autopsy-home/autopsy-4.20.0/bin/autopsy
#报错 :
#org.netbeans.InvalidException: StandardModule:org.sleuthkit.autopsy.core jarFile: /app/autopsy-home/autopsy-4.20.0/autopsy/modules/org-sleuthkit-autopsy-core.jar: java.lang.IllegalArgumentException: java.lang.reflect.InvocationTargetException
- bellsoft-java13-full-amd64 : 最后运行autopsy是否报错未验证
sudo apt install bellsoft-java13-full-amd64
/app/autopsy-4.20.0-install/linux_macos_install_scripts/install_application.sh -z /app/autopsy-home/autopsy-4.20.0.zip -i /app/autopsy-home/ -j /usr/lib/jvm/bellsoft-java13-full-amd64
bash -x /app/autopsy-home/autopsy-4.20.0/bin/autopsy
#报错:
#org.netbeans.InvalidException: StandardModule:org.sleuthkit.autopsy.core jarFile: /app/autopsy-home/autopsy-4.20.0/autopsy/modules/org-sleuthkit-autopsy-core.jar: java.lang.IllegalArgumentException: java.lang.reflect.InvocationTargetException
- bellsoft-java11-full-amd64 : 最后运行autopsy是否报错未验证