checksum这个校验的文件咋用？

Posted 2023-04-02

checksum这个校验的文件咋用？在电驴上下了一个文件，后面有个这种文件，但不知道咋用。

校验和(Checksum)

PE的可选映像头（IMAGE_OPTION_HEADER）里面,有一个Checksum字段,是该文件的校验和，一般EXE文件可以使0，但一些重要的和系统DLL及驱动文件必须有一个校验和.

Windows 提供了一个API函数MapFileAndCheckSum 测试文件的Checksum，它位于IMAGEHLP.DLL链接库里，其原型:

ULONG MapFileAndCheckSum



LPSTR FileName, // 文件名

LPDWORD HeaderSum, // 指向PE文件头的CheckSum

LPDWORD new_checksum // 指向新计算出的Checksum



程序一旦运行后，new_checksum 地址处将放当前的文件的校验和,old_checksum地址指向PE文件的checksum字段

安全的方法是将此值放在注册表里，需要时比较.

内存映像校验

磁盘文件完整性校验可以抵抗解密者直接修改文件，但对内存补丁却没有效果,必须对内存关键的代码进行校验.

1 对整个代码进行校验

每个程序至少有一个代码区块和数据区块，数据区块属性可读写,程序运行时全局变量通常会放在这里，这些数据会动态变化,因此校验这部分是没什么意义，而代码段只读,存放的是程序代码，在程序中数据数不会变的，因此用这部分进行内存校验是可行的.

具体实现方法:

(1) 从内存中映像中得到PE相关数据,如代码块的RVA和内存大小

(2) 根据得到代码区块的RVA值和内存大小，计算出内存数据的CRC-32值

(3) 读取自身文件先前存储的CRC-32值(PE文件头前一个字段),这个值是通过软件写进去的.

(4) 比较两个CRC-32值.

这样比较内存的代码段校验，只要内存的数据被修改，就能发现。

BOOL CodeSectionCRC32()



PIMAGE_DOS_HEADER pDosHeader = NULL;

PIMAGE_NT_HEADERS pNTHeader = NULL;

PIMAGE_SECTION_HEADER pSection = NULL;

DWORD ImageBase,OriginalCRC32;

ImageBase = (DWORD)GetModuleHandle(NULL); // 取基址

pDosHeader = (PIMAGE_DOS_HEADER)ImageBase;

pNtHeader = (PIMAGE_NT_HEADER32)((DWORD)pDosHeader + pDosHeader -> e_lfanew);

// 定位到PE文件头前4个字节值，并读取存储在这里的CRC -32值

OriginalCRC32 = *((DWORD*)(DWORD)pNtHeader - 4);

pSecHeader = IMAGE_FIRST_SECTION(pNtHeader); // 得到第一个区块的地址

//假设第一个区块就是代码区块

if(OriginalCRC32 == CRC32((BYTE*)ImageBase + pSecHeader -> VirtualAddress)

// 为了方便加壳

// 上一句也可为if(OriginalCRC32 == CRC32((BYTE *)0x401000, 0x36AE)

return TRUE;

else

return FALSE;

参考技术A Z6确实属于新一代的motorola linux了Z6的QTE如果我没猜错的话，应该和E2很接近的，可以利用Lasly的E2 EZX SDK进行尝试与以前的EZX不同，Z6是2.6.10内核，不叫montavista xxx版本，而是mobilinux4.1以前的EZX使用的是cramfs格式来保存刷机包smg文件，而Z6使用的是squashfs格式。如何从sbf获得smg文件？你可以使用winhex查找hsqs头部来获得，这样比较麻烦，但同时你可以记录下原smg所在的位置方便改sbf时替换或者使用RSD Lite进行假刷机，在loading ram downloader的进度未完成时拷出生成的smg文件，然后拨掉数据线避免喜刷刷要给Z6改包，需要给你的PC LINUX安装squashfs支持你可以google搜得squashfs的源代码进行安装（可能需要对内核进行patch和重新编译）简单地，使用编译好的安装包进行安装，例如我的ubuntu就是直接使用synaptic(新立得)安装的使用mount -o loop -t squashfs <smgfile> <mountpoint>挂载smg文件tar zcvf <arch.tar.gz> <mountpoint>umount <mountpoint>tar zxvf <arch.tar.gz> -C ./修改刷机包的过程与EZX基本类似。但根文件系统已有较大不同，需探索一番使用mksquashfs <mountpoint> <newsmgfile>来生成新的smg文件在尾部添加FF内容，使新的smg文件达到原smg大小(要是生成就超过，那就删点你的东西吧，呵呵)我分解的z6_cmcc_nolock_r60_g_80.31.17r各smg文件列表如下：cg36=rootfscg43=setupcg44=secure setup*cg52=resource未发现这几个smg存在像EZX一样的FF头部，各squashfs的smg文件均可直接挂载*:需要注意的是：cg44包含0x800尾部，呵呵，这个很意外直接用winhex拷原版cg44的尾部，替换生成的smg的尾部吧。制作完smg文件后需要进行的是刷机包sbf的替换和修改先将你的修改的smg的内容替换进sbf里原smg的位置，这个较简单比较重要的是checksum的替换，这关系到你的sbf能否正确刷入，完成checksum校验各smg 的 checksum 保存在sbf文件内的0x750~0x1000位置使用checksum <smgfile>来获得checksum值，注意，得出的值是反向的，如得到ab cd，则应写入／查找 cd ab* checksum.exe作者是yan0以下是我拆的版本的各smg checksum值及值的位置:cg36.smg 85 A5 @ 0x7F4cg43.smg 26 F5 @ 0x8B8cg44.smg 1A 7A @ 0x8D4cg46.smg 65 4C @ 0x90Ccg52.smg 05 EB @ 0x9E4

Oracle 日志文件内的checksum计算

目录

一、场景介绍

二、校验和分布

三、校验和计算

---

一、场景介绍

        这个比较小众，估计没人会在意这个，但我最近遇到了这个问题，正好记录一下。先说明一下场景，Oracle的日志文件（online redo file 和 archive log file）以块作为读写单位，每一块都是 512 字节（嘿嘿，正好对应扇区），Oracle在读写块的时候会对数据进行完整性校验，通过每块中的某两个字节记录校验和。但这些Oracle官网都是查不到的。