2

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?

Improve this question
2
  • Where does the file come from? Do you know/are you sure the whole file gets loaded before parsing starts? Many XML parsers, like SAX, use incremental parsing, so you might never have the whole file in memory at one point in time. If you don't have access to the file itself, for example because it's fetched from the network, running a network trace might be the easier way.
    – Guntram Blohm
    Nov 26, 2014 at 8:44
  • It's stored locally encrypted, it gets decrypted and loaded into memory as an XML before being parsed into its objects.
    – kyndigs
    Nov 26, 2014 at 11:29

3 Answers 3

Reset to default
4

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.

Improve this answer
3

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
Improve this answer
1

You can also just dump all the RAM :) https://github.com/volatilityfoundation/volatility

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.