已归档项目！仓库和其他项目资源均为只读

自述文件
未设定许可证。版权所有。

README.md

autopsy

本文csdn链接

1. autopsy == sleuthkit + java GUI (以netbeans为骨架?) + solr搜索等各种库，甚至有用到testdisk，可以说是各种大杂烩
1. 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）

参考： Linux下autopsy安装手册

0. 下载autopsy Linux 安装包

下载页面

或 autopsy github下载页面

autopsy-4.20.0.zip

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安装包

sleuthkit github下载页面 sleuthkit-java_4.12.0-1_amd64.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

tsk_loaddb.vcxproj

Tsk_loaddb 文档

编译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

qt 选vs2017 编译器，需要 win10sdk中的调试器，否则无法调试，详见下图：

pyside2(pyqt类似物)

使用QtDesigner

#打开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;
    }

自己写的物理磁盘列表、分区列表

参考， how-to-get-a-list-of-physical-storage-devices

某磁盘的分区表

\tsk\vs\tsk_vs.h

    struct TSK_VS_INFO {//第65行
         //...
        TSK_VS_PART_INFO *part_list;   //第75行 ///< Linked list of partitions  //分区链表
        //...
        };

tools/vstools/mmcat.cpp

//...
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代码理解

Design_Documents

Developer's_Guide

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

\sleuthkit\tools\fstools\jls.cpp

//...

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

下载并安装：VirtualBox-7.0.8-156879-Win.exe
下载：macOS/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"的网络要断开，否则

参考 Virtual Box 安装macOS High Sierra 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是否报错未验证

项目简介

当前项目暂无项目简介

文件大小 15.7 MB
仓库大小 15.8 MB

发行版本

当前项目没有发行版本

贡献者 2

zzz @zzz

prgrmz07 @prgrmz07

开发语言

Java 71.6 %
JavaScript 28.4 %

pubz / disk-recovery / sleuthkit.org / idea_debug_autopsy

autopsy

autopsy 安装、启动过程 （Ubuntu22.04x64）

0. 下载autopsy Linux 安装包

1. Installing Prerequisites (jdk8)

2. Installing The Sleuth Kit

3.Installing Autopsy

4.启动autopsy

注意 ：

可能要注意这几点

提前执行：

提醒

autopsy启动了哪些进程？ 3个nbexec、1个jvm

autopsy的jvm进程用的jar和so

autopsy的jvm进程pid

autopsy的jvm进程用的jar

autopsy的jvm进程用的 so

autopsy 中 jni.so依赖 (linux)

调试autospy(java)

以调试模式启动autopsy

以jdb或netbeans或idea等连接到上面的调试端口

最好以同样的jdk（bellsoft-java8-full-amd64） 运行idea

编译sleuth(c++)并gdb attach到java以调试libtsk_jni.so

编译准备

统一使用bellsoft-java8-full:

正式编译 调试版 libtsk.so

编译过程

查看编译结果:

替换系统自带release版*tsk.so为编译的debug版so

查看启动后autopsy所用的so文件

奏效的替换

gdb附加

gdb调试（断点）

gdb调试脚本

1. 启动autopsy

2. 找到刚刚启动的autopsy的jvm进程pid

3. gdb带调试脚本附加到该autopsy的jvm进程

4. 调试脚本产生的日志输出文件

数据恢复sleuthkit+GUI(msWin10X64)

基于sleuthkit的磁盘或分区列出、文件写db

自己基于autopsy的sleuthkit_jni整理的

sleuthkit自带的tsk_loaddb.cpp

编译sleuthkit（win10下vs2017 ）

JDK_HOME

编译错误解决： NuGet package(s) that are missing

调试 tsk_loaddb.exe

调试 tsk_recover.exe

tsk_recover.dll

qt5

pyside2(pyqt类似物)

物理磁盘列表 (sleuthkit无此代码、autopsy不全且恶心)

简介:

结论： 拿物理磁盘列表 代码 得自己写了

详细描述 sleuthkit、autopsy关于 拿物理磁盘列表 ：

1. sleuthkit中 没有拿物理磁盘列表 的代码，

2. autopsy中用java且偷懒且windows不全、linux全

自己写的 物理磁盘列表、分区列表

某磁盘的分区表

目录遍历、文件遍历（带动作）

samples\callback-style.cpp

sleuthkit代码理解

Nat==native (jni方法名)

jopen==JournalOpen

pool volumes

数据恢复sleuthkit+GUI(macos-10.13.6)

vbox安装macos-high-sierra-10.13.6.iso

识别不了的.iso

其他

正式编译 调试版 libtsk.so

不需要的更好：在build目录下构建，走到ant步会失败

"autoreconf --install" : 从Makefile.am生成configure

替换系统自带release版*tsk.so为编译的debug版so

不奏效的替换（看着挺好，但不奏效）

未验证autopsy在 高版本jdk运行是否正常（ jdk17、jdk13、jdk11）

项目简介

发行版本

贡献者 2

开发语言

autopsy 安装、启动过程（Ubuntu22.04x64）

注意：

最好以同样的jdk（bellsoft-java8-full-amd64）运行idea

正式编译调试版 libtsk.so

结论：拿物理磁盘列表代码得自己写了

详细描述 sleuthkit、autopsy关于拿物理磁盘列表：

1. sleuthkit中没有拿物理磁盘列表的代码，

自己写的物理磁盘列表、分区列表

正式编译调试版 libtsk.so

未验证autopsy在高版本jdk运行是否正常（ jdk17、jdk13、jdk11）