Thanks for ruining the game by being too much of a pussy TO JUST FUCKING PLAY IT.
Cheating and the game itself were separated. Although I ran around the game like a goddess, my own play character wasn't cheated. I had a character image on my hard drive that I would play with when I wanted to play the game as opposed to cheat in it.
The cheating was a game in itself, to me. I actually found it more fun than the game itself. I didn't like ruining the game for other people.
As for item duping, I can't be completely blamed for that. There's actually a bug in the game's UI windowing system that allowed you to dupe items without any cheat programs or hardware at all.
you admit to being one of the people that fucked it up for everyone else?
Yep, although the damage I did to the game was mostly indirect. I did far more damage by giving out our cheat codes than in anything I did myself.
However, when some cheats went too far, like with the hack to break into password-locked games, I emailed Sega with information on how to fix it. Sega Europe had some people who spoke Japanese and were willing to translate my emails for them. That hack was one of my regrets - I was the one who made it.
Congratulations. You're a fucking douchebag. I hope you get cancer and die.
That's nice. Statistically speaking, your wish probably will be granted, but not likely for a few decades.
I was actually one of the most well-known cheaters in PSO. A few friends and I disassembled the game and figured out how various parts worked, making GameShark cheat codes in the process. I had a serial cable between my PC and Dreamcast that let me dump memory and target-debug PSO.
My favorite trick that I would do with the debugger is overwrite my own character with the data from another character in the lobby, then rejoin the lobby. I would appear as an exact clone of them. I even would do things like start listing the items they had in their inventory, as that was broadcast to every other client. Until Sega's servers started detecting it, I would also run around the lobby as Sonic.
When the GameCube version came out, we applied our knowledge from the Dreamcast version to break the new encryption it used on the protocol. We didn't have a way to remote-debug the GameCube, so instead we wrote a transparent proxy server that let us mess with the packet stream instead.
PSO for Xbox is what led to GameCube homebrew, and eventually sped up GameCube piracy. In the Dreamcast days, because of our cheating and bugs, Sega added a packet in "version 2" known as RcvProgramPatch that would tell the client to execute arbitrary SH4 assembly code. The GameCube version had this feature too. Because the GameCube packet encryption was then unknown (to homebrew; we knew it) and the disks were unreadable, there was no obvious way to break it without disassembling the game. The same encryption algorithm was used in the Xbox version of the game - big mistake. Xbox disks were readily dumped, and by disassembling the Xbox version's encryption they got the GameCube version's encryption. From there they simply sent PowerPC assembly code to the GameCube via RcvProgramPatch and it was all over.
We actually cracked the encryption before the Xbox version came out using an elaborate trick involving misuse of stream ciphers by Sega. They violated two rules of stream ciphers and cryptography in general: always have both the server and client provide pieces that hash to the session key, and never let the server session key equal the client session key. This led us to get about 1 MB of the encryption stream for a particular key that we could repeatedly use. From there, we tried RcvProgramPatch, but it was broken. (We later figured out that it didn't flush the instruction cache before executing code. We later worked around that, as did the homebrewers.) Instead, we took advantage of another feature of RcvProgramPatch: the ability to request a CRC32 of an arbitrary chunk of memory. We asked for the CRC32 of every 2-byte word of memory, and from that we were able to get a copy of the game's RAM, and thus the assembly code containing the encryption. It was just disassembly from there to get to the algorithm.
I spent waaaay too much time in that game, to the point that I've heard its lobby music far more than any other song in my life. Maybe someday I'll write the story of PSO hacking.
Even more important: unlike trannies (no offense intended to any TG folk reading this), we intersexed people do not choose to be in the situation we are in.
I have persistent thoughts of hoping I die because I feel very strongly that I need to be a woman. I shy away from mirrors in self-disgust. I have to avoid seeing women in general or I will start to get jealous of them. I hate my life.
Galaxies are almost entirely empty space. Even when Milky Way and Andromeda collide, it will for the most part be a peaceful merger. Most likely, we'd have more stars in the sky, but that's about it. Some stars or systems will collide, but for an individual star the probability is remote.
In 3 billion years, I'm more worried about the Sun becoming a red giant and eating Earth. But there probably won't be life on Earth then.
The current theory is that a Mars-sized planet collided with Earth sometime in history. When this planet, usually named Theia, collided with Earth, some of the disturbed matter from both planets got ejected into space, some fell onto and became part of Earth, and some got caught in orbit around Earth as natural satellites.
The resulting dust either escaped or eventually coalesced into the modern Earth and Moon.
It wasn't meant to be found - it's actually a bug in the game. It's related to a space optimization used in the programming: rather than having a special type of Warp Zone for 4-2's warp to world 5, which unlike the other warps had only one pipe, they did a trick to make the world 5 warp still be a three-pipe warp zone. The trick they did was give the left and right pipes, which don't exist in the map data part, world targets of 36. 36 is the number of the blank display tile, which hides the number for you.
The bug essentially just causes the 36/5/36 Warp Zone data to be used in 1-2. Taking the left or right pipe causes the game to send you to world 36-1. As mentioned above, 36 is the tile index for blank, so you end up in " -1", giving rise to the name "Minus World".
The world number 36 overflows the index into the world table. In the cartridge version, it ends up mapping world 36 to the water area used by 2-2 and 7-2. Because 36 is greater than 4, it spawns the extra enemies used in 7-2's version of the level.
The world repeats forever because of how the "set pipe target" command in the object data works. The object data script says, "if world number is X, the next usable pipe sends the player to level Y". The object data only has such commands for worlds 2 and 7 of course, so nothing happens in 36-1. The particular RAM variable set by the command starts off a level set to the ID of that level. Thus when entering a pipe without such a command setting the variable, it reloads the same level.
The Famicom Disk System version of the game acts differently because the data past the end of the world table is different. It ends up loading a different level as a result. That sequence is a series of glitched levels that eventually lead to "beating the game".
Japan had both an FDS and cartridge version of SMB. The cartridge version is bitwise identical to the American version, thus containing our Minus World. In fact, early American versions of the game have the Japanese version inside along with a pinout adapter.
As is somewhat well-known, Microsoft's license agreement says only the Ultimate, Business and possibly Home Premium editions are permitted to be run under a virtual machine. In Vista, they didn't enforce this technologically.
This might change in Windows 7. I found some assembly code in the Windows 7 beta kernel that was detecting whether it was running under a virtual machine. This code was in functions clearly related to license management. The beta version was Ultimate, so I don't think anyone noticed that VMs don't work...
Portal had what I felt was an interesting way of telling the story. The "narrator" was mostly there to explain the rather quirky gameplay. Only in the later levels did she become part of the story.
Much of Portal's story is in objects you find in optional areas of the game world - secret rooms you find behind walls. You only see the objects in the 3D world and have to read them yourself to understand their storywise meaning; nothing with them is directly narrated.
In the end, your knowledge of the story is entirely inferred from vague clues and events you find throughout the game.
Although it's generally true that what I initially think is a compiler bug is almost always my fault, I definitely run into actual compiler or library bugs on occasion.
- I was working on some low-level boot loader assembly code, and found that "call esp" was not working as documented. It turns out that most modern Intel CPUs have a bug they haven't bothered fixing where it jumps to the value of ESP *after* pushing the return address. AMD processors don't do that, which is why it worked for me >_<
- I found that a memcpy() in our Win32 "vectored exception handler" was corrupting memory. The code that caused the exception was a memmove() that had decided to go in reverse to ensure a proper copy. It turns out that Win32's exception handler stub wasn't clearing the x86 direction flag before calling exception handlers, a violation of the Win32 calling convention. Compilers assume that the direction flag is clear at the start of a function, so a constant-sized memcpy() will frequently get inlined as simply "rep movsd".
- We found an extremely obscure bug in Visual C++'s compiler where it incorrectly zero-extended a pointer to 64 bits when it should have sign-extended as per the C standard. A global declaration like this was being used:
int var; long long extended = (long long) &var;
If the base address of a 32-bit program is >= 0x80000000, as occurs in NT device drivers, the extension to 64-bit will be zero-extended instead of sign-extended. This differs from what happens in local variables.
In fact, getting this right is impossible with the relocations available to Win32 images and object files. The compiler should've thrown an error because it can't do the requested operation. (In C++ it could, but would have to make it a constructor.)
This further raises the question, why the hell does windows have ReadProcessMemory, and WriteProcessMemory system calls that don't require admin rights?
Linux has ptrace() and/proc to do the same things. Mac OS has ptrace() and vm_write().
The reason they exist is to allow the creation of debuggers. A debugger must be able to modify the state of a target process in order to be useful.
Should we require users be Administrator in order to run a debugger, even on their own programs? That's the fundamental question. If we do allow it, malware can inject into other processes. If we don't, we may be severely restricting computer use, particular in situations where "shell accounts" are provided to unprivileged users for software development on UNIX systems.
One approach is to limit the debugging API to specific debugger programs. This done by Linux using SELinux, and by Mac OS requiring debuggers to be setgid "procmod". This isn't secure because the most popular debugger for these systems - gdb - is a terminal program. Malware can just spawn a gdb process and type commands to it as if it were the user.
You'd really need something like UAC to require confirmation to run a debugger. But how would you bring up a UAC dialog to a user logging in through SSH?
Before Vista came out, during its beta phase, I already thought of a way to get around UAC using a form of social engineering. First, two background facts:
1. When you run a signed program as Administrator, the UAC dialog box you get is colored differently, such that it looks more legitimate.
2. Explorer runs as an unprivileged account, and as such can be injected into (same as TFA).
The idea is rather simple. Have your malware inject into Explorer and wait. When the user finally does something that requires elevation, intercept the request.
Instead of running the application the user intended, elevate a Microsoft program that can easily be told to run another program; simple examples are cmd.exe and rundll32.exe. The UAC dialog box will come up, as the user expected. The program name will say "Windows Command Processor" instead of whatever Control Panel feature the user was actually trying to use.
But how many non-expert users know the difference? They were expecting to have to elevate and will click Yes. "Windows Command Processor" sounds legitimate enough.
After your malware takes control, run the original program the user wanted to run, keeping the illusion that everything is normal.
By the way, Administrator access is overrated. You can be a botnet node, steal bank account passwords, and still WoW passwords all without needing to ever access the Administrator account in Windows. Those passwords are the items of real value now, and they're in unprivileged processes within the reach of unprivileged malware.
I heard that much of the technique behind the design is to create x86 segments with a limit such that the sandboxed program can only access certain areas of memory within the process space. If this is true, the technique won't work at all in 64-bit Windows: Win64 doesn't have an API, documented or otherwise, to create segments in the LDT, unlike Win32. In fact, XP 64 and Vista 64 hardcode the LDT register to null. (Windows 7 64 has a limited LDT that appears to be related to SQL Server's "User-Mode Scheduler".)
Does anyone know whether I'm correct about Google's project?
Does hardware Data Execution Prevention stop it from happening, in that this exploit would crash Reader instead of cause an exploit if DEP is enabled? I wish companies would suggest that as a possible mitigation, even if not all computers support it.
I did dumpbin/headers and saw that the EXE header for AcroRd32.exe has the "NX compatible" bit set. This means that DEP will be automatically enabled for Reader on Vista.
However, that doesn't cover XP. XP 32 SP3 has an API call named SetProcessDEPPolicy to request enabling DEP for your process. Adobe should modify Reader to call this function if it exists. (It exists on Vista SP1 as well, but Vista SP1 will already enable it due to/NXCOMPAT.)
XP 32 SP2 and XP 64 SP2, even though they have DEP, don't have a way to enable it if the system-wide DEP setting is "opt in" - the default. And there's no way to opt in that these support. (Google Chrome has code to use an undocumented system call to enable it, but it actually has no effect.)
When, ahem, poking around in the Windows 7 kernel (ntoskrnl.exe), I found something interesting and new to Windows 7: it detects virtual machines. If it finds a virtual machine, it will check the Windows licensing data to see whether your edition of Windows is allowed to run as a VM. It seems like they're putting in enforcement of the EULA rules that were in Vista, but I have no way to test this, since the beta is the Ultimate edition.
The VM detection code itself is rather straightforward: it checks how long it takes to do an opcode that should be very quick ("mov rax, cr3"). Under a hardware VM, this would trap to the hypervisor, causing a delay. The code validates that "rdtsc" time is not elapsing excessively, which would indicate a hypervisor.
If you're making a hardware-assisted hypervisor, you should make use of the virtualization features of the CPU to apply an offset to rdtsc so that the traps to the hypervisor don't get detected this way. AMD processors support this; no idea about Intel.
There is another feature that auto-elevates that can and will be used.
When you use Explorer to drag and drop files into a directory you don't have write access to, Explorer will ask whether you'd like to use your Administrator permissions to complete the task. If you say yes, it will launch a program as Administrator that does the actual copy.
The problem is, this program in Windows 7 is one of the special ones that self-elevates without the UAC dialog box. Because Explorer doesn't run with Administrator privileges, and because the confirmation dialog box is within Explorer, a malicious program can use the file copy program to do any file operation with Administrator privileges, and it will happen without any user input in the default installation.
Slashdot Mirror
Cheating and the game itself were separated. Although I ran around the game like a goddess, my own play character wasn't cheated. I had a character image on my hard drive that I would play with when I wanted to play the game as opposed to cheat in it.
The cheating was a game in itself, to me. I actually found it more fun than the game itself. I didn't like ruining the game for other people.
As for item duping, I can't be completely blamed for that. There's actually a bug in the game's UI windowing system that allowed you to dupe items without any cheat programs or hardware at all.
Yep, although the damage I did to the game was mostly indirect. I did far more damage by giving out our cheat codes than in anything I did myself.
However, when some cheats went too far, like with the hack to break into password-locked games, I emailed Sega with information on how to fix it. Sega Europe had some people who spoke Japanese and were willing to translate my emails for them. That hack was one of my regrets - I was the one who made it.
That's nice. Statistically speaking, your wish probably will be granted, but not likely for a few decades.
I was actually one of the most well-known cheaters in PSO. A few friends and I disassembled the game and figured out how various parts worked, making GameShark cheat codes in the process. I had a serial cable between my PC and Dreamcast that let me dump memory and target-debug PSO.
My favorite trick that I would do with the debugger is overwrite my own character with the data from another character in the lobby, then rejoin the lobby. I would appear as an exact clone of them. I even would do things like start listing the items they had in their inventory, as that was broadcast to every other client. Until Sega's servers started detecting it, I would also run around the lobby as Sonic.
When the GameCube version came out, we applied our knowledge from the Dreamcast version to break the new encryption it used on the protocol. We didn't have a way to remote-debug the GameCube, so instead we wrote a transparent proxy server that let us mess with the packet stream instead.
PSO for Xbox is what led to GameCube homebrew, and eventually sped up GameCube piracy. In the Dreamcast days, because of our cheating and bugs, Sega added a packet in "version 2" known as RcvProgramPatch that would tell the client to execute arbitrary SH4 assembly code. The GameCube version had this feature too. Because the GameCube packet encryption was then unknown (to homebrew; we knew it) and the disks were unreadable, there was no obvious way to break it without disassembling the game. The same encryption algorithm was used in the Xbox version of the game - big mistake. Xbox disks were readily dumped, and by disassembling the Xbox version's encryption they got the GameCube version's encryption. From there they simply sent PowerPC assembly code to the GameCube via RcvProgramPatch and it was all over.
We actually cracked the encryption before the Xbox version came out using an elaborate trick involving misuse of stream ciphers by Sega. They violated two rules of stream ciphers and cryptography in general: always have both the server and client provide pieces that hash to the session key, and never let the server session key equal the client session key. This led us to get about 1 MB of the encryption stream for a particular key that we could repeatedly use. From there, we tried RcvProgramPatch, but it was broken. (We later figured out that it didn't flush the instruction cache before executing code. We later worked around that, as did the homebrewers.) Instead, we took advantage of another feature of RcvProgramPatch: the ability to request a CRC32 of an arbitrary chunk of memory. We asked for the CRC32 of every 2-byte word of memory, and from that we were able to get a copy of the game's RAM, and thus the assembly code containing the encryption. It was just disassembly from there to get to the algorithm.
I spent waaaay too much time in that game, to the point that I've heard its lobby music far more than any other song in my life. Maybe someday I'll write the story of PSO hacking.
Why do I have the sudden urge to play Arkanoid?
I have persistent thoughts of hoping I die because I feel very strongly that I need to be a woman. I shy away from mirrors in self-disgust. I have to avoid seeing women in general or I will start to get jealous of them. I hate my life.
Why would i choose this?
And I thought that I passed enough gas already from eating McDonald's.
Galaxies are almost entirely empty space. Even when Milky Way and Andromeda collide, it will for the most part be a peaceful merger. Most likely, we'd have more stars in the sky, but that's about it. Some stars or systems will collide, but for an individual star the probability is remote.
In 3 billion years, I'm more worried about the Sun becoming a red giant and eating Earth. But there probably won't be life on Earth then.
The current theory is that a Mars-sized planet collided with Earth sometime in history. When this planet, usually named Theia, collided with Earth, some of the disturbed matter from both planets got ejected into space, some fell onto and became part of Earth, and some got caught in orbit around Earth as natural satellites.
The resulting dust either escaped or eventually coalesced into the modern Earth and Moon.
It wasn't meant to be found - it's actually a bug in the game. It's related to a space optimization used in the programming: rather than having a special type of Warp Zone for 4-2's warp to world 5, which unlike the other warps had only one pipe, they did a trick to make the world 5 warp still be a three-pipe warp zone. The trick they did was give the left and right pipes, which don't exist in the map data part, world targets of 36. 36 is the number of the blank display tile, which hides the number for you.
The bug essentially just causes the 36/5/36 Warp Zone data to be used in 1-2. Taking the left or right pipe causes the game to send you to world 36-1. As mentioned above, 36 is the tile index for blank, so you end up in " -1", giving rise to the name "Minus World".
The world number 36 overflows the index into the world table. In the cartridge version, it ends up mapping world 36 to the water area used by 2-2 and 7-2. Because 36 is greater than 4, it spawns the extra enemies used in 7-2's version of the level.
The world repeats forever because of how the "set pipe target" command in the object data works. The object data script says, "if world number is X, the next usable pipe sends the player to level Y". The object data only has such commands for worlds 2 and 7 of course, so nothing happens in 36-1. The particular RAM variable set by the command starts off a level set to the ID of that level. Thus when entering a pipe without such a command setting the variable, it reloads the same level.
The Famicom Disk System version of the game acts differently because the data past the end of the world table is different. It ends up loading a different level as a result. That sequence is a series of glitched levels that eventually lead to "beating the game".
Japan had both an FDS and cartridge version of SMB. The cartridge version is bitwise identical to the American version, thus containing our Minus World. In fact, early American versions of the game have the Japanese version inside along with a pinout adapter.
Four you.
As is somewhat well-known, Microsoft's license agreement says only the Ultimate, Business and possibly Home Premium editions are permitted to be run under a virtual machine. In Vista, they didn't enforce this technologically.
This might change in Windows 7. I found some assembly code in the Windows 7 beta kernel that was detecting whether it was running under a virtual machine. This code was in functions clearly related to license management. The beta version was Ultimate, so I don't think anyone noticed that VMs don't work...
Portal had what I felt was an interesting way of telling the story. The "narrator" was mostly there to explain the rather quirky gameplay. Only in the later levels did she become part of the story.
Much of Portal's story is in objects you find in optional areas of the game world - secret rooms you find behind walls. You only see the objects in the 3D world and have to read them yourself to understand their storywise meaning; nothing with them is directly narrated.
In the end, your knowledge of the story is entirely inferred from vague clues and events you find throughout the game.
Although it's generally true that what I initially think is a compiler bug is almost always my fault, I definitely run into actual compiler or library bugs on occasion.
- I was working on some low-level boot loader assembly code, and found that "call esp" was not working as documented. It turns out that most modern Intel CPUs have a bug they haven't bothered fixing where it jumps to the value of ESP *after* pushing the return address. AMD processors don't do that, which is why it worked for me >_<
- I found that a memcpy() in our Win32 "vectored exception handler" was corrupting memory. The code that caused the exception was a memmove() that had decided to go in reverse to ensure a proper copy. It turns out that Win32's exception handler stub wasn't clearing the x86 direction flag before calling exception handlers, a violation of the Win32 calling convention. Compilers assume that the direction flag is clear at the start of a function, so a constant-sized memcpy() will frequently get inlined as simply "rep movsd".
- We found an extremely obscure bug in Visual C++'s compiler where it incorrectly zero-extended a pointer to 64 bits when it should have sign-extended as per the C standard. A global declaration like this was being used:
int var;
long long extended = (long long) &var;
If the base address of a 32-bit program is >= 0x80000000, as occurs in NT device drivers, the extension to 64-bit will be zero-extended instead of sign-extended. This differs from what happens in local variables.
In fact, getting this right is impossible with the relocations available to Win32 images and object files. The compiler should've thrown an error because it can't do the requested operation. (In C++ it could, but would have to make it a constructor.)
I call bullshit.
Can those of us with "Karma: Excellent" get a "Karma Whore" achievement?
Just whoring out for points =)
The fields to enter in your WoW character are rather buggy. I had to try a bunch of times in order to get it to recognize my WoW character.
Also, my original Slashdot account was 5 digits; I changed it for personal reasons several years ago but now I don't get that achievement.
Oh well - at least I now have the April Fools post achievement... >_<
I don't have Perl installed on this Windows machine. What does your signature do? (Assuming "eval" is replaced with "print")
This further raises the question, why the hell does windows have ReadProcessMemory, and WriteProcessMemory system calls that don't require admin rights?
Linux has ptrace() and /proc to do the same things. Mac OS has ptrace() and vm_write().
The reason they exist is to allow the creation of debuggers. A debugger must be able to modify the state of a target process in order to be useful.
Should we require users be Administrator in order to run a debugger, even on their own programs? That's the fundamental question. If we do allow it, malware can inject into other processes. If we don't, we may be severely restricting computer use, particular in situations where "shell accounts" are provided to unprivileged users for software development on UNIX systems.
One approach is to limit the debugging API to specific debugger programs. This done by Linux using SELinux, and by Mac OS requiring debuggers to be setgid "procmod". This isn't secure because the most popular debugger for these systems - gdb - is a terminal program. Malware can just spawn a gdb process and type commands to it as if it were the user.
You'd really need something like UAC to require confirmation to run a debugger. But how would you bring up a UAC dialog to a user logging in through SSH?
Before Vista came out, during its beta phase, I already thought of a way to get around UAC using a form of social engineering. First, two background facts:
1. When you run a signed program as Administrator, the UAC dialog box you get is colored differently, such that it looks more legitimate.
2. Explorer runs as an unprivileged account, and as such can be injected into (same as TFA).
The idea is rather simple. Have your malware inject into Explorer and wait. When the user finally does something that requires elevation, intercept the request.
Instead of running the application the user intended, elevate a Microsoft program that can easily be told to run another program; simple examples are cmd.exe and rundll32.exe. The UAC dialog box will come up, as the user expected. The program name will say "Windows Command Processor" instead of whatever Control Panel feature the user was actually trying to use.
But how many non-expert users know the difference? They were expecting to have to elevate and will click Yes. "Windows Command Processor" sounds legitimate enough.
After your malware takes control, run the original program the user wanted to run, keeping the illusion that everything is normal.
By the way, Administrator access is overrated. You can be a botnet node, steal bank account passwords, and still WoW passwords all without needing to ever access the Administrator account in Windows. Those passwords are the items of real value now, and they're in unprivileged processes within the reach of unprivileged malware.
I heard that much of the technique behind the design is to create x86 segments with a limit such that the sandboxed program can only access certain areas of memory within the process space. If this is true, the technique won't work at all in 64-bit Windows: Win64 doesn't have an API, documented or otherwise, to create segments in the LDT, unlike Win32. In fact, XP 64 and Vista 64 hardcode the LDT register to null. (Windows 7 64 has a limited LDT that appears to be related to SQL Server's "User-Mode Scheduler".)
Does anyone know whether I'm correct about Google's project?
Does hardware Data Execution Prevention stop it from happening, in that this exploit would crash Reader instead of cause an exploit if DEP is enabled? I wish companies would suggest that as a possible mitigation, even if not all computers support it.
I did dumpbin /headers and saw that the EXE header for AcroRd32.exe has the "NX compatible" bit set. This means that DEP will be automatically enabled for Reader on Vista.
However, that doesn't cover XP. XP 32 SP3 has an API call named SetProcessDEPPolicy to request enabling DEP for your process. Adobe should modify Reader to call this function if it exists. (It exists on Vista SP1 as well, but Vista SP1 will already enable it due to /NXCOMPAT.)
XP 32 SP2 and XP 64 SP2, even though they have DEP, don't have a way to enable it if the system-wide DEP setting is "opt in" - the default. And there's no way to opt in that these support. (Google Chrome has code to use an undocumented system call to enable it, but it actually has no effect.)
When, ahem, poking around in the Windows 7 kernel (ntoskrnl.exe), I found something interesting and new to Windows 7: it detects virtual machines. If it finds a virtual machine, it will check the Windows licensing data to see whether your edition of Windows is allowed to run as a VM. It seems like they're putting in enforcement of the EULA rules that were in Vista, but I have no way to test this, since the beta is the Ultimate edition.
The VM detection code itself is rather straightforward: it checks how long it takes to do an opcode that should be very quick ("mov rax, cr3"). Under a hardware VM, this would trap to the hypervisor, causing a delay. The code validates that "rdtsc" time is not elapsing excessively, which would indicate a hypervisor.
If you're making a hardware-assisted hypervisor, you should make use of the virtualization features of the CPU to apply an offset to rdtsc so that the traps to the hypervisor don't get detected this way. AMD processors support this; no idea about Intel.
There is another feature that auto-elevates that can and will be used.
When you use Explorer to drag and drop files into a directory you don't have write access to, Explorer will ask whether you'd like to use your Administrator permissions to complete the task. If you say yes, it will launch a program as Administrator that does the actual copy.
The problem is, this program in Windows 7 is one of the special ones that self-elevates without the UAC dialog box. Because Explorer doesn't run with Administrator privileges, and because the confirmation dialog box is within Explorer, a malicious program can use the file copy program to do any file operation with Administrator privileges, and it will happen without any user input in the default installation.
Surely that will be abused...
I think you're most likely correct, but what makes you state this so directly? Is there something online about him?
...if even EA thought that it would not meet their quality standards. That's hard to do.