Nach Torjaner Meldung Windows Defender: vdi nicht zugreifbar

[lagorth]

Liebe Community,

nachdem ich viele Foren gelesen habe, konnte ich leider folgendes Problem nicht lösen:
Nachdem im laufenden Betrieb der Virtual Box die vdi von Windows Defender als Trojaner klassifiziert wurde, lässt sich die Sitzung nicht mehr starten. Ich habe die Dateien bereits als nicht schädlich markiert, das Problem bleibt jedoch bestehen.

Unter Massenspeicher steht folgender Eintrag: SATA-Port 0: vdi (normal, Nicht zugreifbar)

Fehlercode:

Für die virtuelle Maschine StatsCrewSoftware konnte keine neue Sitzung eröffnet werden.

Could not open the medium ...\StatsCrewSoftware\StatsCrewSoftware.vdi'.
VDI: invalid pre-header in ...\StatsCrewSoftware.vdi' (VERR_VD_VDI_INVALID_HEADER).
VD: error VERR_VD_VDI_INVALID_HEADER opening image file 'C:\Users\Nils Rosjat\VirtualBox VMs\StatsCrewSoftware\StatsCrewSoftware.vdi' (VERR_VD_VDI_INVALID_HEADER).

Fehlercode:
E_FAIL (0x80004005)
Komponente:
MediumWrap
Interface:
IMedium {ad47ad09-787b-44ab-b343-a082a3f2dfb1}

Die letzten Log-Files habe ich als Zip angehängt.

Was kann ich noch tun? Für meine Arbeit verwende ich ein altes Programm, welches ich so unter Windows 10 32-bit laufen lassen kann.

Vielen Dank für baldige Hilfe

EDIT: Ich habe jetzt eine neue Maschine erstellt und auch da nach kürzester Zeit den Fehler des Windows Defenders erhalten und konnte die Maschine daraufhin nicht mehr starten.

[mpack]

This doesn't look like a hardening problem, it looks like standard corruption of a VDI header.

Try repairing the VDI using CloneVDI. Remember to keep the original UUID.

[lagorth]

Thanks for your reply. Unfortunately, it doesn't seem to work:

The VDI failed header validation checks and would normally be considered unreadable. CloneVDI can attempt to infer a new header but this may not work and could result in total failure or a badly corrupted clone. You should test the clone (if any) throughly before relying on it.

Do you wish to continue? Yes

Whic results in the following Error:

Source has strange format or has been corrupted.

Any other ideas?

[mpack]

Ok, so corruption is now confirmed. Incidentally, if you put "Language=2" in the CloneVDI.ini file then it will work in the German language.

If CloneVDI says it can't be repaired then I know of no other way to repair it, except from a backup. It means that it doesn't just have a bad header, the corruption must permeate through parts of the file that CloneVDI can't fix.

How was the VDI recovered? If it was through a undelete tool then you should know that those tools are almost always snake oil. The file might be the right size (it gets that from the directory entry), but the content is random.

Also your earlier comment that Windows Defender tagged a VDI as a trojan makes little sense to me. First, as far as I know Windows Defender will usually only do that kind of analysis on executable files, which a VDI is most definitely not. Second, I imagine that the vast majority of visitors here are using Windows 10 with Windows Defender enabled, and I've never heard of any such problem being reported. Finally, even if Windows Defender did label a file as a trojan, why would that corrupt the file? All Defender would do is list that file in a table of threats, and warn you that it was present.

The only explanation that does make sense to me is that in fact it was never a vdi, it was always an executable perhaps containing a known trojan. But in that case it's unlikely it was ever a working VDI.

Here's something I have not done in a long time. Please use a hex editor or similar to save off the first 2101248 bytes to a binary file. Zip that binary file and attach the zip here. I will take a look. Also please report the exact size (in bytes) of the remaining VDI file.

[lagorth]

Ok, so corruption is now confirmed. Incidentally, if you put "Language=2" in the CloneVDI.ini file then it will work in the German language.

Didn't change the outcome.

How was the VDI recovered? If it was through a undelete tool then you should know that those tools are almost always snake oil. The file might be the right size (it gets that from the directory entry), but the content is random.

The file was never gone. So no recovery involved. The only thing that happened was that Virtual Box shut down, when Windows Defender popped up.

Also your earlier comment that Windows Defender tagged a VDI as a trojan makes little sense to me. First, as far as I know Windows Defender will usually only do that kind of analysis on executable files, which a VDI is most definitely not. Second, I imagine that the vast majority of visitors here are using Windows 10 with Windows Defender enabled, and I've never heard of any such problem being reported. Finally, even if Windows Defender did label a file as a trojan, why would that corrupt the file? All Defender would do is list that file in a table of threats, and warn you that it was present.

For me that's the mysterious part. I was working with this vdi for over a year now and it was also running for several hours yesterday while I was working with an old 8-Bit program (the reason to use the VM in the first place). There were no particular events that could be the reason to trigger this issue.

Trojan:HTML/Phish.C
file: ...\VirtualBox VMs\StatsCrewSoftware\StatsCrewSoftware.vdi

Last night, I also tried to just setup a completely new VM with a new VDI and after a few minutes got the same Windows Defender message after which the VDI wasn't working anymore. So for me it seems like the trigger for this problem is not really related to the specific vdi.

Here's something I have not done in a long time. Please use a hex editor or similar to save off the first 2101248 bytes to a binary file. Zip that binary file and attach the zip here. I will take a look. Also please report the exact size (in bytes) of the remaining VDI file.

I'll try that when I'm back at my computer.

[mpack]

Last night, I also tried to just setup a completely new VM with a new VDI and after a few minutes got the same Windows Defender message after which the VDI wasn't working anymore.

I saw that. The only explanation that makes sense to me is that you have some kind of infection on your host, it is corrupting host files (*). Obviously, malware inside a guest can't do that.

(*) If the only symptom was that large files were being corrupted, I would suspect some kind of hardware problem with the host drive. That would not explain the trojan alert, but that could be a red herring. A filesystem check of the host drive might be useful.

[lagorth]

Also please report the exact size (in bytes) of the remaining VDI file.

File size is: 27.450.671.104 Bytes

But the first 2101248 Bytes are just empty. The first non-empty byte appears at offset 108A00000. I guess I will continue getting my last backup up to date.

[mpack]

The first non-empty byte appears at offset 108A00000.

I assume you mean zero rather than empty. 0s are data too!

But again this is looking like a recovered file, otherwise it would have taken some app a good long time to zero fill >4GB worth of data in a file. I'm taking your assertion at face value btw, though the question does occur of how you established that everything up to that offset was zero, since eyeballing 4GB of data would take a lot of time too.

[lagorth]

though the question does occur of how you established that everything up to that offset was zero

Brute force, tried searching for the first appearance of each possible Hex-Value.

Anyway, thank you for taking the time.