Yep. TPM really is a better design than what's in UEFI. The attack surface against UEFI is quite big.
I actually have a third exploit against part of the whole Secure Boot process, this time a Microsoft bug in Windows itself that lets me load unsigned kernel code at boot time with Secure Boot enabled.
This flaw works on all architectures, so I'm saving it for now. I found it trying to find a new jailbreak for Windows RT 8.1.
Finding an exploit to boot Linux on the Surface RT is like gluing a 500cc engine on your kid's bicycle: Pointless. Still, feel free to get it out there through the proper channel. The usual zero-day mailing lists should do fine.
It affects x86 as well, making it usable by malware to make bootkits without signed drivers despite Secure Boot. I have to be careful with releasing this one.
Main reason I won't get one is that when (not if) RT dies; all you have left is a paperweight.
At least with laptops, I can stick Linux on them when their version of windows gets too bogged down with viruses.
It's likely possible to make an Android distro or regular Linux for the Surface RT. I have an exploit I've been holding onto that could be used to boot a Linux kernel at startup, even with RT's Secure Boot active.
The hard party of it is making a Linux distro that works on Surface. Having a Windows background, I wouldn't know the first thing about porting Linux to unfamiliar motherboards.
I'm going to guess that they'll only allow independent developers to use verifiable.NET code in their games. Allowing native code is exceptionally dangerous, because it multiplies the attack surface by several times. It's almost guaranteed that sandboxes running native code will have escape bugs on release day.
In Windows 8.1, Microsoft actually made significant changes just to lock down Windows RT more strongly. They created a new type of "protected process" that protects csrss.exe from debugging, which is exactly how the RT 8.0 jailbreak worked. They clearly spent a lot of engineering resources to do this.
I have a thread post here describing some of the changes in 8.1 that were clearly designed to target RT's jailbreak, for they have little other practical use.
Either Microsoft have done security right for the first time in their very long history of bad security, or it's hackable. I'm guessing the last option is more likely.
Some Linux varient on that hardware might be pretty nice.
I have an exploit that can be used for this purpose that I've been keeping secret. I just need to wait for the right opportunity to come to use it.
I found an exploit in a different part of Windows, but they aren't paying for that. They were only paying for mitigation bypass exploits and IE11 exploits.
I guess I'll stick to my original plan and use it to jailbreak Windows RT 8.1 and possibly Windows Phone 8.
It failed because Redmond was four years too late, and Android and iOS are so dominant at all price points that there is simply no room for a third competitor. Surface RT offers nothing that mid and upper end iDevices and Androids do not.
In other words, Microsoft has been out-Microsofted.
The advantage that Windows on a tablet has over iOS and Android tablets is that it runs Windows applications. They're tablets that act like tablets, but also work as laptops when you want one. iOS and Android are crap for productivity applications.
This is the flaw with Windows RT: Windows with only Metro offers nothing over iOS and Android. The fact that you can leave Metro is what Windows does better than the competition, but instead Microsoft decided that the desktop was something to eliminate. Surface RT and Windows 8 in general failed as a result.
I feel like Microsoft was almost there with Windows 8, but their colossal hubris ruined it.
What is nice about Windows RT compared to iOS and Android is that it is effectively a full Windows 8. You could leave the Metro world when you had a keyboard and mouse, and effectively start using a laptop.
A huge problem was that Microsoft locked down Surface RT's desktop mode such that only they could make desktop RT programs. You could get to the Windows desktop, but all you could do there is copy files and run Office. Had Microsoft allows making desktop RT apps, some commercial developers would have started porting their apps to RT. In most regards, porting to Windows RT desktop mode is just a recompile with a different CPU setting.
There is a jailbreak for Windows RT, and some open-source desktop applications have been ported to it. However, the fact that it's only unlockable with a jailbreak has meant that no commercial developers have ported their software to the RT desktop mode.
Rather than back down from their mistake, they're actually doubling down: Windows 8.1 not just fixes the jailbreak, but has a bunch of kernel architectural changes just to prevent the type of attack used to jailbreak RT 8.0. If you have a desktop machine running x86/x64 Windows 8.1 Preview, try attaching a debugger to lsass.exe. lsass.exe, csrss.exe, and smss.exe are now "Protected Processes" in 8.1. Protected Processes up until 8.1 have only been DRM-related processes, such as audiodg.exe. And yet, Microsoft went to the trouble to make those system processes Protected just because of the Windows RT jailbreak's existence.
They don't even have the common decency to at least choose a password that isn't already in every rainbow table on the planet.
If I were to make a back door system, I'd make sure customers knew about it. I'd make it so that a physical switch had to be activated on the device itself in order for the back door to be used. Activating the switch would be plainly obvious, with both physical indicators on the device and in management software, with auditing and warnings that the back door has been activated - and detailed logging of that account logging in. I'd use a 30-character randomly-generated password at least, if not some kind of public-key system, to authenticate the back door login.
If having to go to the physical device is a pain for you the customer, you can always just leave the switch always activated - you'd still be better off than those badg3r5 at HP.
In addition to a lot of other misfeatures like shoving Microsoft Accounts down your throat, Microsoft actually went out of their way with Windows RT 8.1 to lock out the jailbreak that allows you to run non-Metro applications on Windows RT 8.0. Windows RT is basically just Windows 8 ported to ARM, desktop and all, but Microsoft made Windows RT unable to run any non-Microsoft program in the desktop -- all third-party applications *must* be Metro applications on the Windows Store. I really think that Windows RT is Microsoft's testbed for what they envision as the future of all of Windows, both desktop and tablet.
The jailbreak made Windows RT able to run unsigned applications on the desktop. Some open-source applications have now been ported to the jailbroken Windows RT environment. That's pretty much all the jailbreak allowed you to do -- run some desktop-mode open-source programs on Windows RT. The jailbreak doesn't seem to facilitate Windows Store application piracy at all -- at least, I haven't heard of such hacks.
And yet, Microsoft went well out of their way to block it. They revoked the certificate used to sign all RT 8.0 applications. They changed the debugger policy on RT to not allow WriteProcessMemory. They rewrote considerable portions of the Windows RT-specific lockdown DLL, wldp.dll. They marked csrss.exe as a DRM-related "protected process", even though it has nothing to do with DRM. This latter change applies to x86 as well, even though the change was clearly designed to target the method by which the Windows RT 8.0 jailbreak worked.
I'm working on a new jailbreak for RT 8.1. I already have code executing in kernel mode in RT 8.1, so it's just a matter of putting everything together. I'm going to wait until the 8.1 final release before releasing the jailbreak, though, to make things more complicated for Microsoft to fix.
With Windows RT 8.1, Microsoft actually took measures to lock out the jailbreak that allowed running unsigned--and Desktop-based--code on Windows RT. I think that this more than anything shows what you're talking about: Microsoft severely cares that you're using their device designed to showcase Metro to run desktop applications.
By the way, we already have good progress on jailbreaking RT 8.1.
Could this be used by lesbian couples in the future to have babies that are biological children of both parents? Obviously, such children would always be daughters, but I'm curious whether this sort of technique would help them.
The window titlebar text is still centered, with no supported way to put it back to left-justified. For those of us who have been using Windows for years, this is a very annoying change since it breaks the muscle memory of our eyes. When I've tried Windows 8, I always find myself looking at the wrong place to see a window title.
That depends on how long you've been using Windows. =) Windows 95 was the first Windows version that had window titles on the top left rather than the top center.
It's sad, but the Metro motif is being forced on other unrelated Microsoft software departments that don't actually use Metro. For example, Visual Studio 2012 recolored the 2010 UI to meet the company's internal Metro directive, and it looks fucking horrible. It can be difficult to see where UI elements begin and end. They even made the menu bar's options uppercase for some stupid Metro aesthetic reason.
It's pretty clear that Microsoft considers desktop applications - and the accompanying Win32 API - to be obsolete. Windows 8 effectively is telling developers "my way or the highway", but seriously, people generally dislike Metro applications. Could you imagine PhotoShop having to be a Metro application?
Microsoft Windows 8 and 8.1 should have been renamed Microsoft Window.
The Start screen, even in 8.1, is effectively keyboard-based for me. I run programs in 8 by hitting control-escape to bring up the Start screen, then start typing the name of the program I want. To search through the icons is just about impossible.
There is a jailbreak that allows running arbitrary Windows desktop-based programs on a Surface RT - if you recompile for ARM. It even allows kernel-mode drivers. Microsoft still hasn't fixed it, because it's not a security hole in the traditional sense--it requires Administrator privileges.
Because it is possible to make a jailbreak that automatically runs soon after startup, and it is possible to use the jailbreak to load a kernel driver, it is possible to boot up another OS by doing the equivalent of a kexec(). The problem is merely that nobody has done it.
I could write the code to do the kexec(), but I have no clue how to build a Linux kernel, let alone figure out how to interface with the hardware devices. If anyone wants to do that part, which I think is the hard part, let me know. =)
In the U.S., when the Feds take your stuff, they won't give you squat, even if they have nothing on you. They'll keep your computers for years, then finally return your stuff if they don't have a case. They won't let you get copies of your data, either.
With your computer gone for so long, you will have had to bought new ones, and the old one will be obsolete by the time you get them back.
The rule really ought to be that they take your computer, mirror the hard drives, then give it back unless they have immediate proof of wrongdoing on the drive. Seriously, there's no excuse for taking your stuff for years.
Sorry, but it's "SHL" that has a duplicate encoding on x86. There are four slots for non-rotating shift instructions in "group 2": 4=SHL, 5=SHR, 6=???, 7=SAR. The/6 variant looks like it ought to be "SAL", and it is. However, unsigned left shifting is equivalent to signed left shifting, and thus the two opcodes end up doing the same thing. The original 8086 happy processed this instruction as a signed left shift because of how it interpreted the opcode bits, but that's the same as an unsigned left shift.
This was retained in modern processors, whereas "pop cs" was not.
It's interesting to note that the code uses two "undocumented" 6510 instructions:
lax $91 anc #$00 ; clears carry for sinadd below
These instructions are undefined; they work by taking advantage of the internal CPU architecture to execute a hybrid of other legal opcodes. A lot of other older processors have such behavior, such as the Z80. Even the 8086 had a bit of this: "pop cs" and the second encoding of "sar" come to mind. (The 8086's "pop cs" was stolen by the 286 to mean an escape to a second opcode page.)
Slashdot Mirror
I was hoping for a woman this time. Would make for some great antics.
Yep. TPM really is a better design than what's in UEFI. The attack surface against UEFI is quite big.
I actually have a third exploit against part of the whole Secure Boot process, this time a Microsoft bug in Windows itself that lets me load unsigned kernel code at boot time with Secure Boot enabled.
This flaw works on all architectures, so I'm saving it for now. I found it trying to find a new jailbreak for Windows RT 8.1.
Finding an exploit to boot Linux on the Surface RT is like gluing a 500cc engine on your kid's bicycle: Pointless.
Still, feel free to get it out there through the proper channel. The usual zero-day mailing lists should do fine.
It affects x86 as well, making it usable by malware to make bootkits without signed drivers despite Secure Boot. I have to be careful with releasing this one.
Main reason I won't get one is that when (not if) RT dies; all you have left is a paperweight.
At least with laptops, I can stick Linux on them when their version of windows gets too bogged down with viruses.
It's likely possible to make an Android distro or regular Linux for the Surface RT. I have an exploit I've been holding onto that could be used to boot a Linux kernel at startup, even with RT's Secure Boot active.
The hard party of it is making a Linux distro that works on Surface. Having a Windows background, I wouldn't know the first thing about porting Linux to unfamiliar motherboards.
I'm going to guess that they'll only allow independent developers to use verifiable .NET code in their games. Allowing native code is exceptionally dangerous, because it multiplies the attack surface by several times. It's almost guaranteed that sandboxes running native code will have escape bugs on release day.
In Windows 8.1, Microsoft actually made significant changes just to lock down Windows RT more strongly. They created a new type of "protected process" that protects csrss.exe from debugging, which is exactly how the RT 8.0 jailbreak worked. They clearly spent a lot of engineering resources to do this.
I have a thread post here describing some of the changes in 8.1 that were clearly designed to target RT's jailbreak, for they have little other practical use.
Either Microsoft have done security right for the first time in their very long history of bad security, or it's hackable. I'm guessing the last option is more likely.
Some Linux varient on that hardware might be pretty nice.
I have an exploit that can be used for this purpose that I've been keeping secret. I just need to wait for the right opportunity to come to use it.
I found an exploit in a different part of Windows, but they aren't paying for that. They were only paying for mitigation bypass exploits and IE11 exploits.
I guess I'll stick to my original plan and use it to jailbreak Windows RT 8.1 and possibly Windows Phone 8.
It failed because Redmond was four years too late, and Android and iOS are so dominant at all price points that there is simply no room for a third competitor. Surface RT offers nothing that mid and upper end iDevices and Androids do not.
In other words, Microsoft has been out-Microsofted.
The advantage that Windows on a tablet has over iOS and Android tablets is that it runs Windows applications. They're tablets that act like tablets, but also work as laptops when you want one. iOS and Android are crap for productivity applications.
This is the flaw with Windows RT: Windows with only Metro offers nothing over iOS and Android. The fact that you can leave Metro is what Windows does better than the competition, but instead Microsoft decided that the desktop was something to eliminate. Surface RT and Windows 8 in general failed as a result.
I feel like Microsoft was almost there with Windows 8, but their colossal hubris ruined it.
WinRT should never have been born.
What is nice about Windows RT compared to iOS and Android is that it is effectively a full Windows 8. You could leave the Metro world when you had a keyboard and mouse, and effectively start using a laptop.
A huge problem was that Microsoft locked down Surface RT's desktop mode such that only they could make desktop RT programs. You could get to the Windows desktop, but all you could do there is copy files and run Office. Had Microsoft allows making desktop RT apps, some commercial developers would have started porting their apps to RT. In most regards, porting to Windows RT desktop mode is just a recompile with a different CPU setting.
There is a jailbreak for Windows RT, and some open-source desktop applications have been ported to it. However, the fact that it's only unlockable with a jailbreak has meant that no commercial developers have ported their software to the RT desktop mode.
Rather than back down from their mistake, they're actually doubling down: Windows 8.1 not just fixes the jailbreak, but has a bunch of kernel architectural changes just to prevent the type of attack used to jailbreak RT 8.0. If you have a desktop machine running x86/x64 Windows 8.1 Preview, try attaching a debugger to lsass.exe. lsass.exe, csrss.exe, and smss.exe are now "Protected Processes" in 8.1. Protected Processes up until 8.1 have only been DRM-related processes, such as audiodg.exe. And yet, Microsoft went to the trouble to make those system processes Protected just because of the Windows RT jailbreak's existence.
Two words. Secure Boot. That is I think, the entire purpose of secure boot.
Secure Boot on Windows RT can already be worked around, albeit not yet perfectly.
No, "secure boot" prevents this while not actually improving security.
Yep - especially since we're already hot on the tail of jailbreaking Windows RT 8.1.
They don't even have the common decency to at least choose a password that isn't already in every rainbow table on the planet.
If I were to make a back door system, I'd make sure customers knew about it. I'd make it so that a physical switch had to be activated on the device itself in order for the back door to be used. Activating the switch would be plainly obvious, with both physical indicators on the device and in management software, with auditing and warnings that the back door has been activated - and detailed logging of that account logging in. I'd use a 30-character randomly-generated password at least, if not some kind of public-key system, to authenticate the back door login.
If having to go to the physical device is a pain for you the customer, you can always just leave the switch always activated - you'd still be better off than those badg3r5 at HP.
In addition to a lot of other misfeatures like shoving Microsoft Accounts down your throat, Microsoft actually went out of their way with Windows RT 8.1 to lock out the jailbreak that allows you to run non-Metro applications on Windows RT 8.0. Windows RT is basically just Windows 8 ported to ARM, desktop and all, but Microsoft made Windows RT unable to run any non-Microsoft program in the desktop -- all third-party applications *must* be Metro applications on the Windows Store. I really think that Windows RT is Microsoft's testbed for what they envision as the future of all of Windows, both desktop and tablet.
The jailbreak made Windows RT able to run unsigned applications on the desktop. Some open-source applications have now been ported to the jailbroken Windows RT environment. That's pretty much all the jailbreak allowed you to do -- run some desktop-mode open-source programs on Windows RT. The jailbreak doesn't seem to facilitate Windows Store application piracy at all -- at least, I haven't heard of such hacks.
And yet, Microsoft went well out of their way to block it. They revoked the certificate used to sign all RT 8.0 applications. They changed the debugger policy on RT to not allow WriteProcessMemory. They rewrote considerable portions of the Windows RT-specific lockdown DLL, wldp.dll. They marked csrss.exe as a DRM-related "protected process", even though it has nothing to do with DRM. This latter change applies to x86 as well, even though the change was clearly designed to target the method by which the Windows RT 8.0 jailbreak worked.
I'm working on a new jailbreak for RT 8.1. I already have code executing in kernel mode in RT 8.1, so it's just a matter of putting everything together. I'm going to wait until the 8.1 final release before releasing the jailbreak, though, to make things more complicated for Microsoft to fix.
With Windows RT 8.1, Microsoft actually took measures to lock out the jailbreak that allowed running unsigned--and Desktop-based--code on Windows RT. I think that this more than anything shows what you're talking about: Microsoft severely cares that you're using their device designed to showcase Metro to run desktop applications.
By the way, we already have good progress on jailbreaking RT 8.1.
...but are you using your browser from within Metro? I bet most people don't.
Could this be used by lesbian couples in the future to have babies that are biological children of both parents? Obviously, such children would always be daughters, but I'm curious whether this sort of technique would help them.
The window titlebar text is still centered, with no supported way to put it back to left-justified. For those of us who have been using Windows for years, this is a very annoying change since it breaks the muscle memory of our eyes. When I've tried Windows 8, I always find myself looking at the wrong place to see a window title.
That depends on how long you've been using Windows. =) Windows 95 was the first Windows version that had window titles on the top left rather than the top center.
It's sad, but the Metro motif is being forced on other unrelated Microsoft software departments that don't actually use Metro. For example, Visual Studio 2012 recolored the 2010 UI to meet the company's internal Metro directive, and it looks fucking horrible. It can be difficult to see where UI elements begin and end. They even made the menu bar's options uppercase for some stupid Metro aesthetic reason.
It's pretty clear that Microsoft considers desktop applications - and the accompanying Win32 API - to be obsolete. Windows 8 effectively is telling developers "my way or the highway", but seriously, people generally dislike Metro applications. Could you imagine PhotoShop having to be a Metro application?
Microsoft Windows 8 and 8.1 should have been renamed Microsoft Window.
The Start screen, even in 8.1, is effectively keyboard-based for me. I run programs in 8 by hitting control-escape to bring up the Start screen, then start typing the name of the program I want. To search through the icons is just about impossible.
Wake me when someone makes a 2048-qubit quantum computer that can run Shor's algorithm. The Xbox public key and I have some unfinished business.
...and your enemies closer.
There is a jailbreak that allows running arbitrary Windows desktop-based programs on a Surface RT - if you recompile for ARM. It even allows kernel-mode drivers. Microsoft still hasn't fixed it, because it's not a security hole in the traditional sense--it requires Administrator privileges.
Because it is possible to make a jailbreak that automatically runs soon after startup, and it is possible to use the jailbreak to load a kernel driver, it is possible to boot up another OS by doing the equivalent of a kexec(). The problem is merely that nobody has done it.
I could write the code to do the kexec(), but I have no clue how to build a Linux kernel, let alone figure out how to interface with the hardware devices. If anyone wants to do that part, which I think is the hard part, let me know. =)
In the U.S., when the Feds take your stuff, they won't give you squat, even if they have nothing on you. They'll keep your computers for years, then finally return your stuff if they don't have a case. They won't let you get copies of your data, either.
With your computer gone for so long, you will have had to bought new ones, and the old one will be obsolete by the time you get them back.
The rule really ought to be that they take your computer, mirror the hard drives, then give it back unless they have immediate proof of wrongdoing on the drive. Seriously, there's no excuse for taking your stuff for years.
and the second encoding of "sar" come to mind
Sorry, but it's "SHL" that has a duplicate encoding on x86. There are four slots for non-rotating shift instructions in "group 2": 4=SHL, 5=SHR, 6=???, 7=SAR. The /6 variant looks like it ought to be "SAL", and it is. However, unsigned left shifting is equivalent to signed left shifting, and thus the two opcodes end up doing the same thing. The original 8086 happy processed this instruction as a signed left shift because of how it interpreted the opcode bits, but that's the same as an unsigned left shift.
This was retained in modern processors, whereas "pop cs" was not.
It's interesting to note that the code uses two "undocumented" 6510 instructions:
These instructions are undefined; they work by taking advantage of the internal CPU architecture to execute a hybrid of other legal opcodes. A lot of other older processors have such behavior, such as the Z80. Even the 8086 had a bit of this: "pop cs" and the second encoding of "sar" come to mind. (The 8086's "pop cs" was stolen by the 286 to mean an escape to a second opcode page.)