changing what's running in Vbox.

[rewolff]

Hi,

I have a very special problem.

I need to stop/pause a running virtual box, and then insert a program that should start running inside it. The program only uses BIOS calls and no operating system, so the currently running OS need not be bothered.

Any suggestions?

Can I attach a debugger to the vbox process, and then memcopy the application in there? But how do I tell vbox then to start the application?

(the OS in the vbox crashes. so I need to start a recovery application....)

And, yes, this seems to be the easiest way. Accessing the disk directly will not work.

[TerryE]

I need to stop/pause a running virtual box, and then insert a program that should start running inside it. The program only uses BIOS calls and no operating system, so the currently running OS need not be bothered.

This sounds to me like you have a problem that you are trying to solve, and picked a solution which isn't solution because it doesn't work. I don't know how to phrase this tactfully, but (given the information that you've sketched out) what you are trying to do is just daft.

(1) Have a look the Forum Posting Guide and think about reframing your Q. (2) why not just step back and try to explain the underlying problem that you are trying to solve and we can give you a more doable approach. Why do you want to call the BIOS? What are you trying to achieve here? What are you stopping and why?

[rewolff]

The situation is as follows: I have system with an encrypted partition. The owner of this disk has requested me to recover their data from that partition. The other partition is just the DELL stuff.

The encryption is something like AES: Unlikely to be broken. The partition is COMPLETLY encyrpted. Even the NTFS boot block is currently stored as 'garbage".

So when I start Virtualbox on the disk image, it starts booting windows. It comes as far as: "loading .... dontgo.sys" and then hangs. This also happens in "safe mode".

From the fact that it loads, apparently, it managed to decode the NTFS boot block, the boot loader, and the NT kernel (or whatever it's called). So without me having provided the system with a password, the encryption software already knows the decryption key! So besides using a strong encryption algorithm, again the "stuff around it makes all the difference": It stored the key somewhere!

I have this program that runs under DOS, that will use the BIOS to request a disk block, and then send it to my server for safe storage. I was hoping I could sneak in and insert it into the VM at some point during the boot.

Suggestions?

[TerryE]

OK, this I understand as I have PointSec Encryption on my Laptop. I also use VBox happily. What happens in the NT boot sequence is that you can add drivers into the initial load sequence. This is really to allow you to boot off SCSI etc., but these encryption packages use this to encrypt the disk. Once this driver has intercepted the block I/O path then all blocks transferred to and from the disc (or possible a subset of partitions) are treated as encrypted. The most common algo is AES because it is fast and strong. Typically each block is encrypted by a key which is a combination of the block or cluster number and a disk-specific key hidden away on partition somewhere in an obfuscated form.

BTW this is really the Achilles heal of this type of encryption scheme, if you know the location and the obfuscation algo then you can easily crack the encryption. However only the vendors (and most security services and any gifted hacker who wants to reenginer the encryption driver) know this so you should be quite safe. The corollary to this is if you are truly paranoid and don't want the security services to know the contents of your HDD then always use an encryption system that prompts for an external pass phrase that only you know. That way the security services will need to kidnap you and pack to off to Guantanamo Bay or wherever to get it out of you

Anyway back to the plot. I doubt that the boot block is garbage. The data and code bootstrap loaded before the encryption driver must be in plain content. I think that we have three scenarios here and in all three I am assuming that the owner has access to and can log onto the encrypted system. (If this isn't the case then you need to go to another forum.)

• Your virtual HDD is in a VDI inside the encrypted file system. In this case you just need to log on and do a file copy onto an external NAS or whatever.
• Your partition is inside the encryption scheme; in which case you need to use a partition save utility which runs within the OS and encryption perimeter. This will "see" the blocks in an unencrypted form and the partition can be dumped again to NAS or whatever.
• Your partition is outside the encryption scheme; in which case you need to boot from a LiveCD and use a partition save utility which runs outside the OS and encryption perimeter.

However you say

So when I start Virtualbox on the disk image, it starts booting windows. It comes as far as: "loading .... dontgo.sys" and then hangs.

which actually makes me think that this has nothing to do with encryption but with your P2V (physical-to-virtual) strategy. dontgo.sys is the Promise eSata controller driver. You can't use eSata inside a VM. It will just cause your VM to hang, which is what has happened here.

The booting OS see a Virtual Machine that is very different to the physical one it was configured for. This is very similar to taking out the HDD and just putting it in a completely different machine: different graphics card, different disk controller, ... As a result if any of the drivers are expecting say an eSata controller that isn't there then at best they will just exit cleanly as if not called. At worst they will simply cause the system to hang.

[rewolff]

You're right. The DISK's boot block is plaintext. It contains references to the company that made the encryption stuff.

The partition's boot block ("it's called NTFS boot block, which is what I called it) is encrypted, together with the rest of the partition.

So, yes, the disk's boot block boots, loads the encryption software, finds the key, and then decrypts the NTFS partition transparently so that the Windows kernel can boot.

You're right, the system is configured for different hardware than what is present in the virtual box. However, booting in safe mode should usually work. Right? No such luck this time.

You're right I have the skills to trace the encryption software to the point that I can find where it has the obfuscated key, and then decrypt the whole partition. However I don't have the time to do this right now. I was hoping to find a way to just stop the VM in it's tracks and use the facilities available to the OS inside the VM to read all the data....

The physical disk that this was on, is broken. The machine this used to be in, is not available to me right now.

[TerryE]

Rewolf, I have a great deal of sympathy with your plight. My company has about 140,000 encrypted PCs and Laptops: company policy and actually for very sound business reasons: it creates a step decrease in the risks of data loss from the trickle of thefts that invariably occur. However, encryption is a two edged sword and it itself also creates a loss of data and denial of service when things go wrong. Our internal engineers forums abound with chatter, complaints and disaster stories about the damage caused by our encryption product.

Our executive policy here is very simple: kits breaks and gets stolen. If you have critical business data on your local HDD then it is your responsibility to back it up using the company supported backup products. End of Story. [Maybe we work for the same company ]

I really don't think a VM approach is going to help you recover your data.