We have an executable that loads an XML file into memory, before parsing it into objects.
When this file is loaded into memory is it possible to, break when it is loaded into memory and then somehow extract the file from memory?
Reverse Engineering Stack Exchange is a question and answer site for researchers and developers who explore the principles of a system through analysis of its structure, function, and operation. It only takes a minute to sign up.
Sign up to join this communityWe have an executable that loads an XML file into memory, before parsing it into objects.
When this file is loaded into memory is it possible to, break when it is loaded into memory and then somehow extract the file from memory?
Yes it is possible in a very large variety of ways, depending on OS, user privileges and user abilities. In some cases you even should not break - it is enough to get memory dump of the process with tools such as procdump from sysinternals package.XML data has very easy detectable structure and can be easily found in the dump.
Update by 3/27/2017:
This answer didn't take in account capabilities of Intel SGX technology which is available since release of Skylake processor generation (6*). This technology intentionally restricts memory dumping in "SGX enclaves" and if all the work on the XML is done inside it could not be dumped.
question is very vague only proper answer that this question can get is
it depends
assuming your program does some like this
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;
}
it is possible to dump when the file is read
say you are using windbg .writemem can dump the file when read
:>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 /b c:\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
now assuming the executable is running and the file is loaded into memory and you dont know cant know the buffer address cant set breakpoints or whatnot you can initialte a kernel debugging session and can dump the unknown in most cases
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 File
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 /b c:\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
or if you dont trust !fileobj :) you can try sussing it out by yourself with some convolutions like this
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
You can also just dump all the RAM :) https://github.com/volatilityfoundation/volatility