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.

Interesting, but

I can only imagine that this will make even Bochs look fast in comparison!

Still, I'd love to tinker with this from a 'gee whiz' standpoint.

Re:Interesting, but

I'd have to agree. Using instruction-by-instruction emulation, a C++ based SNES emulator I wrote around 1998 used at least 150Mhz of processing power to emulate the SNES' 3Mhz processor. When I rewrote it in assembly, it was 5-10 times faster. I expect that some pretty sophisticated techniques would be required to exceed a snail's pace when using Java for emulation, eg "dynamic recompilation": translating sections of x86 machine language to Java bytecode... but getting this to work 100% correctly would be pretty tricky.

If it's hard to get good emulation speed in C++, it's even harder in Java.

can you run java in the x86?

THe next question would be: can you run java in the x86 emulator that runs an other emulator that runs java, that runs an other emulator.

Just like the old days when you ran windows real mode under a windows 386 mode windows.

Re:can you run java in the x86?

Linux on emulated hardware can be faster than Linux on real hardware:

There you go, a perpetual speedup machine. Run enough layers of Java on X86 on Java on X86 and supercomputers will be replaced by Cyrix 386s.

Re:can you run java in the x86?

The next question would be: can you run java in the x86 emulator that runs an other emulator that runs java, that runs another emulator.

...written in XSLT.

Re:can you run java in the x86?

Yes.

The next step is to get rid of hardware altogether.

Re:Interesting, but

'Java is capable of runtime optimisations not possible with statically compiled languages like C++.'

And with them it can perform almost as fast as C in some fringe cases.

Re:Interesting, but

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:Interesting, but

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.

So...

... now we should say: "x86 assembler: write once, run everywhere (slow as molasses in January)" ?

How's the efficiency?

Whilst this looks like a really interesting project, I'm failing to see how it's useful generally due to the limitations of writing it in Java and making it cross-platform. You would lose a lot of those possible (processor- or platform-specific) optimisations that make the leaders in the virtualisation market as fast as they are.

On, say, a mobile phone (which is mentioned by the site as a possible use) would there be enough processing grunt to do anything useful? I know Java's not as slow as some people would have you believe, but virtualisation requires as much speed to be squeezed out as possible to be usable.

On a desktop, what advantage does this have over the existing virtualisation options which don't have to deal with the Java environment?

Well for one

For one this will let you run X86 DOS applications on a SPARC for example.

I'd like you to point me to the support page for VMWare on SPARC... oh wait that's cause there isn't one. QEMU can't even run most applications on a SPARC.

And forget about ARM.

I think this is great. Java is not as slow as people seem to think it is. One thing Java 5 (and 6) have that actually benefits virtualization is dynamic recompilation... the JVM knows the instruction sdequences better than the original author, and in theory can optimize the code paths in ways writing a virtualizer in assembly or C++ can not.

Re:Well for one

If you are using Firefox with Java and having ridiculous applet startup times, you need to disable your Java Cache. This is Java's fault, not Firefox's (supposedly).

Under the Java control applet, under the General tab, click "Settings..." under "Temporary Internet Files". Then click "View Applets...". It will take a moment to load (or in my case, 2-3 minutes). Then UNcheck "Enable Caching". Firefox now starts my applets almost instantly. This doesn't affect downloaded Java applications such as Azureus or Eclipse (both of which I use extensively).

Hope this helps.

Re:How's the efficiency?

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:How's the efficiency?

near-native speeds are necessary to actually boot Windows Vista before the sun goes supernova.

The sun isn't close to large enough to end in a supernova; it'll be a red giant, then end as a white dwarf.

Two great tastes

Talk about gilding the lily!

What's next? A Windows emulator written in Intercal?

What's wrong with virtualisation?

What's wrong with virtualisation? Yes, you can't run it on a phone's ARM processor but you wouldn't do that in the first place.

Java x86 emulator speed

Java only: snail speed
Java+DOS: Snail with ball and chain
Java+DOS on non x86: Snail nailed to the table

So it runs DOS eh?

But can it run Linux. . .?

Why did they use Java? It would have been faster in C++.

I for one welcome our new old x86 overlords.

Did I miss any?

Re:So it runs DOS eh?

In Soviet Russia x86 emulates Java?

java me is not java se

It will take some work to port.

But still cool though.

What do you do when it crashes?

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?

on a good Java runtime...

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.

Oh No

I accidentally formated my virtual floppy and hard drive.

Commander Keen!

Yeah yeah yeah, it's sort of slow, if you screw around with the debugger it dies, but...

They've got Commander Keen!

Java isn't slow anymore

The first ten reactions are about how slow Java is. Wake up! It's 2007, NOT 1997. The world has changed. Don't you keep your knowledge up to date? Are you amateurs? And no, a benchmark from 2001 doesn't count too.

Keyboard Layout change hangs

The first thing I typed at the prompt was "keyb sf" and it hangs... Great...

I can use the US layout, that's not it, but I prefer to see the letters on my keyboard when I type.

Other projects doing the same/faster thing..

There are at least 2 solutions doing a similar thing. The open source binarytranslator.org/PearColator offers x86 and PowerPC emulation:
http://binarytranslator.org/ [binarytranslator.org]
There are attempts to integrate this into the JNode open source Java OS to make a JNode/GNU stack.

There is also the VEELS/JXEmu system:
http://nil.ics.uci.edu/~gal/?page=VEELS [uci.edu]
which appears not to be publicly available.

My intepretation

An interpreted language being used to write an opcode interpreter.

For an encore, perhaps they can write a JVM in BASIC.

WARNING: Performance implosion imminent due to recursive interpretation.

license

Do me a favor and don't pimp software until we can be sure it is non-proprietary.

Why not Simics?

I can get Simics for free if I am an academic and Simics gives over 300 MIPS on 2GHz AMD64s (and probaly a lot more on the Core 2 CPU). I really fail to see the use of something that probably is dog slow, written in Java, and probably cannot do reverse execution. Oh, btw, Simics does x86, x86-64, SPARC V8/V9, PPC32/64, MIPS32/64, ARM and perhaps some more.

Can someone explain the advantages of the Java based x86-emu in TFA over something like Simics?

I tried the demo, but it didn't work

via my Firefox on Kubuntu using the Java 1.5 plugin.

The demo started up okay, booting and getting to an A: prompt. But it wouldn't accept keyboard focus so I couldn't enter any instructions to run any of the games.

I contacted the project to let them know. They responded that I probably need to upgrade to Java 1.6 to insure keyboard focus. It's also possible that one of my Firefox extensions might have interfered. They said they have tested JPC with Firefox and Linux but not with Kubuntu specifically.

I was surprised that the startup worked fairly well. There is a very long delay while the Java applet loads and I thought Firefox had frozen, but eventually it started up rather well.

Java is fine for emulation

[1995] When I was at university [unsw.edu.au] on Java 1.0, we were taught operating systems on emulated Minix [minix3.org]. It was fine then, no reason x86 won't be fine now.

Just give this project time. Everybody is queuing up to knock it down, but it should be fine. They're not planning to put Vista on it, just emulate some DOS data entry applications.

What is the point?

Sorry, but I don't get the point.

Viruses also need OS system calls to do the job. Unless there's also a full Windows emulation in Java (including the Windows bugs and vulnerabilities viruses depend on), how could this be used to analyze how viruses are working? And even if it was the case, what would be the point over QEmu?

If you need to understand what some piece of code is doing, there are tools called debuggers.

Wait for the lawsuits...

How much of the x86 instruction set has patents attached to it?

You probably wouldn't see the likes of Intel suing x86 emulators running on x86 (e.g. virtual machines), but it might be a different story if people start using x86 emulators on other CPU architectures through a Java VM because that cuts into their business.

Not fully functional

It doesn't seem to emulate everything well. I tried running the "Debug" command and it froze up when trying to executing INT 21 (a common DOS interrupt): > Debug -A MOV AH, 2A INT 21 JMP 100 -R -T (crashes at this point) this interrupt basically gets the system time, so there's no reason for it to freeze up like that.

Slow

Slow by definition. I wonder if you can use JIT techniques with java at all, but in the end, it still would have to be converted to native code.

Also, for something that's is apparently non-FOSS, they seem to be using both the BOCHS BIOS and the VGA ROM BIOS.... Now the VGA code is AFAIK LGPLd, so they should be okay unless they modified it (a possibility) but I'm pretty sure they had to modify the stock Bochs BIOS, unless they emulated Bochs. In either case, the Bochs BIOS is GPLd.

Run using your own floppy/hd images...

I was able to run it manually, outside of the applet framework, by doing the following:

(1) Download jar from "http://www.physics.ox.ac.uk/jpc/JPCAppletObfs.jar "

(2) Execute using the following java command line:

> java -classpath JPCAppletObfs.jar org.jpc.j2se.PCMonitor

Also the jar archive contains the floppy and HD images, so you can replace them with your own:

> unzip -l JPCAppletObfs.jar
. . .
        38400 03-16-07 16:07 vgabios.bin
        65536 03-16-07 16:07 bios.bin
  10485760 03-16-07 16:07 dosgames.img
    1474560 03-16-07 16:07 floppy.img
. . .
  13756027 285 files

I tried replacing the floppy.img with a freesco.org linux image, but it failed to boot complaining about missing instructions. I'm guessing it only does the 8086 ISA.

Cool thing.

Ok i now need a faster processor, but this is definitely cool. Why? Because it means that, as long as there is Hardware executing Java around, Dos programs can be used. Could make the transition and archiving of existing data easier.

Won't accept all keystrokes

Renders my entering : as a > character (German system). Any other way to change to the c: volume?

The next step

The next step will be for Microsoft to embrace-extend-exterminate the design for .NET, then use it to run legacy applications on a new OS that locks out native code and unsigned code.

(This is cynicism - I'm not being too serious.)

Quite interesting

Because this means non-X86 systems can finally run X86 code. Even if it is slow, it is better than not running X86 code at all. I assume it is a virtual X86 CPU in much the same way that MAME and MESS emulate CPUs via software.

I understand that until they are able to fully emulate certain hardware than this could be limited to just DOS programs. I think they at least out to be able to emulate a S3 Virge video card, Sound Blaster 16, Intel Chipset network card, and maybe serial ports with a Hayes compatible modem in order to run some older Windows operating systems in it using a virtual hard drive. Yet until they can at least do some of the GeForce or ATI Radeon virtual graphics cards, it will be hard to do XP and Vista and modern video games.

Just like the old Mac OS (Pre OSX) emulated a 680X0 CPU in software it took a while before PowerMac hardware caught up to allow the 680X0 emulation to be at a decent speed. A pity the same cannot be done to Intel Macs to emulate PowerPC and 680X0 cpus in software because of the big-endian little-endian differences. Although ARDI tried the 680X0 software CPU emulation in Executor they found that trying to do the same for a PowerPC CPU emulation was not as fast.

Still a Java based X86 emulator opens up a lot of possibilities, due to the fact that Java uses a sandbox and if the Java X86 virtual machine gets infected, chances are the host OS won't get infected even if it is a X86 system itself. It could be a good way to study viruses, without risking the host machine.

Is Java slow?

All you people saying how Java is slow may find it pretty amusing that this emulator in fact runs faster than DOSBOX on my G4 Mac Mini. Haven't tried it on a PC yet, though.

This is...

in theory something that could revolutionise WebOSes. Instead of using a fixed OS system, users could install whatever OS they want, customise it to their heart's content, and be able to access it anywhere.

This really shows that FLASH is slow...

You know something is seriously wrong with Flash when an X86 emulator running within Java outperforms Flash.

Licence - Lemmings etc.

I am also working on a licence that allows me to distribute commecial video games for fee. Do we really think that Sony considers Lemmings abandonware? - cool work though.

It could be useful . . .

I see this as being useful under one condition only. When you ABSOLUTLY MUST have x86 emulation on a non-x86 platform for whatever reason. Like sparc or power. Much cheaper than those drop-in cards sun sells that let you run windows. (At least I assume it will be) Probably a lot slower though.

Typical Oxford NIH?

"the developers are said to be working on a suitable general license"

So as usual, if it hasn't been fiddled with by Oxonians, it doesn't exist yet... but then they write their own dictionary too, you know.

Java is like XML...

... which is like violence; If it doesn't solve the problem, use more.

Re:Struggling to understand...

It is interesting from the standpoint that the emulator itself *should* be fully portable to any platform that runs java. It's probably not useful commercially but from a geek standpoint it could be cool.

Re:Comparisons to other emulators?

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.

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

Since when did emulators become news on slashdot? Its still buggy too. No mouse support (makes playing Lemmings a pain), graphic corruption in some places in Lemmings, arrow keys get effed up when playing Prince of Persia, no sound support, and, well, its kinda slow. Some lagging in Prince of Persia, and I am on a p4. Now, did the original post say that they wanted to use this to test viruses? Please tell me they are not planning on installing windows on this thing.

Although I would smile if they installed Windows 3.1 and the thing dropped into dosshell when you exited. Of course many licensing things there. I guess there is no licensing issues showing off a product you are trying to license with shareware titles, is there?

Re:On a phone?

They claim 10% native speed, which is somewhat fast in terms of emulation.

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

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).

Re:Struggling to understand...

Because it's new!

Why Java ?

I do understand the reasons they chose the language

I don't. What does Java has to offer that some standard C emulator doesn't ?
Some of the current emulators provides special hooks so the emulated code can ask the emulator to perform some task for acceleration (like some emulators provide special graphic and network drivers for the emulated Windows).
But if you cut them, there are no differences between the emulator and a real machine from the virus' point of view.

If the emulator is well done enough there won't be any exploit that the virus could use to make the emulators's host run arbitrary code.
Or are they using Java just because they want not to need to do extra efforts to be sure the virus won't easily escalate out of the emulator ?

Re:lame description

Cool stuff Joris! And the source is there too!