Page 5 of 11 FirstFirst 1234567891011 LastLast
Results 61 to 75 of 154

Thread: NTFS MFT Internals

  1. #61
    Super Moderator
    Join Date
    Dec 2004
    Posts
    1,486
    Blog Entries
    15
    Break on NtfsReadFileRecord or NtfsReadMftRecord and see what it tells you.
    post #20 in this thread shows a script which prints out the mft record number in windbg with the second function NtfsReadMftRecord

    http://www.woodmann.com/forum/showthread.php?15188-Softice-and-createfile&p=94718#post94718

    nope no movies those were from books of robert ludlum frederik forsyth genre read ages ago

  2. #62
    Quote Originally Posted by Kayaker View Post
    I was muddling through this a bit again, trying to figure out where you're at tracing the connection from CreateFile -> MFT
    Thanks for that, K., there is some interesting stuff in your reply about record numbers (nfi.exe) and MFT access. Let me give you a summary of what I am trying to accomplish and why I am where I am in the tracing.

    1)I stupidly overwrote part of the file system on my external drive, which I use for storage. The original MFT and MftMirr files are still there and the damage seems to have separated the main file archive from the MFT metafiles.

    2)I am looking for a way to connect the MFT data to the lost files. The record number supplied in your utility is interesting but finding the reference to that number in the MFT is compounded by the way it is listed. They use an offset from the beginning of the partition and an offset from the beginning of the MFT to find the file record. The offsets are combined in a way that is not easily read and there is not much info on the Net as to how it should be read...only vague references.

    Even Microsoft admits the process of tracing the MFT is not trivial.

    I am hoping, that if I find the lost files, that record number will be there at the beginning of the lost record. I have an app that does a search through raw data on disk and I may plug in the record number to see what it finds. I am reasoning that the NTFS system relates the MFT with the stored files so it can verify that it has the right file. So far, I have been unable to find raw data with any such reference.

    I used another app to retrieve most of the files I lost, but it does it by recognizing file signatures then recovering the file data. It does not use the MFT as far as I can see. Actually, the lost files are not lost, I have them backed up elswhere. I am doing this as a project to see if I can reconstruct a file/directory system from a damaged MFT.

    3)I glommed onto the idea of watching NTFS unravel the mystery for me and I began with a bpx on Createfile. It lead me into NTFS.sys and even HAL via driver filters, which was interesting, but when the file was accessed, it had already been loaded into memory. That is, the MZ header was already there.

    That seems to suggest that CreateFile, when called initially, retrieves a handle to a file that has already been found on disk by other processes and loaded into memory. From what I have seen, Createfile does not initiate the process of dealing with the MFT.

    4)I decided to back up to the mouse capture when I double-clicked the app and quickly trace through to the CreateFile process. I had no idea how much path parsing and object creation there was in-between, involving shell 32, Shlwapi and Ole32. That's where the PIDls and IDLs come into play. I did see a reference to the MFT in some PIDL theory and that encouraged me.

    Since IDLs (Item ID lists) are part of the shell namespace that underlies the file and directory system, it makes sense to me intuitively that the MFT must somehow be tied into that namespace process. That's what I am looking for.

    http://msdn.microsoft.com/en-us/library/windows/desktop/cc144093%28v=vs.85%29.aspx

    I became so immersed in the theory of PIDLs and IDLs, with SHITEMID lists that it became a project in itself.

    Your suggestion makes eminent sense, to bpx on an MFT function, and I will try that. Something stopped me in the past and I think it had something to do with failing to load symbols in softice from NTFS.sys. The NTFS.sys nms created by symbol loader seemed to be missing those functions and I created an nms using IDA2ICE in IDA, but it did not work for some reason. I'll try it again now that I am loaded in a VM.

    Quote Originally Posted by Kayaker View Post
    Here's a search for notepad.exe
    There is some interesting stuff in here. I'll need to take a closer look to see if I can relate the logical sectors to the offsets stored in the MFT. It might even be interesting to follow NFI.exe with softice or windbg to see where it finds its info.


    Quote Originally Posted by Kayaker View Post
    I just thought that if you ever get to a point, maybe in NtfsReadMftRecord, you could use the known MFT record number as a breakpoint qualifier for the target file you're chasing. Just a random thought.

    Oh, and if you deleted the prefetch for a file, would it go through the initialization steps of accessing the MFT that you're hoping to catch?
    Good idea. I deleted the prefetch and turned it off so that Windows would not use shortcuts to bypass the MFT. Maybe my reasoning is awry.

  3. #63
    Quote Originally Posted by Kayaker View Post
    Break on NtfsReadFileRecord or NtfsReadMftRecord and see what it tells you.
    I edited some of your code to keep the post shorter...

    Code:
    00026B5C _NtfsReadFileRecord@28
    00026B5C
    00026B5C arg_0           = dword ptr  8
    00026B5C arg_4           = dword ptr  0Ch
    00026B5C arg_8           = dword ptr  10h
    00026B5C arg_C           = dword ptr  14h
    00026B5C arg_10          = dword ptr  18h
    00026B5C arg_14          = dword ptr  1Ch
    00026B5C arg_18          = dword ptr  20h
    00026B5C
    ----snip----
    00026B71                 push    dword ptr [edi]
    00026B73                 push    [ebp+arg_0]
    00026B76                 call    _NtfsFindCachedFileRecord@16
    00026B7B                 test    al, al
    ----snip----
    00026B8E                 push    [ebp+arg_0]
    00026B91                 call    _NtfsReadMftRecord@28
    Note the first call .... 'call _NtfsFindCachedFileRecord@16'

    It checks the filecache to see if the file is already cached. I have not done this yet but I am wondering if I can jump over that call then edit memory to make it looks as if it did not find a file in the cache. That might force it to read from the MFT.

    Anyway...I still have to find that code in relation to my project.

    Just rechecked your code and apparently I can force it to read the MFT. I omitted this important step from your code:

    00026B7D jnz loc_274C7

    That follows the cache read and a test al,al. If the file is in the cache, it jumps elsewhere, if not, it goes on to read the MFT.

    I am debating whether to go for a long walk or carry on. I really need the exercise.

  4. #64
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,079
    Blog Entries
    5
    I was hoping you'd pick up on that NtfsFindCachedFileRecord call, because it seemed to fit what you were saying about the system checking the file cache first.
    I got quite a few breaks when I set a bp on the proc, though I didn't check the what/where/why of them.

  5. #65
    Quote Originally Posted by Kayaker View Post
    I was hoping you'd pick up on that NtfsFindCachedFileRecord call, because it seemed to fit what you were saying about the system checking the file cache first.
    I had a fair amount of success once I got things ironed out with ntfs.sys and it's nms file. I must have made a mistake when I loaded ntfs.sys in IDA initially because I could not find any of the references you posted with regard to NtfsReadFileRecord. The nms file created by symbol loader had no symbols at all. I did a fresh load of ntfs.sys in IDA and this time it came up with all the functions. I made an NMS file using IDA2ICE that is nearly a meg long and ice whined about the date stamp. It claimed it is newer than the actual module...no kidding?

    I found your function after loading the ntfs nms file into ice but found that you have to enter it exactly as listed. ie. bpx _NtfsReadFileRecord@28. I had already double-clicked the app in the file manager using a hwnd from SPYXX and was sitting in the file manager context in ice. When I set the bpx and hit F5 it broke right away in the code you posted.

    I think I was wrong in my last post about bypassing the cache check by redirecting the jump following the test al, al. I think you actually need to take the jump after the cache check otherwise it goes to NtfsReadMFTRecord. Anyway, the test ax, ax did not set off the jump and it filtered through to NtfsReadMFTRecord.

    After that there was a call to NtfsMapStream@28 which I need to research. They call any of the MFT data a stream and you can have the default stream, which is unnamed, or you can have several named streams for the same data.

    Immediately following is a call to Ntoskrnl!CcMapData which maps a byte range of a cached file to a buffer. That's why I think I took a wrong turn unless it's just checking to see if the file is cached or not.

    Here's where the fun begins. When it returns from that call, an address is loaded in ESI that contains one of the metadata sections from the MFT. The data begins with the signature 'FILE' and later in the section, the loaded file name appears. I am presuming the address, which is 23:C3764400 is the actual address on disk of the MFT section. It may, however, be the cache address.

    Then disaster struck. My VM input froze again, both mouse and keyboard. It's frustrating. I could access the VM controls bar to shut the VM down but nothing I did would recover the input to windows on the guest. I could not access softice, the windows start button, or anything on the guest desktop. I could access the host OK and the VM tool bar to shut the VM down.

    If I hit ctrl-alt-esc, the softice mouse appears briefly then disappears. The cursor blinks but it is stuck in the code window.

    I managed to watch ntfs.sys begin to parse the metafile. It took ESI+6, which is 3, did an shl, 9 to get 0x400 then compared it to that value (0x400) passed as a parameter in one of the calls. It checked a couple of other values so I need to go back and find out which metafile is being parsed and what each member means.

    Another point of interest. I know from studying the MFT that the attributes beginnng with 'FILE' are 0x400 apart. So I scrolled down to the next one in softice and the file listed was notepad. I have simplified matters this time by creating a directory aaa right under the C:\ directory. Therefore, I know I am in the right directory because the only two files in it are the file I loaded and notepad. I may need to back up to find the root.

    I was hoping to trace right through ntfs.sys to see where it returned to. That is, what called it. Unfortunately, the VM input broke down.

  6. #66
    Quote Originally Posted by Kayaker View Post
    This may be of no use, but I was playing with yet another NTFS utility, nfi.exe
    Kayaker, old boy...nfi was of considerable use. It did not solve my overall problem but an example from it might illustrate the problem I am facing.

    I have a directory, C:\aaa and in it I have two files...7z457.exe, which is the free 7zip installer, and notepad exe. Below is a partial readout from the nfi file which I got using the standard DOS redirection, nfi c: > c:\mft.exe. That gave me a 7 meg file with all the mft entries.

    File 25744
    \aaa
    $STANDARD_INFORMATION (resident)
    $FILE_NAME (resident)
    $INDEX_ROOT $I30 (resident)

    File 25745
    \aaa\7z457.exe
    $STANDARD_INFORMATION (resident)
    $FILE_NAME (resident)
    $DATA (nonresident)
    logical sectors 13718824-13720511 (0xd15528-0xd15bbf)

    File 25746
    \aaa\NOTEPAD.EXE
    $STANDARD_INFORMATION (resident)
    $FILE_NAME (resident)
    $DATA (nonresident)
    logical sectors 13195840-13195975 (0xc95a40-0xc95ac7)

    You will notice that each file is numbered, with notepad being File 25746. In hex that is 0x6492, a magic number I found while exploring with softice the other night in the NTFS.sys code. That was a good find.

    The other thing to note is the logical sector number for notepad, 13195840. There are 512 bytes per sector on my disk so that LSN converts to a byte offset of 6,756,270,080. Using the free Active@ Disk Editor, I went to that offset, and, bingo, there was the MZ header for notepad. I confirmed that by comparing it to the hex readout for notepad. I did the same for the 7zip installer.

    OK...here's my problem. How do I relate that location to the MFT file? On the nfi readout, there are 29,617 files all in MFT segments with signature 'FILE'. Those 29,617 file numbers are part pf a binary tree system that relate back to an earlier entry in the MFT.

    There are two ways I can do this. One is to decipher Microsoft's Madness, which most people on the Net have failed to do, as far as I can see. Even Microsoft claims it is not trivial to trace through the MFT. I have yet to find an explanation for the MFT on the Net other than a trivial and generalized presentation.

    The other way is the one I am undertaking using reverse engineering. I have identified the point in shell32 where ntfs is called initially. It does not make a lot of sense since it is called from the function _SHCreateQueryCancelAutoPlayMoniker.

    http://msdn.microsoft.com/en-us/library/windows/desktop/bb762140%28v=vs.85%29.aspx

    They claim this function is deprecated and that CreateClassMoniker should be used:

    http://msdn.microsoft.com/en-us/library/windows/desktop/ms688698%28v=vs.85%29.aspx

    This is further based on IMoniker:

    http://msdn.microsoft.com/en-us/library/windows/desktop/ms679705%28v=vs.85%29.aspx

    What any of this has to do with programming, hardware, or anything else is beyond me. This is highly obfuscated Greek that only Microsoft could develop.

    Whatever, it leads to NTFS.sys and the processing of the MFT file. The fear I have is that the MFT processing is related only to IMoniker and that I will have to dig further to find the real deal. I am thinking that because there are references in the initial code in shell32 to _SetFileTime and __imp__ReadFile. Why they want to set the file time before doing anything else makes little sense unless they need to set the file access time during that process. But why set the file time before finding the file?

    So...I am tracing through from there to find out how Windows finds the file. As I said, there has already been reference to the Notepad file number in the c:\aaa directory on my system. That's encouraging but the point I was at before with NtfsReadFileRecord@28 is too far past the preliminary entry into ntfs.sys, so I have to go back and see what it is doing to find file record numbers, etc.

  7. #67
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,079
    Blog Entries
    5
    Madness indeed. Maybe you've seen this in one form or another, but the beginning of this file describes the ntfs structure with some details perhaps not written elsewhere. There is mention of the b-tree, how resident vs non-resident attributes are handled, and other things which might be useful, if it's not entirely outdated that is.

    http://read.pudn.com/downloads171/sourcecode/windows/vxd/794585/ntfs/ntfs.h__.htm

  8. #68
    Super Moderator
    Join Date
    Dec 2004
    Posts
    1,486
    Blog Entries
    15
    the file access time during that process. But why set the file time before finding the file?
    SetFileTime Needs a Valid FileHandle which is fetched thorugh CreateFile so it could be an existing file or a new file by Passing OPEN_EXISTING or OPEN_ALWAYS flags

    so it already has found the file
    you can always prevent this api from setting the file time by providing appropriate values (0xffffffff) in fact all of the antivirus programs open and scans any file that you want to view before it is presented to you and they appropriately prevent changing file access time

  9. #69
    Quote Originally Posted by Kayaker View Post
    Maybe you've seen this in one form or another
    Yes...in several different forms. This one is typical of what is out there, although some are better presented than others. They talk about the MFT, describing it's structure, but none I have found seriously attempt to trace a file through it.

    Obviously some have traced through it to produce disk editors and the likes, like the Active@ Disk Editor, but even that app is only partially finished. They do a good job of laying out parts of the MFT graphically, colouring each attribute within a file. However, they have stopped short of the files with INDX signatures that represent directories. They even run out of steam in larger file headers, marking the parameters as general data. However, they do an excellent job of covering what they have covered.

    I have seen one attempt at describing how offsets are described in the MFT so as to find a file that is non resident. The difference between resident and non-resident depends on the size of the file. Only files of slightly less than 1 Kb can be stored inside the MFT. Larger files are referenced in attributes inside the MFT but they have pointers to the file which is located outside the MFT. I have given an example of that below where the 7 zip installer is located outside but referenced inside.

    I finally figured it out last night and was able to trace the 7 zip installer and notepad's location from inside an MFT record. It gets complicated because they talk in clusters and I figured out with 512 bytes per sector at 8 sectors per cluster that you multiply the cluster pointer given in the MFT by 0x1000 to get the actual byte offset outside the MFT.

    That is, 512d bytes/sector = 0x200 bytes/sector and 0x200 bytes/sector x 8 sectors/cluster = 0x1000 bytes/cluster. Therefore, multiplying the number of clusters in the MFT by 0x1000 gives the byte offset on disk relative to the beginning of the disk partition (LCN). There is also a VCN, which is the offset from the beginning of the MFT. I found another magic number in my exploration with softice, 0x1924400. I had no idea what it was but it suddenly occurred to me that it is a VCN.

    The base address of the MFT is at byte offset 0xC0000000 and adding 0x1924400 to that gives 0xC1924400, which is the offset of the 'FILE' signature representing the MFT record for the 7 ZIP file I had in directory c:\aaa. That's the record I found while tracing through NTFS.sys.

    Within that record is reference to a cluster offset of 0x1A2AA5. Multiplying that by 0x1000 gives 0x1A2AA5000 and that is the address of the MZ header for the 7 Zip installer.

    This is all a bit loose in my mind at this time and rattles around in there with other loose nuts and bolts. I need to firm up the process of how to find that record referencing the non-resident 7 Zip installer in directory c:\aaa. That could be a lot easier said than done because it involves dealing with b-trees with close to 30,000 entries. The record referencing the 7 zip installer is file record number 25745 and you can imagine sifting through more than 25,000 records to trace the b-tree.

    At this time, I have no idea where each directory has priority in the b-tree. In other words, does a directory get listed in the b-tree so it is easily found, rather than tracing through thousands of entries to find it?

    Another question to consider. If part of the b-tree path is eradicated, can it be re-constructed using what is left? I don't mean the entries that have been lost, I mean can the remainder be spliced to the root in order to see what is left?

    Each file record has an identifier, as I described in my last post. I don't know at this point if that is the identifier used by the b-tree to create its nodes.

  10. #70
    Quote Originally Posted by blabberer View Post
    SetFileTime Needs a Valid FileHandle which is fetched thorugh CreateFile so it could be an existing file or a new file by Passing OPEN_EXISTING or OPEN_ALWAYS flags
    Thanks for the info Blabs. I am going to trace through it again and this time I will pay closer attention to what is PUSHed for CreateFile.

    Quote Originally Posted by blabberer View Post
    so it already has found the file
    That's what is confusing me. Windows differentiates between a file as an object and a file as an image on disk. Obviously CreateFile returns a handle before SetFileTime is called but is CreateFile returning a handle to an abstract object or to the actual image on disk?

    Last time i passed through this section of code, or a similar one, the CreateFile process lead to SetFileTime then to ReadFile. It progressed through the fltmgr to NTFS.sys and found an MZ header. It did not do any of the stuff I have just been through in ntfs.sys like NtfsReadFileRecord, and I presumed that had been done before. When I retrace it from the stack return points I have recorded I'll know more.

  11. #71
    Quote Originally Posted by blabberer View Post
    so it already has found the file
    Just traced through the entire thing again and you are right, is has found the file by the time SetFileTime is called...even before CreatFile is called.

    I verified that by using a file that had never been loaded before. When I set a bpx at a location where a previously loaded file had broken, it missed the BP. Obviously a fresh file that has never been loaded into the file cache takes a different code route.

    After CreateFile returns a handle, the ntfs code knows about the file number for notepad. It appears in a buffer like a magic number.

  12. #72
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,079
    Blog Entries
    5
    Might as well add these three NTFS powerpoint docs to the list of reading material. Ntfs, Ntfs Recovery, Ntfs Encryption.
    Attached Files Attached Files

  13. #73
    Super Moderator
    Join Date
    Dec 2004
    Posts
    1,486
    Blog Entries
    15
    an article and a python indx parser
    http://www.williballenthin.com/forensics/indx/index.html

    @k
    hey i was thinking where i saw this nfi and had to download it to confirm (its damn old nt4 resource kit )

    want some thing glitzy and glazy ?

    check out the graphical engine for ntfs analysis (gena package from tzworks)
    will list volume wise so simply browse to c:\windows\system32\notepad.exe

    or something less glitzy is ntfswalk by dmitry byrant will list by mft ID you can use the MFT id that was gnerated by nfi to look at this

    both will show the LCN
    ntfswlak by byrant is decimal
    gena is hex dispaly

    so for me notepad is

    Code:
    C:\Documents and Settings\Admin\Desktop\oem3sr2\nfi>nfi c:\WINDOWS\system32\note
    pad.exe | grep log
            logical sectors 28616744-28616879 (0x1b4a828-0x1b4a8af)
    
    C:\Documents and Settings\Admin\Desktop\oem3sr2\nfi>nfi c: 28616744 | grep file
    ***Logical sector 28616744 (0x1b4a828) on drive C is in file number 3902.
    
    C:\Documents and Settings\Admin\Desktop\oem3sr2\nfi>
    see below for cluster run in gena

    C:\Documents and Settings\Admin\Desktop\oem3sr2\nfi>set /a 0x369505*0x1000 <--------- gena
    1766871040
    C:\Documents and Settings\Admin\Desktop\oem3sr2\nfi>set /a 28616744*512 <----- nfi
    1766871040
    C:\Documents and Settings\Admin\My Documents\dloads\ntfswalker>set /a 3577093 * 4096 <------ ntfswalker
    1766871040
    C:\Documents and Settings\Admin\My Documents\dloads\ntfswalker>

    Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

    369505000 4D 5A 90 00 03 00 00 00 04 00 00 00 FF FF 00 00 MZ............ < notepad mz header

    Name:  ntfswalker_db.PNG
Views: 144
Size:  27.3 KB


    gena will show

    Path: [root]\WINDOWS\system32:{DA6227CB-326B-4B4D-9A81-04B61F1538DD}\notepad.exe

    File Record:
    MFT entry: 0x00000f3e [3902]
    Seq Num: 0x0f3e [3902]
    Type: file
    Ref Count: 1

    Standard Info Attrib: (ARCHIVE)
    modified: 04/14/2008 00:12:30.000
    accessed: 09/03/2013 20:26:11.531
    mft mod: 09/04/2013 04:50:10.937
    created: 01/01/1980 00:00:00.000
    secure id: 0x00000000 [0]
    quota id: 0x00000000 [0]
    Jrnl num: 0x62318388 [1647412104]

    Filename Attrib: notepad.exe
    parnt mft: 0x00000a37 [2615]
    modified: 04/14/2008 00:12:30.000
    accessed: 01/20/2010 00:00:00.000
    mft mod: 04/14/2008 00:12:30.000
    created: 01/01/1980 00:00:00.000

    security descr
    resident data used: 0x0098

    Security Identifiers
    owner sid [S-1-5-32-544]
    group sid [S-1-5-32-544]

    Discretionary Access Control List
    access allowed Local System DELETE | READ_CONTROL | WRITE_DAC | WRITE_OWNER | SYNCHRONIZE
    access allowed Admins DELETE | READ_CONTROL | WRITE_DAC | WRITE_OWNER | SYNCHRONIZE
    access allowed Users READ_CONTROL | SYNCHRONIZE
    access allowed Power Users READ_CONTROL | SYNCHRONIZE


    Data Attrib: (unnamed)
    allocated: 0x000000011000
    file size: 0x000000010e00
    valid data: 0x000000010e00
    cluster runs
    0x00369505 -> 0x00369515 <----------------

    obj id
    resident data used: 0x0010
    9d30c76e-b92e-11e0-b97f-001f3a5a6fe5

  14. #74
    Super Moderator
    Join Date
    Dec 2004
    Posts
    1,486
    Blog Entries
    15
    might then as well add the completed pdf half of which i posted earlier in this thread
    ntfs_header_and_datarun.pdf
    Last edited by blabberer; September 4th, 2013 at 01:21.

  15. #75
    Quote Originally Posted by blabberer View Post
    might then as well add the completed pdf half of which i posted earlier in this thread
    ntfs_header_and_datarun.pdf
    That's good info but the reason I started this thread was to find a way to that file record from the MFT root.

    If you look on your PDF at offset 2C (A1922C) you will see the file number 0xD5C5, which is decimal 54,725. How do you wade through those 54,725 MFT files from the MFT root, all with signature 'FILE', to find that record? That's what I am trying to accomplish by tracing through NTFS.sys, hoping to find the path used by Windows to find a file on disk.

    On my external disk, there is a break between the MFT and it's metafiles, hence the the non-resident files. I am trying to decipher how the b-tree is initialized and setup to link those records.

    The record you have posted for devtes~1.hxi does not indicate the root directory. You need that to associate it with the MFT root directory record.

    I have a simplified directory at c:\aaa in which I have 2 files. I have found the record for the directory and each of the two files which are located successively in the MFT. I can trace forward and locate the MZ headers for both files but I cannot trace backward to link them to the MFT root.

    That is the problem.

    I have been scheming meantime. I thought of creating a new directory through the file manager, capturing the process, and following it to the MFT.

Similar Threads

  1. NTFS reversing
    By WaxfordSqueers in forum The Newbie Forum
    Replies: 21
    Last Post: April 28th, 2013, 00:56
  2. Qt Internals & Reversing
    By Daniel Pistelli in forum Blogs Forum
    Replies: 11
    Last Post: December 5th, 2008, 04:12
  3. problem with NTFS file encryption
    By Hero in forum The Newbie Forum
    Replies: 10
    Last Post: October 22nd, 2004, 03:49
  4. New project: RSA-65 analysis on GetDataBack for NTFS
    By Lbolt99 in forum RCE Cryptographics
    Replies: 6
    Last Post: August 1st, 2002, 14:48
  5. Write to NTFS
    By tentakkel in forum Malware Analysis and Unpacking Forum
    Replies: 7
    Last Post: October 8th, 2001, 17:18

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •