转储加载到内存中的文件

逆向工程 倾倒
2021-06-17 16:18:28

我们有一个可执行文件,它将 XML 文件加载到内存中,然后将其解析为对象。

当这个文件加载到内存中时,是否可以在加载到内存时中断,然后以某种方式从内存中提取文件?

3个回答

是的,它可以通过多种方式实现,具体取决于操作系统、用户权限和用户能力。在某些情况下,你甚至不应该打破-这是足以让使用工具过程中的内存转储如procdumpSysinternals的package.xml中的数据具有非常容易检测的结构,可在转储很容易被发现。

2017 年 3 月 27 日更新:

此答案未考虑Skylake处理器 (6*)发布以来可用Intel SGX技术的功能该技术有意限制“SGX enclaves”中的内存转储,如果 XML 上的所有工作都在内部完成,则无法转储。

question is very vague only proper answer that this question can get is 这取决于

假设你的程序做一些这样的

int main(void) {
    FILE *fp;
    long fsiz;
    char *buff;
    if((fopen_s(&fp,"c:\\myxml.xml","rb")) == 0) {
        fseek(fp,0,SEEK_END);
        fsiz = ftell(fp);
        fseek(fp,0,SEEK_SET);
        if ( (buff = (char *)calloc(1,fsiz)) != NULL) {
            if (fread(buff,1,fsiz,fp) == fsiz)
                getchar();
        }
        fclose(fp);
    }    
    return 0;
}

读取文件时可以转储

假设您正在使用 windbg .writemem 可以在读取时转储文件

: >ls -la c:*.xml

-rw-rw-rw-  1 Admin 0 13437 2003-07-15 17:30 c:\myxml.xml

:>cdb -c "bp fread \"r $t0=poi(@esp+4);gu;.writemem c:\mydupxml.xml @$t0 l?@ea x;\";g" dumpxml.exe

0:000> cdb: Reading initial command 'bp fread "r $t0=poi(@esp+4);gu;.writemem c:
\\mydupxml.xml @$t0 l?@eax;";g'

Writing 347d bytes.......

: >ls -la c:*.xml & fc /bc:\myxml.xml c:\mydupxml.xml

-rw-rw-rw-  1 Admin 0 13437 2014-11-26 11:54 c:\mydupxml.xml
-rw-rw-rw-  1 Admin 0 13437 2003-07-15 17:30 c:\myxml.xml 
Comparing files C:\myxml.xml and C:\MYDUPXML.XML
FC: no differences encountered

现在假设可执行文件正在运行并且文件已加载到内存中并且您不知道缓冲区地址不能设置断点或诸如此类的东西您可以初始化内核调试会话并在大多数情况下可以转储未知信息

lkd> !process 0 0 dumpxml.exe

PROCESS 86121020  SessionId: 0  Cid: 0864    Peb: 7ffd9000  ParentCid: 0d8c
    DirBase: 121805a0  ObjectTable: e35e0338  HandleCount:   8.
    Image: dumpxml.exe

lkd> !handle 0 3 86121020 文件

Searching for handles of type File
07f4: Object: 864f88a0  GrantedAccess: 00120089 (Inherit) Entry: e1139fe8
Object: 864f88a0  Type: (86fe9e70) File
    ObjectHeader: 864f8888 (old version)
        HandleCount: 1  PointerCount: 3
        Directory Object: 00000000  Name: dumpxml\myxml.xml {HarddiskVolume1}

lkd> !fileobj 864f88a0

dumpxml\myxml.xml

Related File Object: 0x862c2270

Device Object: 0x86f76030   \Driver\Ftdisk
Vpb: 0x86f7a2b8
Event signalled
Access: Read SharedRead 

Flags:  0xc0042
    Synchronous IO
    Cache Supported
    Handle Created
    Fast IO Read

FsContext: 0xe5ee0658   FsContext2: 0xe10e9600
Private Cache Map: 0x864e72f0
CurrentByteOffset: 347d
Cache Data:
  Section Object Pointers: 8656c324
  Shared Cache Map: 864e7218         File Offset: 347d in VACB number 0
  Vacb: 86fbecd0
  Your data is at: c484347d

lkd> .writemem c:\mydupxml.xml c484347d-347d l?347d

Writing 347d bytes.......

.shell fc /bc:\dumpxml\myxml.xml c:\dumpxml\mydupxml.xml

Comparing files C:\\DUMPXML\\myxml.xml and C:\\DUMPXML\\MYDUPXML.XML
FC: no differences encountered

.shell: Process exited

或者如果你不相信 !fileobj :) 你可以尝试自己用一些像这样的卷积来解决它

lkd> db @@c++(((nt!_VACB *)*((nt!_Shared_cache_map *)(( nt!_FILE_OBJECT *) @@(864f88a0) )->SectionObjectPointer->SharedCacheMap)->Vacbs)->BaseAddress)

.

c4840000  3c 3f 78 6d 6c 20 76 65-72 73 69 6f 6e 3d 22 31  <?xml version="1
c4840010  2e 30 22 3f 3e 0d 0a 3c-73 63 70 64 20 78 6d 6c  .0"?>..<scpd xml

您也可以转储所有 RAM :) https://github.com/volatilityfoundation/volatility