Java-Based x86 Emulator

jaavaaguru writes "Researchers at Oxford University have produced a Java-based x86 emulator that they hope will be useful in testing applications and learning about viruses without damaging the host, utilizing the robust sandboxing that Java provides. They have an online demo available that boots DOS and has some games to play. Being purely Java, this emulator should be able to run on almost anything, including cell phones." The code is not yet available outside the Oxford community; the developers are said to be working on a suitable general license. In the meantime the code can be licensed on a case-by-case basis.

What do you do when it crashes?

[CTho9305]

I was playing around with DEBUG.COM and ran "OUT 20, AX"...and now it's apparently dead [ctho.ath.cx]. A lot of things don't seem to work - e.g. "mode 80,20". Even "dir c:" when the current drive is "a:" seems to hang. I wonder how complete the hardware emulation is. Can you run Windows 3.1 on this? How about programs that probe for a joystick?

Re:Comparisons to other emulators?

[dreamchaser]

Both of those need to be ported to the target OS that they will be hosted on. A java based emulator doesn't need to be ported.

on a good Java runtime...

[dshk]

if the emulator itself runs on x86 then the just in time compiler of the Java runtime may optimize the code enough that we get back almost the original assembly code... but without any buffer overflows and other security problems - theoretically.

Re:How's the efficiency?

[sumdumass]

I don't think this is meant for a general purpose vitalization application. This is more or less a research on what something does project. More specifically, You can take a virus and run in it a way to compromise the virtual machine without compromising the machine itself. This means your output is not likely to be damaged in any ways as well as you can monitor the activity from a removed setting while maintaining a presence.

And this wouldn't be just limited to a virus program either. Suppose we had this around when sony distributed their root kit. The root kit would have likely been found faster seeing how it hides in the OS but not outside the sandbox. Also, take something like WGA. What exactly does it do? Well, we have found more and more about it as time goes on but we never had the ability to discover it all at once.

But wait, it gets better. Suppose I have a program and are all the sudden getting calls that it doesn't work after update# 2 from some other company pertaining to some other product. I could use this virtual machine to watch how the interactions between my program and this other program or see were the files were changed easily and make adjustments accordingly. This would be exceptionally usefully if some other program is a competing business who wants to blame everything on your bad programing.

Now some of this can be addressed by existing virtualization and processes already available. But the sand box functioning available with Java makes it less likely the problem can spread somewhere else un noticed.

Re:How's the efficiency?

[slamb]

More specifically, You can take a virus and run in it a way to compromise the virtual machine without compromising the machine itself. This means your output is not likely to be damaged in any ways as well as you can monitor the activity from a removed setting while maintaining a presence.

Well, that's great, but you can already do that with VMware, Parallels, QEMU, or other virtualization tools. Sure, virtualization requires the same host and guest architecture, but we all have plenty of x86 machines sitting around, and near-native speeds are necessary to actually boot Windows Vista before the sun goes supernova. So while this is neat software, it's not as suitable for malware researchers as what they are already using. The JPC project needs to find a different niche.

Re:Interesting, but

[chorltonian]

Errm... how about trying it out before judging it? As has been covered god knows how many times before, Java is capable of runtime optimisations not possible with statically compiled languages like C++.

Re:Can I conclude: Survive /. effect = robust

[animaal]

If this webapp. survives a lot of geeks messing and hacking about in that virtual machine I'd be very tempted to label this as a very interesting experience when it comes to the Java robustness factor.

There's no danger to the virtual machine. The emulator and disc images are all run within the browser. So each browser receives its own emulated memory space and fresh disc images. No processing occurs on the server (except for serving the application code and disc images to the browser).

Compared to what?

[alienmole]

You're missing something here. Sure, Java is faster than some languages like Python or Ruby or PHP, but that doesn't necessarily put it in the realm of languages that are a good choice for implementing hardware emulators. There are many other languages that would be faster and, at the same time, more high-level than Java. (The ML family comes to mind.) The Java sandbox argument they use in this case is rather bogus - if you're writing an emulator, you can easily build sandbox functionality into it. In short, the choice of Java for this project is nowhere near as rational as the authors would have you believe. They probably chose it because that's what they were familiar with, or because it helped them get funding.

Re:license

[mohjlir]

So should we just run OSS news? Then all the MS trolls would have to get jobs! Seriously, this is news no matter what the copyright holders intend to do (or charge) for the software.

Re:Interesting, but

[Anonymous Coward]

Don't you know, around here:

• All Java is slow
• All Perl is unreadable
• All PHP is insecure
• All JavaScript is a useless intrusion into your browser

... and all comments like those are written by "experts" who've never written one line in the language in question.

Re:Ah, a Java-based x86 emulator...

[Anonymous Coward]

"Since when did emulators become news on slashdot?"

Sadly it's not just slashdot. I seem to encounter lots of sensational sounding studies by nonspecific "researchers at [Cambridge|Oxford]" performing miraculously mundane feats in the news. In scotland it's also fairly bad with the BBC local news often reporting about research at Glasgow University which is often, quite frankly, fucking laughable.

Re:Interesting, but

[MobyTurbo]

Errm... how about trying it out before judging it? As has been covered god knows how many times before, Java is capable of runtime optimisations not possible with statically compiled languages like C++.

Maybe so, but it is running much slower than DOSEMU or DOSBOX does in Linux here, which are probably written in C or C++, with possibly some assembly; and can do emulation of all the games it emulates. Java is indeed capable of certain optimizations that are not done in a non-JIT compiler, but that simply is because it needs them. Anyone who tells you that Java operating system emulators typically run faster than C operating system emulators has been smoking SUNW crack. That having been said, there are reasons for choosing Java over C. One of them is built-in security sandboxing, which was obviously the reason for the choice.

Re:Interesting, but

[tomhudson]

Errm... how about trying it out before judging it?

errm ... how about because the applet failed to load?

If you go to the site, you'll see their premise is stupid - that game companies will license this to sell old dos games on cell phones, rather than porting them. Of course what they overloook is once you have the emulator, you don't need the game companies - just go through any abandonware site, or your stacks of old floppies.

Flamebait??

[Weaselmancer]

Hey mod, I'm serious and I'm making a serious point.

Porting the JVM somewhere is about as much effort as porting a word processor, or any other 100 meg application. But if you port the JVM, all the applications you have in Java are ported by proxy. It's a one-time task.

So if your 100 meg word processor is in Java, once you port the JVM you get the word processor for free. And all of your other Java applications. You don't have to port them seperately. It's one porting task and then you're done.

And now that the JVM is open source, you can expect that to happen more often. It's part of the beauty of running VM based languages.

Re:Interesting, but

[heinousjay]

Awesome, you've successfully combined unnecessary anger, anecdotal evidence, the arrogant assumption that only your opinion matters, a Slashdot meme, and a bunch of insults into one post. I think you get some kind of award for that.