Windows RT 8.1 anti-jailbreak differences - Windows RT Development and Hacking

It looks like they locked out the jailbreak from 8.1 by invalidating all old signatures. Windows RT 8.1's ci.dll does not trust the "1.3.6.1.4.1.311.10.3.6" OID in certificates anymore, only a new "1.3.6.1.4.1.311.10.3.21" OID. Both are required now. How it works is, if a certain configuration bit is not set in the call to CipMinCryptToSigningLevel, attempting to load an executable with a *10.3.6 OID on the certificate but not a *10.3.21, CipMinCryptToSigningLevel will explicitly fail with STATUS_INVALID_IMAGE_HASH--it won't even bother to consider it a 0 signing level.
I bet that this time, they will not give device manufacturers anything but executables that require booting Windows in test mode, something only Microsoft and device manufacturers can accomplish due to Secure Boot.
Microsoft Office's executables are signed with both the 2010 and 2011 keys, presumably so that it can run on both 8.0 and 8.1.
Visual Studio 2012's remote debugger doesn't work anymore, either. I bet that they're working on further locking down the remote debugger to avoid letting us use it to jailbreak.
The only good news I see is that NtUserSetInformationThread sub 7--the kernel exploit--has not been fixed.

Myriachan said:
It looks like they locked out the jailbreak from 8.1 by invalidating all old signatures. Windows RT 8.1's ci.dll does not trust the "1.3.6.1.4.1.311.10.3.6" OID in certificates anymore, only a new "1.3.6.1.4.1.311.10.3.21" OID. Both are required now. How it works is, if a certain configuration bit is not set in the call to CipMinCryptToSigningLevel, attempting to load an executable with a *10.3.6 OID on the certificate but not a *10.3.21, CipMinCryptToSigningLevel will explicitly fail with STATUS_INVALID_IMAGE_HASH--it won't even bother to consider it a 0 signing level.
I bet that this time, they will not give device manufacturers anything but executables that require booting Windows in test mode, something only Microsoft and device manufacturers can accomplish due to Secure Boot.
Microsoft Office's executables are signed with both the 2010 and 2011 keys, presumably so that it can run on both 8.0 and 8.1.
Visual Studio 2012's remote debugger doesn't work anymore, either. I bet that they're working on further locking down the remote debugger to avoid letting us use it to jailbreak.
The only good news I see is that NtUserSetInformationThread sub 7--the kernel exploit--has not been fixed.
Click to expand...
Click to collapse
Do you know if they blocked downgrading (through updating the EFI certs), or if we can just throw the old CI.dll in there or not?
Edit: Nevermind, they state that a recovery drive can return to RT.

netham45 said:
Do you know if they blocked downgrading (through updating the EFI certs), or if we can just throw the old CI.dll in there or not?
Click to expand...
Click to collapse
I can boot the 8.0 recovery image from USB just fine. In fact, if I choose Command Prompt, I can then go run WinDbg if it's on the hard drive. =)
Windows 8.1 knows the name of the new OIDs. The previous OID 1.3.6.1.4.1.311.10.3.6 is "Windows System Component Verification"; the new OID 1.3.6.1.4.1.311.10.3.21 is specifically named "Windows RT Verification".
Replacing ci.dll with the old version causes it to fail to boot. Looking into this more.

Myriachan said:
It looks like they locked out the jailbreak from 8.1 by invalidating all old signatures. Windows RT 8.1's ci.dll does not trust the "1.3.6.1.4.1.311.10.3.6" OID in certificates anymore, only a new "1.3.6.1.4.1.311.10.3.21" OID. Both are required now. How it works is, if a certain configuration bit is not set in the call to CipMinCryptToSigningLevel, attempting to load an executable with a *10.3.6 OID on the certificate but not a *10.3.21, CipMinCryptToSigningLevel will explicitly fail with STATUS_INVALID_IMAGE_HASH--it won't even bother to consider it a 0 signing level.
I bet that this time, they will not give device manufacturers anything but executables that require booting Windows in test mode, something only Microsoft and device manufacturers can accomplish due to Secure Boot.
Microsoft Office's executables are signed with both the 2010 and 2011 keys, presumably so that it can run on both 8.0 and 8.1.
Visual Studio 2012's remote debugger doesn't work anymore, either. I bet that they're working on further locking down the remote debugger to avoid letting us use it to jailbreak.
The only good news I see is that NtUserSetInformationThread sub 7--the kernel exploit--has not been fixed.
Click to expand...
Click to collapse
I run office from windows.old but it doesnt work at all.

windowsrtc said:
I run office from windows.old but it doesnt work at all.
Click to expand...
Click to collapse
Windows RT 8.1 installs a new set of Office executables that are signed with the new signature. The old Office executables won't work, just like everything else won't work.

Trying to use the old ci.dll fails, but using the old boot loader does not. In fact, the old 8.0 boot loader can actually boot the 8.1 kernel just fine, not even noticing a difference.
The 8.1 bootmgr.efi is signed with the *10.3.21 OID. This means that they could reflash the firmware to only accept *10.3.21 signatures during the final build 8.1 upgrade process if they wanted to be mean to people in the way that Apple is. In other words, I fully expect that Microsoft will do this. Even worse, they could force the 8.1 install on most people via Windows Update if it's free to RT users.
We need another way in. >.<

I dunno, I think this should reinvigorate those with the know-how to figure out how to get Linux on the thing so we could keep control of our own devices. It's come up a couple times in a couple threads, and I'm sure a kernel driver is the easiest way to go about it for now.

The Linux boot ideas have all been about cross-booting from RT into Linux. If 8.1 locks out our ability to run unsigned code (including kernel drivers), then it would no longer be possible to load Linux either. New devices, or older ones that got the upgrade, would be stranded.
Don't get me wrong, I thing that getting Linux working is an admirable goal. Just don't expect it will fix the 8.1 "now with moar lockdown!" problem.

Myriachan said:
Visual Studio 2012's remote debugger doesn't work anymore, either.
Click to expand...
Click to collapse
What about VS2013 - the preview version has just been released... ?

GoodDayToDie said:
The Linux boot ideas have all been about cross-booting from RT into Linux. If 8.1 locks out our ability to run unsigned code (including kernel drivers), then it would no longer be possible to load Linux either. New devices, or older ones that got the upgrade, would be stranded.
Don't get me wrong, I thing that getting Linux working is an admirable goal. Just don't expect it will fix the 8.1 "now with moar lockdown!" problem.
Click to expand...
Click to collapse
Well, I meant, get out ahead of it and don't ever bother upgrading to 8.1. Leave it jailbroken at 8.0 and give up on Microsoft thereafter.

GoodDayToDie said:
The Linux boot ideas have all been about cross-booting from RT into Linux. If 8.1 locks out our ability to run unsigned code (including kernel drivers), then it would no longer be possible to load Linux either. New devices, or older ones that got the upgrade, would be stranded.
Don't get me wrong, I thing that getting Linux working is an admirable goal. Just don't expect it will fix the 8.1 "now with moar lockdown!" problem.
Click to expand...
Click to collapse
It all depends on whether upon 8.1's final release Microsoft will do a firmware update that disallows bootarm.efi files that were signed with the original keys.

"The following error occurred: The Remote Debugger cannot be started as an Administrator on Microsoft Windows RT. Restart the remote debugger with normal user permissions."
I'm rather disappointed in MS for /still/ not unlocking RT.
Edit:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Looks like they locked down the debugger decently.

I think the best way is to find a way to flash uefi by uart.so we can hack uefi directly.
BTW,windows 8.1 WDK contains arm files and may be they can be used on vs2012.

I came up with a copy of windbg/cdb that works, but it looks like they blocked attaching to csrss by marking it as a protected image.

netham45 said:
I came up with a copy of windbg/cdb that works, but it looks like they blocked attaching to csrss by marking it as a protected image.
Click to expand...
Click to collapse
This may make things harder, but you can try to run WinDBG as a service and run your script. Start from here: http://support.microsoft.com/kb/824344

netham45 said:
I came up with a copy of windbg/cdb that works, but it looks like they blocked attaching to csrss by marking it as a protected image.
Click to expand...
Click to collapse
I PM'd you about discussing ways into 8.1. I sent a PM because I would rather not discuss certain things visibly prior to 8.1 release when Microsoft still has an easy chance to defeat what we come up with before launch.

Myriachan said:
... Windows 8.1 knows the name of the new OIDs. The previous OID 1.3.6.1.4.1.311.10.3.6 is "Windows System Component Verification"; the new OID 1.3.6.1.4.1.311.10.3.21 is specifically named "Windows RT Verification".
Replacing ci.dll with the old version causes it to fail to boot. Looking into this more.
Click to expand...
Click to collapse
Since your exploit still works, can you locate ci.dll and patch it in-memory? Or is Microsoft performing runtime integrity checks?
As far as I {knew|know}, Microsoft was only doing on-disk checks before mapping the image into memory. See Alan Meese's Windows Phone: Security Deep Dive, http://channel9.msdn.com/Events/TechEd/Europe/2012/WPH304. (I know its a different platform, but I would expect it to be very similar).
Jeff

noloader said:
Since your exploit still works, can you locate ci.dll and patch it in-memory? Or is Microsoft performing runtime integrity checks?
Click to expand...
Click to collapse
Yes, which is what the 8.0 exploit does. Finding ci.dll is simple: EnumDeviceDrivers or whatever the NT API equivalent is. The hard part is writing to kernel memory.
Two exploits are required in order to jailbreak. The first is to execute arbitrary assembly code at user level. The second is to attack kernel mode with an exploit. Both of these are difficult problems to solve. In 8.0, the code execution exploit was to use a Microsoft-signed debugger executable to modify an existing program's code. The kernel exploit was the kernel not properly validating parameters from csrss.exe, a trusted process.
Microsoft didn't release a security fix for the csrss.exe exploit probably under the idea of being on the other side of the airtight hatchway, using Raymond Chen terminology: attacking csrss.exe requires Administrator access, so from a security perspective, an attacker would already have won. The only time that that philosophy doesn't apply is with DRM protections--and guess what, the 8.1 fix is to mark csrss.exe as a DRM process, which it clearly is not.
The other big thing Microsoft did in 8.1 was to invalidate all the signed debugger executables from 8.0, and make the new 8.1 debuggers require a special secure boot mode that only device manufacturers and Microsoft can enable.

Myriachan said:
It looks like they locked out the jailbreak from 8.1 by invalidating all old signatures. Windows RT 8.1's ci.dll does not trust the "1.3.6.1.4.1.311.10.3.6" OID in certificates anymore, only a new "1.3.6.1.4.1.311.10.3.21" OID. Both are required now. How it works is, if a certain configuration bit is not set in the call to CipMinCryptToSigningLevel, attempting to load an executable with a *10.3.6 OID on the certificate but not a *10.3.21, CipMinCryptToSigningLevel will explicitly fail with STATUS_INVALID_IMAGE_HASH--it won't even bother to consider it a 0 signing level.
I bet that this time, they will not give device manufacturers anything but executables that require booting Windows in test mode, something only Microsoft and device manufacturers can accomplish due to Secure Boot.
Microsoft Office's executables are signed with both the 2010 and 2011 keys, presumably so that it can run on both 8.0 and 8.1.
Visual Studio 2012's remote debugger doesn't work anymore, either. I bet that they're working on further locking down the remote debugger to avoid letting us use it to jailbreak.
The only good news I see is that NtUserSetInformationThread sub 7--the kernel exploit--has not been fixed.
Click to expand...
Click to collapse
Myriachan - do you have a reference for those changes? A friend is writing a paper and would like to verify the source and cite you. Google is turning up lots of spurious noise.

noloader said:
Myriachan - do you have a reference for those changes? A friend is writing a paper and would like to verify the source and cite you. Google is turning up lots of spurious noise.
Click to expand...
Click to collapse
I believe everything in this thread is our own research.

Related

[Q] Hacking Windows RT to Run Desktop Apps?

Obviously no one has a had a chance to try this yet, but will there be an effort to hack Windows RT to enable more desktop applications? I really don't care about the desktop, but there's one tiny utility that would be extremely useful. I use a program from Microsoft called "Mouse Without Borders" to control two computers with one keyboard and mouse. I'd love to do this on the Surface RT I'll be buying, but of course because it's a desktop application, I probably won't be able to.
revxx14 said:
Obviously no one has a had a chance to try this yet, but will there be an effort to hack Windows RT to enable more desktop applications? I really don't care about the desktop, but there's one tiny utility that would be extremely useful. I use a program from Microsoft called "Mouse Without Borders" to control two computers with one keyboard and mouse. I'd love to do this on the Surface RT I'll be buying, but of course because it's a desktop application, I probably won't be able to.
Click to expand...
Click to collapse
Compiling desktop apps for ARM using VS 2012 gives an error message, but it can be bypassed. Not sure if the results will run in Windows RT though.
Of course there's no way to find out until Windows RT devices are released to the public, because everyone who has access to one is under NDA. Have some patience.
for what you are suggesting, i believe it is technically either impossible or reliant on an emulator. since windows RT is for ARM processors and normal windows is for x86 processors, instructions would need to be converted from x86 to ARM in order to be used. this would be the job of an emulator, which would most likely not be able to be integrated deeply enough in the OS to do what you are talking about. even if it was, it would run slower than optimal.
now if microsoft releases the source code for their application (very unlikely), its an entirely different story. then the code can be recompiled for an ARM processor, making anything possible.
someone correct me if im wrong, but i believe im correct.
Pseudonym117 said:
for what you are suggesting, i believe it is technically either impossible or reliant on an emulator. since windows RT is for ARM processors and normal windows is for x86 processors, instructions would need to be converted from x86 to ARM in order to be used. this would be the job of an emulator, which would most likely not be able to be integrated deeply enough in the OS to do what you are talking about. even if it was, it would run slower than optimal.
now if microsoft releases the source code for their application (very unlikely), its an entirely different story. then the code can be recompiled for an ARM processor, making anything possible.
someone correct me if im wrong, but i believe im correct.
Click to expand...
Click to collapse
As someone who has one of these devices, I can't say much more other than it will not happen, I am sorry. You'll need to start barking at the developer to make a ARM Compatible App... Not likely it will happen as the API's are very different.
lseidman said:
As someone who has one of these devices, I can't say much more other than it will not happen, I am sorry. You'll need to start barking at the developer to make a ARM Compatible App... Not likely it will happen as the API's are very different.
Click to expand...
Click to collapse
You have an ARM device? If so, can you say 100% that there is no way to target win32/desktop using new code? It would be great to know for sure. I know it's possible to compile desktop code that targets ARM, producing a certain mystery executable. The only question is, will it actually run?
I have an arm device running WindowsRT. I compiled a HelloWorld for arm no problem in VS2012.
Unfortunately it will not run. Get 'Windows cannot verify the digital signature for this file'
If anyone knows a workaround to this we might be able to get it working
xanderkaiber said:
I have an arm device running WindowsRT. I compiled a HelloWorld for arm no problem in VS2012.
Unfortunately it will not run. Get 'Windows cannot verify the digital signature for this file'
If anyone knows a workaround to this we might be able to get it working
Click to expand...
Click to collapse
well the simple way would be to sign it. HOW to sign it is a completely different problem... there may be a group policy change or registry edit to turn off signature verification, but i am not familiar with windowsRT at all.
phailyoor said:
You have an ARM device? If so, can you say 100% that there is no way to target win32/desktop using new code? It would be great to know for sure. I know it's possible to compile desktop code that targets ARM, producing a certain mystery executable. The only question is, will it actually run?
Click to expand...
Click to collapse
How did you bypass the error message in VS2012? Can you share the exact steps you took to bypass the error as well as your mystery executable here so that folks who are under NDA and have early access to the ARM devices can try it out?
Since Office RT is a desktop app, one can only assume all of this is possible.
Windows RT is basically just Win8 recompiled for ARM, with one major exception: EXE files need to be signed by Microsoft before they will run. This means that MS can release desktop apps just fine - they have the signing keys, after all - but third-party software can't run by itself (as a desktop app) and will need to be bundled as an .APPX file (Metro-style app bundle).
If you want to try bypassing the signature check, there are a few things you could attempt. One would be to create your own signing certificate, install the public key in the OSes root code signing cert store (not the per-user store, though it qprobably wouldn't hurt to install it there too), and then sign your test apps with that cert. MS *probably* used certificate pinning - where a specific cert is used, rather than just any cert present in the OS of sufficient trust level - but they may not have, too. Alternatively, you could try looking for some legacy or debug functionality to disable the code-signing. Finally, you coul try using a built-in program, rundll, to invoke your applications.
I can't test any of this right now, because I don't have an RT device. There's a lot of research on them that I want to do, though.
Quote from one very old MS Windows 8 document, from those times when windows RT was called "woa" (2011). Everything could have changed from those days.
Description of the change:
WOA platforms will require that all desktop binary images be signed with a trusted Microsoft certificate. Any unsigned code will fail to load. This document describes the technical steps required to enable unsigned test, development, or manufacturing applications to run. This document does not cover Metro Style applications for which there is a separately documented signing requirement and developer licensing.
Action required
In order for any test binary or tool to run on WOA platforms you must do one of the following:
· Register the install location of your test binaries as an exclusion path, OR
· Attach a Kernel Debugger and disable checking by setting the appropriate registry value
...cut...
2. Scripts - Scripts will be allowed to run if the script host (e.g. cscript.exe, cmd.exe, etc.) is Microsoft signed or is run under an exclusion path.
...cut...
How to register your test binaries in an exclusion path
...cut...
Exclusion paths are listed in the following registry key in REG_MULTI_SZ format:
Key: HKLM\SYSTEM\CurrentControlSet\Control\CI\TRSData
Value: TestPath
Paths added to this key should be in one of two formats:
1. Path (recursive): \Program Files\TestAutomationPath
2. Binary (specific): \Program Files\TestAutomationPath\mybinary.exe
Note: Do not include the drive letter of the volume. Each path will be excluded across all volumes.
...cut...
The following paths are restricted and cannot be added as an exclusion:
1. \
2. \Windows
3. \Windows\System32
4. \Program Files
...cut...
How to disable signature verification with an attached Kernel Debugger
To disable signing verification when a Kernel Debugger is attached the “DebugFlags” value must be deleted from the “HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CI” registry key and the system must be rebooted. After this Signing Verification will not take place.
This can be scripted by putting the following in a .cmd script and executing with admin privilege:
cmd /c reg delete "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CI" /v DebugFlags /f
shutdown -r -t 0
...cut...
Note: Enabling Kernel Debug will not be allowed by default on machines with Secure Boot enabled. Either Secure Boot will need to be disabled, or during boot the F8 menu selection to EnableDebugging must be chosen.
...cut...
At a later point, changes will be made to Windows 8 builds which will enforce that only machines configured as “Debug System” will support exclusion paths.
A “Debug System” is will initially be identified by the presence of the Microsoft Test Signing CA in the UEFI signature database (“db”).
...cut...
Note: If there is a need to run unsigned tools, the system can be configured as a “Debug System” during manufacturing but there must be a step in the production process that removes the Microsoft Test CA.
Production machines must not ship with the Microsoft Test CA in the db.
Click to expand...
Click to collapse
First we need to get hands on ARM device. I'd recommend Qualcomm-based, as chinese friends regularly leak their docs/sources. MS Surface is Tegra-based, so don't buy it
And one more thing:
This document “Enabling Debug Mode for Development, Manufacturing, and Support of Windows RT Devices” discusses placing a production device into ‘Debug Mode’ is accomplished by creating a per device Windows Debug Policy using tools provided by Microsoft.
Click to expand...
Click to collapse
Unfortunately I don't have “Enabling Debug Mode...” document, as I don't have access to connect.microsoft.com. Anyway it would not be helpful for us, end-users.
So to turn on a device to debug mode - you'll need a special "something" that is signed for your particular device. Sign is based on 2048-bit key, so you can't bruteforce it. But you can try to hack UEFI. UEFI is partially opensourced, so you can start to study its code now from edk2.sf.net
And one more way. Remember the test signing mode in Win7+. It is still present in Win8. Turn it on via bcdedit on your RT-device, use your own certificate to sign your driver or your program, ..., profit.
But be careful when hacking. There are known problems with BitLocker when test signing mode is on. The OS simply would not boot. Lets hope that we could disable BitLocker on our devices...
Just tried editing the registry to add a testing path. Didnt work
Still asks for certificate
xanderkaiber said:
Just tried editing the registry to add a testing path. Didnt work
Click to expand...
Click to collapse
According to MS document - this would work only on "debug mode"/"debug system" devices.
Can you turn on the test-signing mode:
Code:
In elevated CMD type:
bcdedit.exe /set {globalsettings} testsigning Yes
bcdedit.exe /set {bootmgr} testsigning Yes
bcdedit.exe /set {current} testsigning Yes
and try to sign your app with your own certificate I hope that test signing is still present on WinRT.
But first check that you are not using BitLocker (the "get-bitlockerVolume" command in admin's powershell). According to MS docs the retail device would not boot in this case (this info is taken from windows phone 8 "portico" docs, so may be unrelated to WinRT devices).
danchar4 said:
How did you bypass the error message in VS2012? Can you share the exact steps you took to bypass the error as well as your mystery executable here so that folks who are under NDA and have early access to the ARM devices can try it out?
Since Office RT is a desktop app, one can only assume all of this is possible.
Click to expand...
Click to collapse
Theres some info on the web somewhere for a config change to VS2012 that lets it build ARM desktop apps
Not that you can run them due to the signing issues
http://stackoverflow.com/questions/...op-programs-be-built-using-visual-studio-2012
I did it!
I managed to build and run a windows application for arm! Just turned on test signing and signed it with my own cert, then compiled for ARM in vs2012 and it ran
Definitely a good sign
xanderkaiber said:
I did it!
I managed to build and run a windows application for arm! Just turned on test signing and signed it with my own cert, then compiled for ARM in vs2012 and it ran
Definitely a good sign
Click to expand...
Click to collapse
Working on the surface?
Sent from my SCH-I535 using Tapatalk 2
eorsini said:
Working on the surface?
Sent from my SCH-I535 using Tapatalk 2
Click to expand...
Click to collapse
Not a surface, a Qualcomm engineering sample device. But I imagine it would definitely work on the surface also.
xanderkaiber said:
I managed to build and run a windows application for arm! Just turned on test signing and signed it with my own cert, then compiled for ARM in vs2012 and it ran
Click to expand...
Click to collapse
Great news
Seems that turning on the test-sign mode would soon be a must on ARM devices, at least for those of us who need programs like VLC player, DosBox, FAR manager and so on.
As far as I can see, you could port pretty much anything (as long as it's c++) if you can get the source code.
Might give VLC a try now
Doesn't seem like a very good solution to me though.
While it's nice that progress is made, I think that running unsigned apps should be the primary focus - Microsoft could revoke the keys at any time.

What's the real problem about linux on surface rt ?

Hi,
I've buy from at lest one mont a surface rt, i've jailbreak it and install filezilla and notepad+++ so.... but i'd like anymore. Like many people i'd like to install a linux distribution on it but i dont really understand what is the problem...
I've know about:
Surface get a secure boot (EFI) and we can't disable the secure boot on surface RT caused windows need a valid key (?). I've read that linux got some distributions arm based (ubuntu, debian, fedora) and i think i've understand about ubuntu got a valid microsoft signature with a ssl provider that can bypass the useless verification... am i right?
So, if ubuntu (or another distro), got a valid sign for bypassing the limitation to due EFI why can't we normal install linux such like surface pro??
Best regards and sry for my bad english ^^'
----------------------------------------------
Some distros has keys to X86 UEFI. No one (other than Microsoft) has keys for ARM.
And (afair) due to some limitations of jailbreak we have no way to execute linux kernel.
This applies to any RT device.
kitor said:
And (afair) due to some limitations of jailbreak we have no way to execute linux kernel.
Click to expand...
Click to collapse
Is this true for sure? I figured especially since we have driver-level access we could possibly tear down the Windows kernel in reverse and start execution of arbitrary code. But I might have missed something.
The bigger issue about trying to port Linux to any device without official Linux support is usually in getting the kernel to boot and then making the hardware itself useful after that. This usually means you have to work "blind" and rely on some kind of low-level serial output to monitor the kernel boot to see where it panics. Only after getting a successful kernel boot can you even begin to think about drivers for the display, touch screen, etc.
So the prerequisites to even beginning to port to e.g. a Surface would be to find some way to kick out Windows and start arbitrary execution, enable some kind of low-level serial debugging for the would-be kernel, and then tediously poke and prod until it can successfully start. I'm not sure anyone knows of a dependable way to get serial debugging information.
Embedded devices on the whole are a lot more finicky and a lot less tolerant than normal PCs, generally due to their proprietary nature requiring a lot of hardware knowledge to initialize everything properly. About the only thing we'd have going for us is that it's a Tegra chipset, so if you can get the underpinnings working, you can probably at least get the basics like video and USB working without too much trouble.
I think the biggest thing about it is like the rest of RT ... there's just not enough interest in those with the skills to even attempt this because this is such an extreme minority platform. I imagine a Surface RT would make an excellent little Linux tablet, but I'm not holding my breath.
Well, If somebody would write something like WinKExec, or HaRET (haret allowed to analyse gpios and memory on WinCE/WM devices) then things may be possible. I own XPS10, so quite different device (as it has Snapdragon CPU), but I have some (small) experience on porting Linux on ARM devices - some time ago I was able to get Linux working on Bsquare Maui: http://pdasite.pl/kitor/maui_linux/ (including hardware reverse engineering - tracking gpios using multimeter - this way i found hidden usb host )
There's been talk of a WinKExec-like approach for months. Nobody has attempted it yet, though, or if they have they kept quiet about it.
One of the problems getting something like that working on RT is that it blocks kernel debugging, so you have to work pretty blindly. Then there's all the driver issues.
What about getting android to boot on it? There's drivers and such for tegra 3. I think its possible to build and deploy if we can get a kernel exploit. Am I wrong?
Android depends on Linux. If you can't get a Linux kernel booted, you won't be able to get Android to start up either.
skiman10 said:
What about getting android to boot on it? There's drivers and such for tegra 3. I think its possible to build and deploy if we can get a kernel exploit. Am I wrong?
Click to expand...
Click to collapse
The kernel by itself would be *relatively* easy (translation: still quite hard, but we could probably do it if people cared enough). However, getting all the other hardware (you know, things like the touchscreen, WiFi, and such) would likely be difficult, and without all that, it's pretty useless as a tablet. This is true for both Android and "desktop" Linux.
Where should I start to get a kernel to boot? I'm an android exploiter trying to dabble in Windows exploitation.
Sent from my HTC6500LVW using Tapatalk
Well, unless you think you can break Secure Boot, you should start by writing/porting a way to use the NT kernel to launch the Linux kernel. That probably means a lot of NT driver development stuff (done without the aid of a kernel debugger, just for extra fun).
There's a doc on internet from the blackhat usa 2013 seems to be interesting.
The man from the pdf get the exploit of injecting some code from the boot, so i think we can done this, no ?
If anyone tried and arrive he'll get amout of money from me
graphsys said:
There's a doc on internet from the blackhat usa 2013 seems to be interesting.
The man from the pdf get the exploit of injecting some code from the boot, so i think we can done this, no ?
If anyone tried and arrive he'll get amout of money from me
Click to expand...
Click to collapse
Can you PM me the article?
---------- Post added at 10:59 AM ---------- Previous post was at 10:57 AM ----------
GoodDayToDie said:
Well, unless you think you can break Secure Boot, you should start by writing/porting a way to use the NT kernel to launch the Linux kernel. That probably means a lot of NT driver development stuff (done without the aid of a kernel debugger, just for extra fun).
Click to expand...
Click to collapse
I think there is an exploit for Secure Boot, it just hasn't been shared yet...
If you mean the exploit I think you mean (discovered by an XDA member), it's a Windows bug, not actually a Secure Boot bug. It doesn't actually allow booting a different OS directly, just messing with Windows after bootup. We already have the jailbreak (for 8.0), which is pretty much equivalent.
GoodDayToDie said:
If you mean the exploit I think you mean (discovered by an XDA member), it's a Windows bug, not actually a Secure Boot bug. It doesn't actually allow booting a different OS directly, just messing with Windows after bootup. We already have the jailbreak (for 8.0), which is pretty much equivalent.
Click to expand...
Click to collapse
Im researching the doc i've found to provide you it.
Its not the jailbreak done by clockr ported by neman its another jailbreak who's available from the boot, but if remember they dont give sources... search in progress i'll post the link
There is one theoretical way to remove secureboot on a jailbroken device. It is rather easy: write a driver that reads/writes physical RAM. Find EFI_RUNTIME_SERVICES in memory and look for SetVariable function. Patch it so that it does not check for a valid signature. Than write your own certificates to UEFI with this patched function. Profit.
I've already done the first part - wrote a driver and found the table in memory (this is really an easy part). But my device died before I was able to successfully overwrite the certificates.
As far as I know similar method was once demonstrated for an x86 UEFI, just noone made it for ARM.
That... is a rather clever option too, although I'm tempted to avoid things which require modifying the firmware (too much option for future updates to break things). Still, a good option for those of us with gen1 devices who would like to be able to upgrade without losing the jailbreak, and also a good option for those who would like to install different OS images...
mamaich said:
There is one theoretical way to remove secureboot on a jailbroken device. It is rather easy: write a driver that reads/writes physical RAM. Find EFI_RUNTIME_SERVICES in memory and look for SetVariable function. Patch it so that it does not check for a valid signature. Than write your own certificates to UEFI with this patched function. Profit.
I've already done the first part - wrote a driver and found the table in memory (this is really an easy part). But my device died before I was able to successfully overwrite the certificates.
As far as I know similar method was once demonstrated for an x86 UEFI, just noone made it for ARM.
Click to expand...
Click to collapse
Can we get in contact? I'd love to get a more detailed plan that I can try. Gen 1 Surface RT on Windows 8 RT.
One demo about bypass: youtube.com/watch?v=i9ULYwRK1iU searching again the pdf mens
GoodDayToDie said:
Well, unless you think you can break Secure Boot, you should start by writing/porting a way to use the NT kernel to launch the Linux kernel. That probably means a lot of NT driver development stuff (done without the aid of a kernel debugger, just for extra fun).
Click to expand...
Click to collapse
About the only way you could possibly break secure boot is possibly by spoofing a key or potentially modify the UEFI to have secure boot disabled. While both are technically possible, you'd have to find an exploit to do it because I'm sure the UEFI probably can't be easily flashed
ThatGuy94 said:
About the only way you could possibly break secure boot is possibly by spoofing a key or potentially modify the UEFI to have secure boot disabled. While both are technically possible, you'd have to find an exploit to do it because I'm sure the UEFI probably can't be easily flashed
Click to expand...
Click to collapse
if you got a device with a jtag interface left open, that should be easy enough. The problem is that EPROM "fuses" are usually burned on the SOC. The secureboot check is hardcoded check that flag. You can't alter the bootloader without invalidating its signature, and it's practically impossible to unset an EPROM fuse.

[RT] Windows RT 8.1 Jailbreak Discussion

If you have nothing to add to this discussion please do not post. Thanks
Im hoping that we can make a list of requirements for this jailbreak to happen. Please read along with us and if you have any ideas regarding any of the steps please help us out...
Thanks,
Toxickill.
In JB 8.0 we change a byte which indicates the sign level from "Microsoft" to "Unsigned".
Now this is protected by PatchGuard: you will get BSOD if you change it.
I think this is probably the only change.
LolitaPlus said:
In JB 8.0 we change a byte which indicates the sign level from "Microsoft" to "Unsigned".
Now this is protected by PatchGuard: you will get BSOD if you change it.
I think this is probably the only change.
Click to expand...
Click to collapse
Well can we bypass patchguard? Because people over at easy hook have written a c# patchguard 3 bypass driver maybe we can build off of that?
yeah patchguard has been bypassed I think https://twitter.com/standa_t/status/437972336705159169
master.peterm said:
yeah patchguard has been bypassed I think https://twitter.com/standa_t/status/437972336705159169
Click to expand...
Click to collapse
Ok so now that it can be done im going to fire up my surface and get working on a new jailbreak tool. If all succeeds then i will update accordingly. Hopefully bypassing patchguard is all that is needed to run old bypass methods. If patch guard stays bypassed then we can make the jailbreak persistent through sessions.
Well, the other problem is that you can't attach a debugger to CSRSS.EXE anymore. So you need a different way to change the relevant value (or a way to bypass the Protected Process restriction).
I think Myriachan already has a way to do that, though; she mentioned that she'd managed to jailbreak but Patchguard was causing the system to crash, so she was working on a way around that.
GoodDayToDie said:
Well, the other problem is that you can't attach a debugger to CSRSS.EXE anymore. So you need a different way to change the relevant value (or a way to bypass the Protected Process restriction).
I think Myriachan already has a way to do that, though; she mentioned that she'd managed to jailbreak but Patchguard was causing the system to crash, so she was working on a way around that.
Click to expand...
Click to collapse
Would patchguard bsod if we removed the protected process on csrss?
Also, would shell code be able to call ntdll.dll methods? We might be able to code arm shell code and call a method to temporarily revoke its protected process flag.
Edit:
Could we attach the debugger to a none protected process, execute shell code that removes process protection? Only problem is writing shell code is not my thing and especially for arm where its not documented as well.
Also could someone PM me with a cdb.exe thats signed for windows rt 8.1? the one provided with the old jailbreak is only signed for 8.
... You do realize the Protected Process flag is in the kernel, right? How do you plan to remove it when, in order to modify kernel memory, you would need to attach to a protected process? It's not like this is the RO flag on a file or something.
The whole point of Windows protected processes is to avoid letting somebody debug them even if they have full control over the machine (they were originally designed for DRM). In testsigning mode or with a kernel debugger, they usually won't launch at all (CSRSS will - it's critical for all Win32 processes, including stuff like Explorer - but the DRM ones won't). This isn't something Microsoft is going to just allow people to turn off. We could theoretically patch around the restriction with the aforementioned kernel debugger or with a testsigned kernel-mode driver, but if we could put RT into Testsigning or use a KD on it we wouldn't need anything else at all anyhow; either of those are sufficient for an easy jailbreak.
When thinking about breaking into the system, think about what you want to accomplish. Then identify attack vectors to get there. Then think about how those attack vectors might be blocked. Then think about how you might bypass those blocks. Etc... If you can't get at least as far as the fourth step, you won't accomplish much (certainly not against a target as hardened as Windows).
GoodDayToDie said:
... You do realize the Protected Process flag is in the kernel, right? How do you plan to remove it when, in order to modify kernel memory, you would need to attach to a protected process? It's not like this is the RO flag on a file or something.
The whole point of Windows protected processes is to avoid letting somebody debug them even if they have full control over the machine (they were originally designed for DRM). In testsigning mode or with a kernel debugger, they usually won't launch at all (CSRSS will - it's critical for all Win32 processes, including stuff like Explorer - but the DRM ones won't). We could theoretically patch around this with the aforementioned kernel debugger or with a testsigned kernel-mode driver, but if we could put RT into Testsigning or use a KD on it we wouldn't need anything else at all anyhow; either of those are sufficient for an easy jailbreak.
Click to expand...
Click to collapse
So just to clarify we can not use this undocumented API call that works in Win8.1 x64 on RT:
Code:
[DllImport("ntdll.dll", SetLastError = true)]
internal static extern int NtSetInformationProcess(IntPtr hProcess, int processInformationClass, ref int processInformation, int processInformationLength);
int enable = 0;
NativeMethods.NtSetInformationProcess(CSRSS.exe HANDLE, 29, ref enable, sizeof(int));
C# code of course but you could easily code in any language.
I don't see any way you can set the Protected Process flag this way... ProcessBreakOnTermination is not, so far as I know, in any way related (although CSRSS should have that flag set anyhow, and should have had it since before protected processes were even added to NT at all). If you could *set* the ProcessBasicInformation you could in theory overwrite the PEB, but supposedly that one is query-only (according to undocumented.ntinternals.net, which may be wrong). Also, you may find that you can't call OpenProcess with PROCESS_SET_INFORMATION on CSRSS, at least on RT 8.1. Worth trying though, perhaps...
GoodDayToDie said:
I don't see any way you can set the Protected Process flag this way... ProcessBreakOnTermination is not, so far as I know, in any way related (although CSRSS should have that flag set anyhow, and should have had it since before protected processes were even added to NT at all). If you could *set* the ProcessBasicInformation you could in theory overwrite the PEB, but supposedly that one is query-only (according to undocumented.ntinternals.net, which may be wrong). Also, you may find that you can't call OpenProcess with PROCESS_SET_INFORMATION on CSRSS, at least on RT 8.1. Worth trying though, perhaps...
Click to expand...
Click to collapse
Well apparently when passing an int (29) as the ProcessInformationClass value that indicates a protected process, and it does work for enabling it and disabling it on other processes so far, process acts like csrss once enabled. We have to make sure to set the SeDebugPrivilege flag on the current process in order to make OpenProcess open a process with the flag PROCESS_ALL_ACCESS which is required for NtSetInformationProcess.
Looking into this, might be worth a shot.
Interesting. MSDN for NtQueryInformationProcess (http://msdn.microsoft.com/en-us/library/windows/desktop/ms684280(v=vs.85).aspx) says that value is ProcessBreakOnTermination and indicates a "critical" process, which I interpreted to mean one that cannot be safely exited (there are a few of these, and have been since XP or before, while protected processes were introduced in Vista and "lightweight protected processes" (the kind that CSRSS is, apparently) were introduced in 8.1. Still, worth a shot.
Administrator should have SeDebugPrivilege, and *probably* have it enabled by default. I'm still not sure you will be able to open the handle to CSRSS - it's explicitly not supposed to be possible to mess with it even if you *are* Administrator (or otherwise have debug privs) - but it's worth trying.
EDIT: There's a policy in Local Security Policy Editor (secpol.msc, yes it's present on RT at least 8.0, if not on 8.1 it's in the registry anyhow), under Local Policies -> User Rights Assignment. You can control what privileges (in the NT Se*Privilege sense) processes owned by given users have. For example, "Debug programs" (This user right determines which users can attach a debugger to any process or to the kernel. Developers who are debugging their own applications do not need to be assigned this user right. Developers who are debugging new system components will need this user right to be able to do so. This user right provides complete access to sensitive and critical operating system components.). You can add "ALL APPLICATION PACKAGES" to the assignees. In theory, this would mean that app packages now have SeDebug. They *might* not be able to use it anyhow (because of the lowbox restrictions) but if they are, that removes the need to use a debugger to inject code into a desktop process running as Admin; just write a native app that calls the relevant APIs.
Great find, i'm away from my dev box until later today but i will try this out. I'm not use to finding the exploit, how ever i'm perfectly capable of writing code for one once its found. But ill dig deeper maybe powershell could still be a possibility.
Edit: Found a spreadsheet that documents all of the security registry keys for 8.1! I found Debug Programs flag for User Rights Assignment in the document for 8.1 and it says minimum requirement is Windows XP! So its most likely on 8.1, my dev box and surface are both on 8.1 so I can verify later I also have the registry key.
Also found load and unload device drivers flag, not sure if thats of any use.
Second Edit: "User Rights security settings are not registry keys" there is no registry key to edit so we would have to either use secpol.msc or figure out where these values are stored.
Is there any way for us to figure out how csrss is being flagged as a protected process? Is that done in the kernel, with its createprocess params or is it done by the process itself?
Also has anyone checked if they modified Powershell's exe to prevent unsigned C# code from executing? And if so we also should check if we can use an 8.0 copy on 8.1 worth a shot as well but i'm almost positive it will not execute because of the "Windows cannot verify the digital signature of this application."
It would help if we could at least get cdb or WinDbg working on 8.1 even if we can't attach it to csrss.
I PMd netham45 about how he got cdb working on 8.1 but he has not replied yet. I've checked the WDK 8.1 release and everything is there even for arm except cdb.
Edit:
Also i'm working with Spazzarama over at EasyHook to see how he wrote his Patchguard disabler. If I can get unsigned code running even if it means we need to use a dev id just to start the jailbreak like the original version of nethams tool it would be worth it if it means we can disable patchguard. I have a few ideas on how to go about this, possibly creating a blank app and compile it. Then disassemble the exe with ildasm and replace the entry point with code that includes desktop code, then stitch it back up with ilasm (command line args allow arm code creation and toggling app containers, as long as the tools that create an app package don't test command line args it should work ok and be valid because it wont load any desktop dll's if they are not called i've tested this on normal environments. Then we might be able to get desktop code running that will allow us to disable patchguard, modify the value and then remove the app.
Lots of me rambling on about that, hopefully we get somewhere.
Toxickill said:
Is there any way for us to figure out how csrss is being flagged as a protected process? Is that done in the kernel, with its createprocess params or is it done by the process itself?
Also has anyone checked if they modified Powershell's exe to prevent unsigned C# code from executing? And if so we also should check if we can use an 8.0 copy on 8.1 worth a shot as well but i'm almost positive it will not execute because of the "Windows cannot verify the digital signature of this application."
It would help if we could at least get cdb or WinDbg working on 8.1 even if we can't attach it to csrss.
I PMd netham45 about how he got cdb working on 8.1 but he has not replied yet. I've checked the WDK 8.1 release and everything is there even for arm except cdb.
Edit:
Also i'm working with Spazzarama over at EasyHook to see how he wrote his Patchguard disabler. If I can get unsigned code running even if it means we need to use a dev id just to start the jailbreak like the original version of nethams tool it would be worth it if it means we can disable patchguard. I have a few ideas on how to go about this, possibly creating a blank app and compile it. Then disassemble the exe with ildasm and replace the entry point with code that includes desktop code, then stitch it back up with ilasm (command line args allow arm code creation and toggling app containers, as long as the tools that create an app package don't test command line args it should work ok and be valid because it wont load any desktop dll's if they are not called i've tested this on normal environments. Then we might be able to get desktop code running that will allow us to disable patchguard, modify the value and then remove the app.
Lots of me rambling on about that, hopefully we get somewhere.
Click to expand...
Click to collapse
Have you tried the latest WinDBG that came with SDK 8.1? I'm using RT 8.0 so I cannot verify it, however it should work on RT 8.1 since it came with the 8.1 SDK
C\Program Files (x86)\Windows Kits\8.1\Debuggers\Redist
cdb is part of WinDBG
It's a flag passed to CreateProcess (presumably therefore also in NtCreateProcess), CREATE_PROTECTED_PROCESS. Only usable on binaries with a special Microsoft signature. It blocks most access to the process, causing an OpenProcess specifying those permissions to fail. http://msdn.microsoft.com/en-us/library/windows/desktop/ms684880(v=vs.85).aspx
EDIT: Creating a sideloadable app with desktop code is easy; we managed that over a year ago. The fancy/complex way of doing involves scanning the system libraries that are loaded into memory (using an allowed API, such as GetSystemTime() as a starting point) for the entry point of LoadLibrary, then calling that using a function pointer. The simple and straightforward way is to either modify the header files (which #ifdef out the relevant prototypes when compiling for WinRT) or just copy-paste those prototypes and definitions into our own headers, and then link against the relevant libraries (it's easy to extract .LIB files from DLLs). The latter approach has more initial time investment, and is probably easier to detect, but is "cleaner" (the source code looks exactly the same as would normally be used, aside from removing some checks in the headers) and slightly more performant on startup.
@LolitaPlus: The public debug tool downloads don't include ARM debugger binaries, so they won't run on RT...
They can debug ARM programs, but that's not sufficient for this purpose. Microsoft (and OEMs) have debugging tools that run on the devices directly, and they have leaked in the past; that's what's needed.
GoodDayToDie said:
It's a flag passed to CreateProcess (presumably therefore also in NtCreateProcess), CREATE_PROTECTED_PROCESS. Only usable on binaries with a special Microsoft signature. It blocks most access to the process, causing an OpenProcess specifying those permissions to fail. http://msdn.microsoft.com/en-us/library/windows/desktop/ms684880(v=vs.85).aspx
EDIT: Creating a sideloadable app with desktop code is easy; we managed that over a year ago. The fancy/complex way of doing involves scanning the system libraries that are loaded into memory (using an allowed API, such as GetSystemTime() as a starting point) for the entry point of LoadLibrary, then calling that using a function pointer. The simple and straightforward way is to either modify the header files (which #ifdef out the relevant prototypes when compiling for WinRT) or just copy-paste those prototypes and definitions into our own headers, and then link against the relevant libraries (it's easy to extract .LIB files from DLLs). The latter approach has more initial time investment, and is probably easier to detect, but is "cleaner" (the source code looks exactly the same as would normally be used, aside from removing some checks in the headers) and slightly more performant on startup.
Click to expand...
Click to collapse
Thats what i figured, for csrss, with the sideloadable app I was just wondering if it would be easier to do il modifications. But we are trying to get unsigned code anyway. Im home now and ill look into secpol.msc on my 8.1 tablet. It IS on my dev pc 8.1.
Edit:
Ok secpol.msc is available on my surface, and Debug programs is set to Administrators, what should I try modifying it to?
GoodDayToDie said:
@LolitaPlus: The public debug tool downloads don't include ARM debugger binaries, so they won't run on RT...
They can debug ARM programs, but that's not sufficient for this purpose. Microsoft (and OEMs) have debugging tools that run on the devices directly, and they have leaked in the past; that's what's needed.
Click to expand...
Click to collapse
I'm not talking about VS remote tools. I'm talking about WinDBG (version 6.3.xxxx, not the 6.2.xxxx) and it is on my Surface RT now.
Please correct me if you are not talking about this(WinDBG). If indeed that is what you want, give this link a try (I just uploaded it):
https://mega.co.nz/#!Rthz1aCC!chur33IsRLASnysWQOgNY9LJaeyv8oIsPaHDnwbuWCE

BlissOS on VirtualBox - Not working...

I've watched a tons of install videos on youtube and while the outdated buggy blissos11 running anroid9 works on virtualbox i can't get the latest one running.
Now i'm asking if the problem is on my end or blissos.
So, i got blissos15-android12l SUCCESSFULY INSTALLED but when i boot the os, nothing happens. What's going on?
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
It's stuck FOREVER.
It works in VMware for me, but fails in Vbox.
I toght virtualbox is better because it's minimalistic and has decent privacy standards over vmware, also vmware seems to be somewhat deeply integrated to the host OS, not the case with virtualbox, it's super light - only two services in taskmanager.
Seriously i saw someone on youtube getting blissOS 14/15 running in virtualbox but when i follow the same steps and it even says successfuly installed, it doesn't load the OS after booting, i'm clueless.
Both VMWare and VirtualBox is not officially supported by Bliss OS.
Why run Bliss OS in an 3rd-party emulator where Windows since some time offers Windows Subsystem for Android, what actually is Android 13 based?
Privacydroid said:
I toght virtualbox is better because it's minimalistic and has decent privacy standards over vmware, also vmware seems to be somewhat deeply integrated to the host OS, not the case with virtualbox, it's super leight - only two services in taskmanager.
Seriously i saw someone on youtube getting blissOS 14/15 running in virtualbox but when i follow the same steps and it even says successfuly installed, it doesn't load the OS after booting, i'm clueless.
Click to expand...
Click to collapse
VMware doesn‘t have privacy issues, and Virtualbox is by no means light. 2 processes in task manager means nothing (how much ram/cpu those processes use matters more).
I’m doing some testing with Blis in VBox and will get back to you.
For general use, as @jwoegerbauer said, WSA would be better (if you run windows 11 )
- Tejas
Windows 11? You must be joking, before touching that cancerous malware i'll switch to linux.
11 is utter garbage spyware, sure 10 is the same but 11 is even worse.
Has Windows become Spyware?
Has Windows become Spyware? Windows 11 vs XP Network Analysis on Wireshark. What websites does your new laptop secretly connect to? Get Crowdsec (free): https://www.crowdsec.net/?mtm_campaign=PCSecMag-May22 (sponsor) Buy the best antivirus: https://thepcsecuritychannel.com/best-antivirus Join...
yewtu.be
Privacydroid said:
Windows 11? You must be joking, before touching that cancerous malware i'll switch to linux.
11 is utter garbage spyware, sure 10 is the same but 11 is even worse.
Click to expand...
Click to collapse
AFAIK Malware, short for malicious software, refers to any intrusive software developed by cybercriminals (often called hackers) to damage or destroy computers and computer systems. Don't think Microsoft is doing so.
AFAIK Spyware collects personal and sensitive information that it sends to advertisers, data collection firms, or malicious actors for a profit. Attackers use it to track, steal, and sell user data, such as internet usage, credit card, and bank account details, or steal user credentials to spoof their identities. Don't think Microsoft is stealing an user's private data.
BTW:
Serious Windows users make use of O&O Shutup tool to configure behaviour of Windows OS with regards to unwanted actions.
jwoegerbauer said:
AFAIK Malware, short for malicious software, refers to any intrusive software developed by cybercriminals (often called hackers) to damage or destroy computers and computer systems. Don't think Microsoft is doing so.
AFAIK Spyware collects personal and sensitive information that it sends to advertisers, data collection firms, or malicious actors for a profit. Attackers use it to track, steal, and sell user data, such as internet usage, credit card, and bank account details, or steal user credentials to spoof their identities. Don't think Microsoft is stealing an user's private data.
BTW:
Serious Windows users make use of O&O Shutup tool to configure behaviour of Windows OS with regards to unwanted actions.
Click to expand...
Click to collapse
Honestly no offense but the reply you wrote is nothing but extremely dumb, dumb in these sense of seriously trashworthy.
Does microsoft meet the definition of malware? No. Did i mean that they are malware? No.
Is microsoft a disgusting company that should be ashamed of themselfes? Absolutely.
Is microsoft windows spyware and does it steal personal information? You don't think so? We are done here, no words. Stop replying let this thread die without saying anything more that hurts my brain.
@Privacydroid I know... I personally use Linux and Win11 in dualboot and still end up using Linux 90% of the time.
Microsoft is becoming more and more like an ad company, and I have to admit that (sadly). Not that win10 is any better than 11 (older versions of windows 10 were better though). The PC Security Channel compared XP to 11, cut comparing 10 to 11 shows that they collect approximately the same amount of data.
However, this thread has nothing to do with Windows. It's about Bliss OS. For me, VMware works. I'm trying to get it working with Virtualbox, and I'll tell you if I do. What version of windows (your screenshots imply windows) and Virtualbox are you using? Bliss 12.1 (12L) is considered experimental right now (keep that in mind too).
It will run (and freeze up at setup) in virtualbox if you go to without hardware acceleration (at bottom of list). (don't do this)
In VMWare, you need to enable EFI (go to the .vmx file and add the line
Code:
firmware = "efi"
before booting. Install it (make sure to set the CD and HD to SATA in the settings) and remember to disable HW acceleration (Advanced Options -> No Hardware Acceleration). It works (doesn't freeze like Vbox does).
traman124 said:
In VMWare, you need to enable EFI (go to the .vmx file and add the line
Code:
firmware = "efi"
before booting. Install it (make sure to set the CD and HD to SATA in the settings) and remember to disable HW acceleration (Advanced Options -> No Hardware Acceleration). It works (doesn't freeze like Vbox does).
Click to expand...
Click to collapse
I'd say microsoft windows isn't becomming an ad company, it already is.
It's the same trash like google android, facebook preinstalled - cannot be deleted but only deactivated which is not the same, i don't use facebook but these mentally drowned companys force it on anybodys phone without their consent.
And this is exactly what happens on windows aswell, when i tried windows 11 in virtualbox for the first time it had not only facebook preinstalled but also a whole lot's of other degenerated trash like tiktok. It's insane just how many connection windows makes directly after booting up the os, lucky privacy has evolved to such a degree where you can even use windows without any concerns over privacy, i've literally entirely blocked all microsoft connection to my personal computer.
Safing Portmaster - Easy Privacy
Portmaster is a free and open-source application that puts you back in charge over all your computer's network connections. Increase your privacy and security. Get peace of mind.
safing.io
I've tried using blissOS in virtualbox with hardware acceleration both on/off but it doesn't work either way.
I might check out vmware again, thanks for the info. Had my hopes up to get it running in vbox.
Edit: Windows 10 21H2, tried both blissOS 14 and 15, both fail.
ummm I just tested it, it works. You need to use the entry for no acceleration in the grub to boot. I'll send you a video soon. Also it didn't install for me when I used bios. (works with EFI)
traman124 said:
ummm I just tested it, it works. You need to use the entry for no acceleration in the grub to boot. I'll send you a video soon. Also it didn't install for me when I used bios. (works with EFI)
Click to expand...
Click to collapse
And how would you configure grub to not use acceleration? Guess i'll just wait for that video.
Oh and regarding windows, this is also great https://privacy.sexy
here's that video:
blissos.mp4
MP4 File
1drv.ms
be prepared for mediocre performance though
You can then add those parameters to the regular grub so you don't have to do that every time
Wondering why not
Dual Boot Bliss OS and Windows, Android 11 with Google Play Store​for example this one
Bliss OS 14.3 - Generic x86_64 - kernel-5.10.42 - 06.26.21
Works.. I just selected the vbox/vmware option...
@CXZa where did 6ou download that Bliss image?
@jwoegerbauer he's trying to run it on a VM, not dual boot.
traman124 said:
@CXZa where did 6ou download that Bliss image?
Click to expand...
Click to collapse
Bliss OS For PC
Open Source OS for PC's, based on AOSP
blissos.org

Virtual Machines on Android

One of the best features of Intel based MacBooks is the support for Bootcamp: Apple's own software that allows users to install Windows on MacBooks and use it as Dual Boot machines.
Unfortunately, this is no longer supported on the non-Intel Macs that run on Apple Silicon. Even more unfortunate is that Microsoft doesn't have any plans currently to support Windows on ARM.
The solution to this problem is to use Virtual Machines (VM)! Given the increased capabilities of hardware today, virtualization is handled well without lags or other problems. Virtual Machines allow running different operating systems on top of the currently booted system.
Android devices too have very capable hardware today. Can we not have a similar solution for Android?
This would be great for the following:
1. Users can run an older Android version if they like it more.
2. Users can install and use custom ROMs without unlocking their bootloader.
3. Users can install and run original ROMs of other brands and smartphone models.
4. Users can even install iOS and use it on an Android device.
5. Users can root their virtual machines and enjoy root without unlocking their bootloader.
6. No waiting time or hassles to get bootloader unlock codes as they would no longer be needed.
7. Users can continue using banking apps and other apps/ games that won't work in bootloader unlocked phones.
8. There is no risk of losing warranty or causing any damage to their phones.
9. The Virtual Machines (VMs) can be easily copied to other Android devices and run from there without losing data or setting everything up again.
I don't see discussions on this topic. Is this not possible?
Found this article:
Can You Run a Virtual Machine on a Smartphone? How Does It Work?
With smartphones increasingly becoming capable devices, did it ever cross your mind to run a virtual machine on them? Is it even possible? How?
www.makeuseof.com
Has anyone tried this?
TheMystic said:
Is this not possible?
Click to expand...
Click to collapse
Possible but theysimply dont care
TheMystic said:
2. Users can install and use custom ROMs without unlocking their bootloader.
3. Users can install and run original ROMs of other brands and smartphone models.
4. Users can root their virtual machines and enjoy root without unlocking their bootloader.
5. No waiting time or hassles to get bootloader unlock codes as they would no longer be needed.
Click to expand...
Click to collapse
Non-sense and impractical
TheMystic said:
One of the best features of Intel based MacBooks is the support for Bootcamp: Apple's own software that allows users to install Windows on MacBooks and use it as Dual Boot machines.
Click to expand...
Click to collapse
More like one of the best features of any x86 pc , you can boot window , linux , android , chrome os or whatever . Thats why x86 is miles ahead compared to arm
Guan Yu said:
Non-sense and impractical
Click to expand...
Click to collapse
Why so?
While this sort of use is pretty niche, but so is the entire segment of rooting and custom ROMs.
If smartphone hardware is capable, there are definitely plenty of advantages and zero risk. It will totally eliminate hardware issues for users and there won't be any boot-looping issues or bricking problems.
I have edited OP to include iOS too as a potential possibility.
GSIs & treble are the closest we can get for running custom ROMs on modern Android hardware.
You can always run ARM Linux on Android with Termux,
I believe there used to be a niche project which ran Android Lollipop on Android. However, it was very slow so it was not very popular.
Even if the Android Hardware is capable the base Android running the said hardware limits the execution.
That's why a BL unlock is required to access any specific Hardware feature which is blocked by software,
Obviously you aim too high, but basic virtual machines are always possible.
A starting point: https://github.com/limboemu/limbo
karandpr said:
GSIs & treble are the closest we can get for running custom ROMs on modern Android hardware.
You can always run ARM Linux on Android with Termux,
Click to expand...
Click to collapse
These are not VMs.
karandpr said:
I believe there used to be a niche project which ran Android Lollipop on Android. However, it was very slow so it was not very popular.
Click to expand...
Click to collapse
When was this?
I don't know the technical details of how VMs work on PCs. But I have tried all sorts of operating systems like Windows 7, Windows XP, macOS, several Linux distros on my 10 year old HP laptop that runs on Windows 11. They all run surprisingly well and smooth. Only macOS is a bit laggy on the machine, but is still quite usable.
karandpr said:
Even if the Android Hardware is capable the base Android running the said hardware limits the execution.
That's why a BL unlock is required to access any specific Hardware feature which is blocked by software,
Click to expand...
Click to collapse
Does Android block VMs from using the hardware directly?
It's been a while since I played around with these things, so not quite sure if I had to make any changes in the laptop recovery to make VMs work. Is this similar to unlocking bootloader on an Android phone?
SoundDrill said:
A starting point: https://github.com/limboemu/limbo
Click to expand...
Click to collapse
It appears this project currently doesn't support Android OS.
TheMystic said:
These are not VMs
Click to expand...
Click to collapse
In the end, the "emulator" will have to run a GSI on top of the device.
TheMystic said:
When was this?
Click to expand...
Click to collapse
2019 ish
TheMystic said:
I don't know the technical details of how VMs work on PCs. But I have tried all sorts of operating systems like Windows 7, Windows XP, macOS, several Linux distros on my 10 year old HP laptop that runs on Windows 11. They all run surprisingly well and smooth. Only macOS is a bit laggy on the machine, but is still quite usable.
Click to expand...
Click to collapse
x86 is way different than ARM ,
On Android phone, you cant even install ROM of a different variant of the device model, let alone install something from different device vendor.
TheMystic said:
Does Android block VMs from using the hardware directly?
It's been a while since I played around with these things, so not quite sure if I had to make any changes in the laptop recovery to make VMs work. Is this similar to unlocking bootloader on an Android phone
Click to expand...
Click to collapse
I mean, you need to allocate resources to a VM constantly. The power manager in Android wont like that.
TheMystic said:
It appears this project currently doesn't support Android OS.
Click to expand...
Click to collapse
Limbo supports AndroidOS.
karandpr said:
In the end, the "emulator" will have to run a GSI on top of the device.
Click to expand...
Click to collapse
Like a DSU?
V0latyle said:
Like a DSU?
Click to expand...
Click to collapse
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
karandpr said:
x86 is way different than ARM ,
On Android phone, you cant even install ROM of a different variant of the device model, let alone install something from different device vendor.
Click to expand...
Click to collapse
Sorry if my questions are too basic.
Is this a limitation of the platform (architecture) or is it purely how the OEM configured it? If it is the latter, then it is simply a question of removing the software imposed restrictions (which in turn may require the bootloader to be unlocked, unfortunately).
macOS isn't supposed to run on Windows hardware. But it does because the virtualization software (Virtual Box, VMware, etc.) makes the OS believe that the hardware is what it is designed to run on. Is this not possible on Android?
karandpr said:
I mean, you need to allocate resources to a VM constantly. The power manager in Android wont like that.
Click to expand...
Click to collapse
The virtualization software (or app) would run like any other app, isn't it? I don't think these apps would be as demanding on the hardware like some of the games are (e.g. Genshin Impact).
TheMystic said:
Sorry if my questions are too basic.
Is this a limitation of the platform (architecture) or is it purely how the OEM configured it? If it is the latter, then it is simply a question of removing the software imposed restrictions (which in turn may require the bootloader to be unlocked, unfortunately).
macOS isn't supposed to run on Windows hardware. But it does because the virtualization software (Virtual Box, VMware, etc.) makes the OS believe that the hardware is what it is designed to run on. Is this not possible on Android?
Click to expand...
Click to collapse
Because macOS can run on x86. For now atleast.
Once macOS pulls the plug on x86 (M1 is arm) like they did with PowerPC, they will stop to work on Windows.
Lets talk about M1 macs. IIRC, you cannot run x86 Windows on those macs. You will the ARM versions of Windows, which don't run lot of traditional windows software.
iOS runs only on Correlium which is state of art engineering.
TheMystic said:
The virtualization software (or app) would run like any other app, isn't it? I don't think these apps would be as demanding on the hardware like some of the games are (e.g. Genshin Impact).
Click to expand...
Click to collapse
It's like running PC game on PS3. PS3 had a powerful processor. Some researchers made a supercomputer with multiple PS3s.
But it simply cannot run a PC game.
Also the reason PS3 games don't work on PS5.
karandpr said:
Because macOS can run on x86. For now atleast.
Once macOS pulls the plug on x86 (M1 is arm) like they did with PowerPC, they will stop to work on Windows.
Lets talk about M1 macs. IIRC, you cannot run x86 Windows on those macs. You will the ARM versions of Windows, which don't run lot of traditional windows software.
iOS runs only on Correlium which is state of art engineering.
It's like running PC game on PS3. PS3 had a powerful processor. Some researchers made a supercomputer with multiple PS3s.
But it simply cannot run a PC game.
Also the reason PS3 games don't work on PS5.
Click to expand...
Click to collapse
You absolutely can run ps3 games on ps5. Whether it would run well is a different matter. Don't believe me? Run linux on the ps4 and use RPCS3.

Categories

Resources