80x86 ASM for ASP.NET

Galen Wolffit writes "A chap out in Denmark has brought us an 80386 Assembler for ASP.NET. This interpreter supports about 61 80x86 instructions, though there are a number of limitations. Why? Why not. And when asked about pointers (which are considered evil in .NET), the author simply says 'With 80386 scripting you can still generate memory exceptions and bring the web-server down. It's things like this that make assembler programmers feel powerful.'"

power?

[arnorhs]

asm programmers fell powerful whenever they get to write anything... which happens very seldom :/

Overhead?

[exebeoex]

I wonder what kind of overhead this incurs. Afterall, for a number of reasons it would only be as fast as an x86 emulator, no? Not to mention trying to convert register based instructions for use on a stack based machine. But maybe this sort of register->stack translation scheme used can be useful for those working on making a backend to the GCC RTL (register transfer language) for the .NET runtime. Could it?

Re:Overhead?

[yamla]

This would only be true if you were not running inside of the .NET CLR.

Re:Overhead?

[GigsVT]

It's right on the page.

Speed?
Converting a language like 80386 assember to another low-level instruction set is, as you can imagine, not a healthy thing for code performance. In other words, the performance suck big time.

Fun... Perhaps

[foooo]

Fun... Perhaps...

Useful? Probably not.

I don't personaly find writing Asm to be the quickest way to code something and the benefit of superfast execution speed is lost when converting to IL.

If you're going to actually write Assembler... do it the way it's meant to be done. Not in .NET... leave .NET to the high(er) level developers it's aimed at.

~foooo

Lies!

[Tuxinatorium]

There is no such thing as x86 architecture! It is a silicon fabrication of the Intel Infidels!

--(former) Iraqi Information Minister, Mohammed Saeed Al-Sahaf

Question

[m0rph3us0]

Some of you that know more about exploits may be able to point me in the right direction. Would you be able to use this to exploit .NET ie. create exploitable app in 80386script and then have a browser load the exploitable app? or would we have to find a general exploit to the .NET VM to gain access to the system? I'm assuming unsigned .NET code for IE runs in some sort of security mode like java does.

Re:Question

[AssFace]

huh? why would this allow exploits any more easily than any of the other languages in .NET?

Re:Question

[anarxia]

In this case x86 assembly does not give you the power it traditionally does, since the compiled code will bare little resemblance to the code you write. The way to get the most power on the generated code would be to write in IL directly (you might as well write an IL assembler while you are at it).

Re:Question

[pchasco]

I dont think so. If the assembly code is running on the web server, then it isn't running on the browser. Besides, even assembly code isn't executably by a computer. It still needs to be compiled with an assembler. That being said, if the exploit were possible then they wouldn't even need 80386script to exploit the browser. They could just send it some C#.

MenuetOS

[e8johan]

Does this mean that we can run MenuetOS on .Net? (MenuetOS is 100% x86 asm)...

Re:MenuetOS

[anarxia]

From the specs on the website only a small subset of the x86 asm is supported, so I seriously doubt it.

More Virii! Yay!

[screwthemoderators]

Now script kiddies can recycle those old virii that anti-virus software now defeats. Woot! I knew Dot-NET would present new opportunities for '1ee7 exploits!

This stuff has no effect on the web browser

[pchasco]

For all those paranoid, you can rest easy. The assembly code still runs on the web server, and not your browser. No different than C# or VB.NET code in that respect. If the web server could force your browser to compile and execute this assembly code, then it could very well just force you to compile and run some C# or VB.NET code.