显示标签为“tool”的博文。显示所有博文

2022年2月28日星期一

静态分析：DIE工具

来源：https://blog.csdn.net/fengtum/article/details/107756710

https://github.com/horsicq/Detect-It-Easy

“DIE”是一个跨平台的应用程序，除Windows版本外，还有适用于Linux和Mac OS的可用版本。

许多此类程序（PEID，PE工具）允许使用第三方签名。不幸的是，这些签名只能通过预设掩码扫描字节，并且无法指定其他参数。结果，经常发生错误的触发。程序本身通常严格设置更复杂的算法。因此，要添加新的复杂检测，需要重新编译整个项目。除作者自己外，没有人可以改变检测算法。随着时间的推移，如果没有持续的支持，这些计划就会失去意义

Detect It Easy完全开放签名架构。您可以轻松添加自己的算法来检测或修改已存在的算法。这是通过使用脚本来实现的。脚本语言与JavaScript非常相似，任何了解编程基础知识的人都会很容易理解它的工作原理。可能有人可能会决定脚本工作非常缓慢。事实上，脚本运行速度比编译代码慢，但是，由于脚本引擎的良好优化，这不会造成任何特别的不便。开放式架构的可能性弥补了这些限制。

DIE存在三种版本。基本版本（“DIE”），Lite版本（“DIEL”）和控制台版本（“DIEC”）。所有这三个使用相同的签名，它们位于文件夹“db”中。如果你打开这个文件夹，将会找到嵌套的子文件夹（“二进制”，“PE”等）。子文件夹的名称对应于文件的类型。首先，DIE确定文件的类型，然后依次加载位于相应文件夹中的所有签名。目前该程序定义了以下类型：

MSDOS可执行文件MS-DOS

PE可执行文件Windows

ELF可执行文件Linux

MACH可执行文件Mac OS

文本文件

二进制文件

静态分析工具：Trid

来源：https://cathon.github.io/2015/02/12/tools-for-stego/

##TrID

TrID File Identifier

TrID是一款根据文件二进制数据特征进行判断的文件类型识别工具。虽然也有类似的文件类型识别工具，但是大多数都是使用硬编码的识别规则，而TrID则没有固定的匹配规则，TrID具有灵活的可扩展性，可以通过训练来进行文件类型的快速识别。
TrID通过附加的文件类型指纹数据库来进行匹配，可用于取证分析、未知文件识别等用途。

linux 平台下载解压缩

1
2
3

$ cd trid_linux
$ chmod +x trid
$ ./trid binary_file

若检测失败，缺失 triddefs.trd ，从windows版的软件中将其复制过来即可。
windows 平台可以直接下载使用

P.S. linux 下的 file 命令与这个工具作用相似

静态分析工具：ExifTool

起因：做静态分析的需求时看到很多不了解的工具，go了一下，mark一下

来源：https://www.rmnof.com/article/exiftool-introduction/

ExifTool完全入门指南

ExifTool介绍

ExifTool由Phil Harvey开发，是一款免费、跨平台的开源软件，用于读写和处理图像（主要）、音视频和PDF等文件的元数据（metadata）。ExifTool可以作为Perl库（Image::ExifTool）使用，也有功能齐全的命令行版本。ExifTool支持很多类型的元数据，包括Exif、IPTC、XMP、JFIF、GeoTIFF、ICC配置文件、Photoshop IRB、FlashPix、AFCP和ID3，以及众多品牌的数码相机的私有格式的元数据。

什么是Exif

Exif是可交换图像文件格式（Exchangeable image file format），是一种标准，定义了与数码相机捕获的图像（或其他媒体）有关的信息，用于存储重要的数据，比如相机的曝光、拍摄日期和时间，甚至GPS定位等。在早期，摄影师需要随身携带笔记本来记录重要信息，如日期、快门速度、光圈等，这非常麻烦而且容易出错。如今，每台数码相机都支持Exif，能够将拍摄时的很多参数通过这种格式（Exif）记录到照片中，这些照片（或其他类型的文件）中的额外数据就叫元数据（metadata），它由一系列参数组成，如快门速度、光圈、白平衡、相机品牌和型号、镜头、焦距等等。Exif信息可能会造成隐私泄露（相机型号、位置等），在社会工程学中，Exif也是获取目标信息的一种手段，所以建议在把照片上传到互联网之前先清理Exif数据。

ExifTool支持的文件类型和标签

ExifTool支持的文件类型（File Type）：参考官网Supported File Types
ExifTool支持的标签（Tag）：参考官网ExifTool Tag Names

2019年4月10日星期三

linux ab 报告存文件

参考: https://blog.csdn.net/helencoder/article/details/52457078

ab常用参数的介绍：
-n ：总共的请求执行数，缺省是1；
-c：并发数，缺省是1；
-t：测试所进行的总时间，秒为单位，缺省50000s
-p：POST时的数据文件
-w: 以HTML表的格式输出结果

ab -g a.csv -n 1000 -c 10 -p data https://10.9.147.38:443/risk 1>file
ab -g a.csv -n 1000 -c 10 -p data -w https://10.9.147.38:443/risk 1>file.html

两个结果有点儿差异,如下: 这样看还是用非html的好一点儿，自己的ab是 Version 2.3

file中

Document Length:        63 bytes

Concurrency Level:      10
Time taken for tests:   1.304 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      379000 bytes
Total body sent:        1203000
HTML transferred:       63000 bytes
Requests per second:    766.75 [#/sec] (mean)
Time per request:       13.042 [ms] (mean)
Time per request:       1.304 [ms] (mean, across all concurrent requests)
Transfer rate:          283.79 [Kbytes/sec] received
                        900.78 kb/s sent
                        1184.56 kb/s total

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        5    7   1.2      7      12
Processing:     2    6   3.4      5      41
Waiting:        2    5   3.3      5      41
Total:          7   13   3.4     13      48

Percentage of the requests served within a certain time (ms)
  50%     13
  66%     13
  75%     14
  80%     14
  90%     15
  95%     16
  98%     17
  99%     36
 100%     48 (longest request)

file.html中

This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Server Software: nginx
Server Hostname: 10.9.147.38
Server Port: 443
Document Path: /api/v4/ip/reputation_risk
Document Length: 63 bytes
Concurrency Level: 10
Time taken for tests: 1.285 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 379000 bytes
Total body sent: 1203000
HTML transferred: 63000 bytes
Requests per second: 778.08
Transfer rate: 294890.69 kb/s received
  936025.06 kb/s sent
  1230915.75 kb/s total
Connnection Times (ms)
  min avg max
Connect: 5 7 13
Processing: 3 5 7
Total: 8 12 20

2018年9月14日星期五

转:mergecap 合并pcap包

http://qwxingren.blog.sohu.com/304463885.html

合并在wireshark中通过filter过滤出sip信令，但是在多个文件中,megecap可以将多个pcap文件合并为一个文件。

用法：mergecap -w <输出文件>  <源文件1>  <源文件2> ...
示例：
mergecap -w compare.pcap a.pcap b.pcap

2018年9月3日星期一

转: inux版lcx

http://www.vuln.cn/2791

[popexizhi：刚刚知道windows的lcx 看着很好用啊，查了一下，linux下也有，打算试试]

这个工具以前使用的初衷是内网渗透，需要将内网ssh端口转发到外网服务器上。但这个工具同样适用于运维工程师进行远程内网维护。

当然这一切的前提是内网可以访问外网，检测方法当然就是直接ping 一个外网IP即可。

这个工具之前折腾了很久发现有点不稳定，断掉无法重新连接，昨晚重新调整了下命令参数总算可以正常使用，稳定性妥妥的。

linux版lcx工具下载

linux版lcx端口转发2016.6.10 – 12.04 Kb

lcx使用方法：

Usage:./portmap -m method [-h1 host1] -p1 port1 [-h2 host2] -p2 port2 [-v] [-log filename]
-v: version
-h1: host1
-h2: host2
-p1: port1
-p2: port2
-log: log the data
-m: the action method for this tool
1: listen on PORT1 and connect to HOST2:PORT2
2: listen on PORT1 and PORT2
3: connect to HOST1:PORT1 and HOST2:PORT2

先在外网中转服务器运行：

./portmap -m 2 -p1 6666 -h2 118.*.*.2 -p2 7777

2018年1月17日星期三

sar历史日志

参考:
http://blog.csdn.net/panda_bear/article/details/8005102
http://haibing.org/?p=90

"sar -参数 -f filename"，可以查看二进制文件，通过选择查看参数；

参数解释如下：

-A 所有报告的总和

-u CPU利用率

-v 进程、I节点、文件和锁表状态

-d 硬盘使用报告

-r 没有使用的内存页面和硬盘块

-g 串口I/O的情况

-b 缓冲区使用情况

-a 文件读写情况

-c 系统调用情况

-R 进程的活动情况

-y 终端设计活动情况

-w 系统交换活动

补充说明：

"sar -参数 -o filename 间隔时间采集次数"

可以根据需要的性能参数，手动开启性能数据采集记录入文件；

"sar -f filename"

通过以上指令对二进制文件进行查看。

查看日志文件 ------------------------
日志文件是二进制的，直接打开没办法看。
为sar命令指定-f以选择要读取的文件。如果想读1日的数据，可以使用命令sar -f /var/log/sa/sa01来读取sa01以查看当天的数据，这里会打开当天全部的数据，基本上没办法看。
我们通常都是想看某一时段的数据，这时就需要添加开始时间和结束时间：
使用-s和-e参数（即开始和结束）来指定具体时间以缩小查询的范围。
请注意，-s并不是包含性的，所以必须从所选择的开始时间中多减去十分钟。

[root@linux sa]# sar -f  sa01 -s 01:00:00 -e 05:00:00 -u

sar -f 日志文件  -s 开始时间  -e 结束时间 平时我们经常用的参数

Usage: sar [ options... ] [  [ <count> ] ]

Options are:

[ -A ] [ -b ] [ -B ] [ -c ] [ -d ] [ -i  ] [ -p ] [ -q ]

[ -r ] [ -R ] [ -t ] [ -u ] [ -v ] [ -V ] [ -w ] [ -W ] [ -y ]

[ -I {  | SUM | ALL | XALL } ] [ -P {  | ALL } ]

[ -n { DEV | EDEV | NFS | NFSD | SOCK | ALL } ]

[ -x {  | SELF | ALL } ] [ -X {  | SELF | ALL } ]

[ -o [  ] | -f [  ] ]

[ -s [  ] ] [ -e [  ] ]

再来总结一下：

sa1 是调用sadc将性能数据收集到二进制日志文件中的一个Shell 脚本，而且在cron中被计划执行，每隔十分钟运行一次；
sa2 是将当日二进制日志文件中所有的数据转储到文本文件，并根据保存天数清除过期日志文件的一个shell脚本,在cron中每晚23：53分定期执行；
sadc 是系统动态数据收集工具，收集的数据被写一个二进制的文件中，也是其中最重要的工具，其它工具基本上都是调用它来实现功能；
sadf 显示被sar通过多种格式收集的数据；

安装sysstat-------------------------------------
安装这么简单的事就不讲了

#sar -V 查看一下版本

sysstat version 7.0.2

sar其实是sysstat中的其中一个工具。

Sysstat 是一个软件包，包含监测系统性能及效率的一组工具，这些工具对于我们收集系统性能数据，比如CPU使用率、硬盘和网络吞吐数据，这些数据的收集和分析，有利于我们判断系统是否正常运行，是提高系统运行效率、安全运行服务器的得力助手。

Sysstat 软件包集成如下工具：

Sysstat的功能列表：

◆iostat：统计并报告你的设备的CPU状态和I/O状态数据。
◆mpstat：监控和显示关于CPU的细节信息。
◆pidstat：统计正在运行的进程/任务的CPU、内存等信息。
◆sar：保存和报告不同资源(CPU、内存、输入输出、网络、内核等)的详细信息。
◆sadc：系统活动数据收集器，用于为sar收集后台的数据。
◆sa1：读取和存储sadc的数据文件的二进制数据。
◆sa2：和sar协作，用于总结每日报告。
◆Sadf：以不同的格式(CSV或XML)显示sar生成的数据。
◆Sysstat：解释sysstat的各种作用。
◆nfsiostat-sysstat:统计NFS协议的网络文件系统的 I/O状态数据。
◆cifsiostat：统计CIFS协议的网络文件系统的 I/O状态数据。

安装完，sysstat默认就是随机启动的。
可以通过chkconfig –list|grep sysstat来检查

而且会在日志保存目录/var/log/sa/中产生当天的日志文件：这也说明sysstat运行正常。

cd /var/log/sa/

ls

sa01 sa02 sar01

2017年8月16日星期三

rm替代脚本

add:http://yuanshuilee.blog.163.com/blog/static/21769727520131021355927/
[popexizhi： rm 太有危险了，还是使用替代脚本mv代替比较好一些，如下脚本
加到执行路径下就ok
vim xrm #写入脚本
chmod oug+x rm
echo $PATH #找个默认的路径使用
sudo mv xrm /usr/local/bin
]

#!/bin/bash
#首先要将带“-”的选项删除，因为rm可以-r -f -i，所以首先删掉这几个，最后是删除文件，
while echo "$1" |grep \- >/dev/null 2>&1
do
    shift
done

if [ ! -d $HOME/.trash ]
then mkdir $HOME/.trash
fi
#循环删除文件，并加上时间戳
for i in "$@"
do
    time=`date +%m-%d_%H-%M-%S`
    mv "$i" $HOME/.trash/"$time"_"$i"
done;

转:Linux下误删除后的恢复操作（ext3/ext4）

add: http://www.cnblogs.com/kevingrace/p/6145308.html
[popexizhi: 这里有一个悖论 extundelete 恢复时挂在的/dev/sda2 / 中，就无法umount 就无法恢复，ext3 系统没有找到，好吧！先标记一下]

extundelete，这是针对ext4文件格式下文件删除后的恢复工具

2)执行删除操作（要是/根分区之外的分区，并且只能是文件删除后的恢复，目录删除不能恢复）
[root@slave-node ~]# df -T
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/sda3 ext4 151189708 2370020 141139688 2% /
tmpfs tmpfs 32960412 0 32960412 0% /dev/shm
/dev/sda1 ext4 198337 26798 161299 15% /boot
/dev/sda2 ext4 806346400 201304 765185096 1% /home

[root@slave-node ~]# cd /home/
[root@slave-node home]# echo "123456"> test1
[root@slave-node home]# echo "hahahahha" > wangshibo
[root@slave-node home]# ls
lost+found test1 wangshibo zabbix

删除文件
[root@slave-node home]# rm -rf test1 wangshibo
[root@slave-node home]# ls
lost+found zabbix

3）数据删除后的恢复操作
首先恢复前，卸载需要恢复文件的分区
[root@slave-node ~]# umount /home/ //如果卸载失败，就用命令"fuser -k /home"结束使用此分区的进程树
[root@slave-node ~]# df -T
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/sda3 ext4 151189708 2370024 141139684 2% /
tmpfs tmpfs 32960412 0 32960412 0% /dev/shm
/dev/sda1 ext4 198337 26798 161299 15% /boot

使用extundelete查看分区上存在的文件,如下：
--inode 为查找某i节点中的内容，使用2则说明为搜索，如果需要进入目录搜索，只须要指定目录I节点即可
[root@slave-node ~]# extundelete --inode 2 /dev/sda2
WARNING: Extended attributes are not restored.
Loading filesystem metadata ... 6250 groups loaded.
Contents of inode 2:
0000 | ed 41 00 00 00 10 00 00 84 10 49 58 82 10 49 58 | .A........IX..IX
0010 | 82 10 49 58 00 00 00 00 00 00 04 00 08 00 00 00 | ..IX............
0020 | 00 00 00 00 07 00 00 00 21 24 00 00 00 00 00 00 | ........!$......
0030 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0040 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0050 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0060 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0070 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0080 | 00 00 00 00 00 00 00 00 11 10 00 00 00 00 00 00 | ................
0090 | 00 00 00 00 00 00 00 00 62 0e 49 58 62 0e 49 58 | ........b.IXb.IX
00a0 | 62 0e 49 58 00 00 00 00 00 00 00 00 00 00 00 00 | b.IX............
00b0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00c0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00d0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00e0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00f0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................

Inode is Allocated
Group: 0
File mode: 16877
Low 16 bits of Owner Uid: 0
Size in bytes: 4096
Access time: 1481183364
Creation time: 1481183362
Modification time: 1481183362
Deletion Time: 0
Low 16 bits of Group Id: 0
Links count: 4
Blocks count: 8
File flags: 0
File version (for NFS): 0
File ACL: 0
Directory ACL: 0
Fragment address: 0
Direct blocks: 9249, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
Indirect block: 0
Double indirect block: 0
Triple indirect block: 0

File name | Inode number | Deleted status
Directory block 9249:
. 2
.. 2
lost+found 11
haha 12 Deleted
zabbix 17432577
test1 12 Deleted
wangshibo 13 Deleted

如上可以看出，被删除的两个文件test1和wangshibo已经被找到，状态为已经删除。
接下来就将它们恢复出来：
[root@slave-node ~]# extundelete --restore-inode 12 /dev/sda2
WARNING: Extended attributes are not restored.
Loading filesystem metadata ... 6250 groups loaded.
Loading journal descriptors ... 46 descriptors loaded.
Restored inode 12 to file RECOVERED_FILES/file.12
[root@slave-node ~]# extundelete --restore-inode 13 /dev/sda2
WARNING: Extended attributes are not restored.
Loading filesystem metadata ... 6250 groups loaded.
Loading journal descriptors ... 46 descriptors loaded.
Restored inode 13 to file RECOVERED_FILES/file.13

[root@slave-node ~]# ls RECOVERED_FILES/
file.12 file.13
[root@slave-node ~]# mount /dev/sda2 /home/ //重新挂载home分区
[root@slave-node ~]# mv RECOVERED_FILES/file.12 /home/test1
[root@slave-node ~]# mv RECOVERED_FILES/file.13 /home/wangshibo

再次查看home分区，发现删除的文件已经恢复回来了,很强大！！！
[root@slave-node ~]# cd /home/
[root@slave-node home]# ls
lost+found test1 wangshibo zabbix
[root@slave-node home]# cat test1
123456
[root@slave-node home]# cat wangshibo
hahahahha

------------------------------------------------------------------------------------------------------
上面介绍的是在ext4文件格式下的文件删除后的恢复，那如果是ext3文件格式下的文件删除后想恢复，怎么办呢？
可以使用debugfs工具，这是linux系统自带工具，debugfs恢复Ext3的文件系统中被rm、rm -f 掉的文件。

实例说明：
[root@slave-node ~]# df -T
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/sda3 ext3 151189708 2370036 141139672 2% /
tmpfs tmpfs 32960412 0 32960412 0% /dev/shm
/dev/sda1 ext3 198337 26798 161299 15% /boot

创建一个文件
[root@slave-node ~]# mkdir test
[root@slave-node ~]# echo "123456" > /root/test/test.file

删除文件
[root@slave-node ~]# rm -rf /root/test/test.file

接着运用系统自带工具debugfs来恢复已删除的文件
首先打开，刚刚被删除文件所在的分区
注意上面显示的有<>尖括号内的数字就是我们要找的文件Inode号，执行logdump –i <8654024>
[root@slave-node ~]# debugfs
debugfs 1.41.12 (17-May-2010)
debugfs: open /dev/sda3
debugfs: ls -d /root/test
8654023 (12) . 8519681 (4084) .. <8654024> (4072) test.file
debugfs: logdump -i 8654024
FS block 1006 logged at sequence 404351, journal block 7241
(inode block for inode 15):
Inode: 15 Type: regular Mode: 0664 Flags: 0×0 Generation: 0
User: 0 Group: 0 Size: 20
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 8
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0×48159f2d — Mon Apr 28 15:25:57 2008
atime: 0×48159f27 — Mon Apr 28 15:25:51 2008
mtime: 0×4806f070 — Thu Apr 17 12:08:40 2008
Blocks: (0+1): 102348
No magic number at block 7247: end of journal.

执行完命令后，显示了一屏信息，需要注意的是下面Blocks这一行后面的值（如上信息，需要记住Blocks这一行后面的数字102348）

输入quit，退出debugfs
debugfs: quit
[root@slave-node ~]#

执行如下命令进行恢复：
[root@slave-node ~]# dd if=/dev/sda3 of=/tmp/test.file.bk bs=4096 count=1 skip=102348
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.0110028 s, 372 kB/s

最后查看tmp目录下，发现已经恢复了我们之前删除的文件内容
[root@slave-node ~]# cd /tmp/
[root@slave-node tmp]# cat test.file.bk
[root@slave-node tmp]# mv test.file.bk /root/test.file
[root@slave-node tmp]# cat /root/test.file
123456

订阅：博文 (Atom)