Page 1 of 2 12 LastLast
Results 1 to 15 of 16

Thread: SoftIce - Breaking on phisical sector access

  1. #1
    ATY
    Guest

    SoftIce - Breaking on phisical sector access

    Hi

    I have a strange bug in an app being developed at my work place:

    We develop an application on a Win2k environment.

    on a specific sequence, when we crash our app (we use a known bug in a VB control), a specific file, that is not related to the bug/crash, is being partialy overwriten with a piece of memory dump - the first 450 Kb of the file are overwritten with some garbage memory content (a bitmap in this case, since we crash our app while it tries to load that bitmap).
    The application crash doesn't cause blue-screen but only pops Dr.Watson (we tried to look at Dr.Watson's log file, but found nothing related to the file being overwriten).

    The file that is being overwritten is .MDB file and is about 6 megs. We access this file (using MS Jet) before we initiating the crash (when the app starts), but we dont access it during the crash (we checked that the file is closed after we access it).

    We suspect Windows Write Cache mechanism, but can't be sure.

    Using File Monitor revealed nothing (it didnt show access to this file during the application crash - but the file was damaged anyway)

    Our system is Win2k SP2 running over some embedded system (generally a Pentium 3 / 256 RAM - but not a regular Desktop PC)

    In order to understand what exactly is causing this file "smash" I though about using SoftIce. I suspect that breaking on standard Win32 API (WriteFile) wont help, as FileMon wasn't able to trap it. we suspect that something is going wrong in the kernel level, not the application level.


    So, finally... How can I break on a disk access to a specific file, or, even better, how can i break on disk access to a specific phisical sector ?

    What we finaly wanna discover is what causing this file overwrite.
    (btw, any ideas other that the suggested are more than welcome)

    10x in advance, ATY.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  2. #2
    at a guess,you could try setting up a seh handler, that closes all handles to the database, then shutsdown the application gracefully, that might stop the file corruption, as for monitoring a sector write,that could be pointless as if the file is written to,windows will probably move the data to another sector, write the information, then update the fat tables.. try the seh approach, it might work

  3. #3
    Howdy,

    I am confused. You say :
    on a specific sequence, when we crash our app (we use a known bug in a VB control), a specific file, that is not related to the bug/crash,
    Please tell me how this file is not related.
    Explain how the .MDB file is used.
    Is this prog a 3rd party app?

    Woodmann

  4. #4
    ATY
    Guest
    Quote Originally Posted by Woodmann
    Howdy,

    I am confused. You say :


    Please tell me how this file is not related.
    Explain how the .MDB file is used.
    Is this prog a 3rd party app?

    Woodmann
    Woodmann: What I meant is that the .MDB file that is being overwriten, is not accessed for long period before we attemp to generate the crash.
    The crash is generated by exploiting a bug in an Internet Explorer VB Control: we load a large HTML file with loads of images, scroll it down quickly, and at the same time trying to close the form - it simply crashes the VB layer (the GUI) of our app.

    The .MDB file is accessed by using the Jet engine. a data from that file is beeing read while our application starts (this only happens when the aaplication starts, leter, we dont read/write to this file).

    The prog is no 3rd party, but beeing developed by my company. Unfortunately, I can't post it over the Net.

    evlncrn8: I understand that phisical sector might be problematic, since windows might move data. however, our app doesnt write data to the .MDB file, but only reads from it.
    If we can trap access to a specific FILE or an entry in the MFT - that can be also helpful.

    10x, ATY.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  5. #5
    evlncrn8: I understand that phisical sector might be problematic, since windows might move data. however, our app doesnt write data to the .MDB file, but only reads from it.
    If we can trap access to a specific FILE or an entry in the MFT - that can be also helpful.
    -------------------

    if thats the case then why not just set the file attributes of the mdb file to read only..that should prevent it getting corrupted.. in theory anyhows

    also, perhaps this could help

    http://www.granite.ab.ca/access/corruptmdbs.htm
    Last edited by evlncrn8; March 11th, 2004 at 03:55.

  6. #6
    ATY
    Guest
    Quote Originally Posted by evlncrn8
    if thats the case then why not just set the file attributes of the mdb file to read only..that should prevent it getting corrupted.. in theory anyhows
    Hehe, We thought about it at first place, but read-only attribute seem to have effect only on the application level. Windows internal mechanisms (such as write cache, or swap) are not affected by this.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  7. #7

    As Above

    It seems that the problem needs to be approached logically. Once you apply your mind, it all falls into place. Correct me if I am wroing somewhere but...

    1. I understand that you are opening the access file
    2. I also understand that you are NOT closing the access file before the crash.

    These lead me to believe that the following may be happending:

    1. You open the MS access file
    2. You open the application
    3. This implies that both are loaded somewhere in memory
    4. You crash the application, which overwrites something in the memory (possibly the space where the OS had loaded the access file)
    5. This seems to be a perennial problem with SOFTICE too. You open the file in memory (any app), change the bytes in memory, and close softice. You'll find that the file got modified!!. This type of memory access and overwriting is obviously not going to be shown in filemon/regmon or even softice itself.

    To solve this you may need to:

    1. Use softice (possibly in Win98 -- I'll explain why)
    2. Load access file, load app
    3. Ctrl_D to ice and find where in mem the access db is located
    4. BPR on the entire memory (that's why you need win98)
    5. Now Ctrl_D again and come out of ICE
    6. Work on app as required, and see what hits. Chances are, its gonna be the rouge low-level process that modifies the file

    However, if you are REALLY stuck only on Win2k and above platforms then to prove that the same is being overwritten in MEMORY and not on the disk, do this:

    1. Use Softice (NT version)
    2. Load MDB, load app
    3. Ctrl_D and see memory of MDB file
    4. USE THE COPY COMMANDS TO MOVE THE MEMORY OF MDB TO A SEPERATE MEMORY REGION OR FILE (Check out tools on programmerstools.org for memorydumpers)
    5. Work normally.
    6. Just before the app exits (mostly, hits doctor watson -- you'll have to figure out that bp) go to ice and use the MEMORY COMPARE for MDB files
    7. If different, you KNOW that its being modified in memory

    You'll not get much ahead by using disk monitoring, because its NOT modifying the file on the disk, but the memory.

    Have Phun
    Blame Microsoft, get l337 !!

  8. #8
    Musician member evaluator's Avatar
    Join Date
    Sep 2001
    Posts
    1,518
    Blog Entries
    1
    Lets firstly determine, IF file corruption happens
    because of DR.Whatson's logging or memory dumping engine;
    for this you can turn off both service & crash again your app.

    then..

  9. #9
    Naides is Nobody
    Join Date
    Jan 2002
    Location
    Planet Earth
    Posts
    1,647
    Quote Originally Posted by ATY
    Hi

    I have a strange bug in an app being developed at my work place:

    We develop an application on a Win2k environment.

    on a specific sequence, when we crash our app (we use a known bug in a VB control), a specific file, that is not related to the bug/crash, is being partialy overwriten with a piece of memory dump - the first 450 Kb of the file are overwritten with some garbage memory content (a bitmap in this case, since we crash our app while it tries to load that bitmap).
    The application crash doesn't cause blue-screen but only pops Dr.Watson (we tried to look at Dr.Watson's log file, but found nothing related to the file being overwriten).

    Out my deep ignorance.

    This behavoir, writing a memory dump, conceded to the wrong place, appears to be a 'fossil' of the recovery procedure. You guess the routine happens inside windows Kernel, which is quite likely, as most low level disk access is handled by this system dll, but, rarely does any other crash result in the memory dump overwritting a file.

    1-I think the root of the problem is in the VB routine you use to provoke the crash. As it is not vital to use such routine, can you start the crash using something else? A quick and dirty asm protection fault code perhaps?

    2- Windows use API to tell the kernel what to write on the disk, but deep down to the metal, kernel uses software interrupts to do disk I/O. You can place interrupt breakpoints in softIce BPINT 21 if ax==4 or something like that to catch the kernel preparing itself to write a sector into the disk. then you do your autopsy and figure out what kernel routine called the interrupt, and who called that routine.

  10. #10
    ATY
    Guest
    Quote Originally Posted by evaluator
    Lets firstly determine, IF file corruption happens
    because of DR.Whatson's logging or memory dumping engine;
    for this you can turn off both service & crash again your app.

    then..
    evaluator: good idea. however, we tried that, and the corruption still occure.

    Aimless: We run a query on the file using DAO (MDAC) (that uses the Jet engine). Basicaly we open the file and then close it.
    Although I didn't check it yet, I hardly believe that the entire file remains in RAM since its 7 megs, and there is no good reason to keep the entire file or portions of it in RAM after it is no longer needed.
    The corruption occuers only later (during the crash), long after we closed the file.

    Another direction we think of, is that pointers in the MFT are getting corrut and that causes the problems (the actual phisical sector may not change, but when u try to access the file it is being read from different place).
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  11. #11
    least
    Guest
    Hi,
    maybee I'm wrong and what I'd do can't be done in W2K, but what about trying what aimless says with one modification: Trying virtualprotect(ex) on pages that contain MDB file setting guardian flag (it could mimick softice BPR command), so the code that access it should generate page fault and softice with faults on should catch it (hope so).
    Or what about good old BPM R ...
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  12. #12
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,147
    Blog Entries
    5
    Hi

    I wonder if it would be possible to flush the cache buffers after you are done with the mdb file. I'm just surmising as to how the read operation actually works, but say you ask MSJet to open a file, it calls CreateFile with FILE_SHARE_READ + FILE_SHARE_WRITE access (in case you are wanting to write to it), then maps a view of the entire file into its own address space with CreateFileMapping and MapViewOfFile, passing you the starting address of the mapped view. Or maybe the starting address is passed to the DAO engine and awaits your SQL queries.

    Now let's say you write to the file then "close" it from within your app. You assume you are done with it, but in reality the system will do the actual writing to the file on disk in its own sweet time. The WriteFile call itself is probably part of the Jet engine, but even then the actual writing won't be done immediately unless FlushFileBuffers is called. The writing phase may be in a separate callback thread that may have other I/O operations queued, possibly not even finishing until the system has dealt with more pressing processing matters.

    In the meantime, you're busy distracting the CPU with loading bitmaps and quick display updates due to the rapid scrolling, plus handling the deliberate crash and calling poor old Dr. Watson. Somewhere in there you overwrite the mapped view with the bitmap parts, and finally when things settle down the system gets around to writing its queued I/O operation, now corrupted.

    You say you aren't actually writing to the file, but I think the principal may still hold. Perhaps there's a call to FlushViewOfFile (as opposed to FlushFileBuffers) which also ends up writing a corrupted image to the disk file. As Aimless mentioned, something along these lines often happens when you make changes to memory within Softice. This seems to be language specific as well (often occurred in MS Visual C++ v5 & 6 apps as I recall, but not every one, and I don't think anyone figured out the exact reasoning behind it).

    Actually, you said it was a "long time" between when you close the file and the crash occurs. Perhaps you can use DuplicateHandle in some way to force the Jet engine to finish completely with the file + mapped view and clean up. Again, I'm just throwing out ideas here, maybe if you used DuplicateHandle with the DUPLICATE_CLOSE_SOURCE flag, you could force the original handle to the file to close, which might effectively "sever" the faulty connection and flush the buffers, then close the useless duplicate handle.

    Perhaps none of this applies, but as you mention it does seem to have something to do with the write cache mechanism.

    Regards,
    Kayaker

  13. #13
    The DAO and the MDB file work together AFAIK.

    You cant stop using one without the other unless you have
    written some custom DLL files.

    Check these to make sure they are not being used some where else in your program.
    Since the crash is writing to your MDB file it is still open. The DAO must also be stopped or it will keep the MDB file open even if you tell it to close.
    You may also have a DLL issue.

    Thats my best guess

    Woodmann

  14. #14
    ATY
    Guest
    Another pieces of (interersting) information:

    We experienced another file overwrite - this time not .MDB.
    We have 2 data files (that we didnt access at all while generating the crash) that got overwritten, this time with portions of the .MDB file (!) that got corrupted in the first place...

    common things to the corrupt files: all are large files (above 2 megs), we tried to put smaller files in the same dir where we keep the .MDB file and nothing happened to them.

    All the corrupt files (the .MDB and the 2 data files) are in virtual drives that where created by a subst command (i.e. the directories were mapped to drives). We dont wanna use "net use" to map those directories because of performance issues.
    The .MDB and data files are on different "drives".

    Kayaker: from what I understand, in order to be sure that the data is actually written to the disk, we have to "manually" flash the cache after each file access... I think it might be easier to simply turn of the Write-Cache mecanism (paying with some performance decrease). However, if something in the MFT get corrupt, I suspect the file overwrite might still occure.

    P.S: after the file corruption occures, we run chkdsk and it returns with errors. we fix with /F, then on the next file corruption, errors return.
    for example, one time, after running chkdsk /F the .MDB file size went to zero.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  15. #15
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    Very strange, the disk corruption issue (and the writing to files that are never opened at any point) suggest that the problem is not on application level, but rather on operating system level. If this is the case, the issue might in turn be used as an attack for bypassing filesystem permissions and such, and if you manage to find the source of this problem you might very well get your name on a Microsoft Security Advisory.

Similar Threads

  1. Breaking in DAV RPC INTERFACE : Peripherals
    By OpenRCE_adityaks in forum Blogs Forum
    Replies: 0
    Last Post: November 30th, 2007, 12:20
  2. Breaking 104 bit WEP in less than 60 seconds
    By evilcry in forum RCE Cryptographics
    Replies: 3
    Last Post: April 20th, 2007, 08:31
  3. Breaking on file acces...
    By GooseWrecker in forum OllyDbg Support Forums
    Replies: 1
    Last Post: May 13th, 2005, 05:13
  4. Breaking on execution with installshield
    By kittmaster in forum OllyDbg Support Forums
    Replies: 10
    Last Post: March 3rd, 2005, 22:56
  5. Breaking on an API programmatically
    By Iwarez in forum Off Topic
    Replies: 2
    Last Post: April 10th, 2003, 16:52

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
  •