HEY /PROG/ GO FUCK YOURSELVES

You heard me,

Go fuck yourself, the world doesn't you or your bs "HACKERS ON STEROIDS" Programing, You and your shit are nothing to what a real PROGRAMMER will know.

Fucking say to every person, go read "xxx" where "xxx" is when you insert some absurd insult.

Or how about you thinking you're so mighty hackers on steroids b ut can't even use correct Grammar or English skills!

So, final advice: GO FUCK YOURSELF.

>>28
He's probably disabling the exception handler (win32 specific) and then causing a divide by zero exception. The first instruction should enable protected mode (if not already enabled) and disable a lot of other features (it will set cr0 to 1). If this is ran in ring0 (protected mode), it will cause interrupt 0 to be called, which (assuming win32, given that he makes use of fs:[0]) will try to call the exception handler which doesn't exist, so it will likely result in a bugcheck (BSOD). If ran in ring3 (protected mode), the first instruction should cause an exception in itself since it's a priviledged instruction (the exception being caused by the ring0 trap code being called which then calls the generic exception handler in ring0, which then thunks back to the one in ring3 - KiUserExceptionDispatcher, which then calls VEH and SEH handlers as documented). Oh, also and cr0,1 is not really a valid x86 instruction by itself, however it's easily accomplished by simpler x86 instructions, like:

0F20C0          MOV EAX,CR0
83E0 01         AND EAX,1
0F22C0          MOV CR0,EAX