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.
Related
So I tried out Android x86 for my PC. It works beautifully. I cannot boot it on my Surface Pro though... It seems like the Surface Pro was designed to only boot EFI boot loaders. Not BIOS boot loaders... I was wondering if somebody could lend a hand at helping me get past this issue. I really think Android x86 would be great for the Surface Pro, there are so many things I miss from my Nexus 7 but I don't want an Android device, if I could just dual boot it every now and then, I would be happy. Can someone please get the Android 4.2 x86 ISOs to boot via EFI? That would be appreciated.
sionicion said:
So I tried out Android x86 for my PC. It works beautifully. I cannot boot it on my Surface Pro though... It seems like the Surface Pro was designed to only boot EFI boot loaders. Not BIOS boot loaders... I was wondering if somebody could lend a hand at helping me get past this issue. I really think Android x86 would be great for the Surface Pro, there are so many things I miss from my Nexus 7 but I don't want an Android device, if I could just dual boot it every now and then, I would be happy. Can someone please get the Android 4.2 x86 ISOs to boot via EFI? That would be appreciated.
Click to expand...
Click to collapse
hmmm ... interesting you tried ...
and came out with a finding ...
following this thread on the possible development on this front ...
I've always dreamt of a Surface Pro on Android always ...
a reboot to Win7 for Work ... and back to Android !!!
going to be really very interesting ...
Hope the Android X86 team is peaking at this thread ...
Cheers!
Did you bother disabling secure boot?
Otherwise you can try "jar of beans" or "bluestacks" to run android applications for windows. There is a version of bluestacks which claims to be optimised for the surface pro, in reality its just bluestacks with proper windows 8 touch support.
SixSixSevenSeven said:
Did you bother disabling secure boot?
Otherwise you can try "jar of beans" or "bluestacks" to run android applications for windows. There is a version of bluestacks which claims to be optimised for the surface pro, in reality its just bluestacks with proper windows 8 touch support.
Click to expand...
Click to collapse
Of course I did, the problem is the Surface Pro's UEFI chip does not actually support booting BIOS-based bootloaders. It only boots EFI-based bootloaders like the Windows Boot Manager or Grub EFI, etc. Unless one was to emulate BIOS to boot Android, it needs a EFI bootloader to even boot it on the Surface Pro. Ubuntu boots fine on the Surface Pro, but it is booting from Grub EFI. I copied the Grub EFI file to my other flash drive, and Grub indeed boots. It is the trouble of getting Android x86 to boot because it isn't using a EFI-based bootloader.
Also, that wasn't the point. I want to run pure Android just for the experience of having Android right on my Surface so I don't miss having a Nexus 7. I tried it on my desktop PC and it runs beautifully, if only I could get it on my Surface...
Surface Pro comes with Windows 8 Pro and a CPU capable of second-level address translation. It is therefore capable of running Client Hyper-V, which is a hypervisor-based virtualization (rather than hosted VM) technology that allows you to run another OS in parallel with Windows. I believe it includes support for BIOS-based OSes. Perhaps you should try that?
GoodDayToDie said:
Surface Pro comes with Windows 8 Pro and a CPU capable of second-level address translation. It is therefore capable of running Client Hyper-V, which is a hypervisor-based virtualization (rather than hosted VM) technology that allows you to run another OS in parallel with Windows. I believe it includes support for BIOS-based OSes. Perhaps you should try that?
Click to expand...
Click to collapse
But what's the point in that? I don't want to virtualize. I want to run it natively... That's like saying hey use Bluestacks. I want Android running native on my Surface.
Anyway, guys I got it. Here it is.
First of all, running on a hypervisor is nothing like using Bluestacks. Android would then be running as "natively" as Windows at that point (Windows itself would also be running on the hypervisor), except that Windows would have first access to the display (Android would be able to use the graphics hardware nonetheless). When the virtual display was set to the Android machine, Android would be interacting with the input devices. As a plus side, you could switch back and forth rapidly...
That said, if you managed to get it working on bare metal, that's cool. Did you mean to include a link in your "Here it is "?
GoodDayToDie said:
First of all, running on a hypervisor is nothing like using Bluestacks. Android would then be running as "natively" as Windows at that point (Windows itself would also be running on the hypervisor), except that Windows would have first access to the display (Android would be able to use the graphics hardware nonetheless). When the virtual display was set to the Android machine, Android would be interacting with the input devices. As a plus side, you could switch back and forth rapidly...
That said, if you managed to get it working on bare metal, that's cool. Did you mean to include a link in your "Here it is "?
Click to expand...
Click to collapse
The tutorial is on the YouTube page. But the problem with the Hyper-V hypervisor is it uses that remote console. I only found it decent for running Windows with the guest drivers installed. Unless I'm just not executing it very well, Hyper-V isn't a good solution. Since VirtualBox is used much more in the Linux world, I would use that before using Hyper-V.
I'll investigate the virtual solutions though and let you know.
more recent linux kernel versions do support hyper-v, partly provided by microsoft believe it or not
I would assume that hyper-v support would carry over into android. Just a case of setting it up.
Worth trying. However, Android runs a somewhat customized kernel build that probably doesn't include a lot of the optional stuff such as the Hyper-V helpers. Of course, you could install the required kernel module for them...
SixSixSevenSeven said:
I would assume that hyper-v support would carry over into android. Just a case of setting it up.
Click to expand...
Click to collapse
I somewhat doubt the android platform itself has support for hyper-v.
Further, if you're looking to boot android directly would an android kernel and platform support booting via UEFI at all yet?
What partition would android be installed to? it likely wouldn't like being stuffed into an NTFS partition so you'd have to repartition the SSD and take some of the space from Windows, or boot android from an SDcard or USB memory stick.
EDIT: I see you did infact get it running, nice job, did you just use GRUB for a bootloader? did you have android run from the SSD or from elsewhere?
tbh if I had a surface pro I don't think i'd be installing android on it, slightly a waste.
by the way, a faster way of doing advanced reboot so you get the boot options is to hold shift and select the reboot option from the power menu.
So, after a short little flip around the web, I came across this
https://01.org/android-ia/downloads/2013/android-4.2.2r1-ia0
somehow.
I would love to have my Surface Pro dual-bootable between Android and Win8, but your tutorial has sort of overwhelmed me.
Are you using this code? Would it be better to?
Just wasn't sure where this development was going....
Purrsia said:
So, after a short little flip around the web, I came across this
https://01.org/android-ia/downloads/2013/android-4.2.2r1-ia0
somehow.
I would love to have my Surface Pro dual-bootable between Android and Win8, but your tutorial has sort of overwhelmed me.
Are you using this code? Would it be better to?
Just wasn't sure where this development was going....
Click to expand...
Click to collapse
You can try my guide in windows 8 development forums
Sent from my HTC One X+ using xda app-developers app
---------- Post added at 10:37 AM ---------- Previous post was at 10:36 AM ----------
feherneoh said:
Can't you add the lines which boot android-x86 into Ubuntu's GRUB? If it can be loaded, it could be used to load Android's kernel
Click to expand...
Click to collapse
Microsoft locked it, you can only use the stock bootloader for now
Sent from my HTC One X+ using xda app-developers app
rEFIit
Have you tried a rEFIit or rEFIitd? As the name subtly suggests, its a bootloader for EFI machines. I suggest having a look. I'm going to try this myself on a couple of machines tomorrow once I get to work. Good luck! Let me know how it turns out or if I lead someone down the right track!
rEFInd - An EFI boot manager utility: http://goo.gl/KRwzk
rEFIt: http://refit.sourceforge.net/
Agreed, Android on a Surface would be kick ass. Windows for work, Android for real life!
Hi Folks.....
Feeling a little nervous here seems I must have took a wrong turn somewhere to end up in the Microsoft Surface forum LOL.
Is anyone still wondering about this? I noticed the other day that the linux kernel 3.10 which is currently used by the android-x86 project has android efi drivers/patches which maybe what you require. I'd also have a poke around the Android-IA sources which is the official intel android open source project from what I recall there's more efiboot goodies in there.
As an extra bonus the 3.10 kernel also includes a patch for Binder which allows a 32bit userspace to function correctly with a 64bit PAE kernel which means "BIG RAM" so if you have more than 4 gig and a 64 bit processor you can get access to the full ram allocation, not quite the pure 64bit Android that I want but it'll do for now while I figure out the finer points of x86_64 assembly language.
If Anyone wants/needs a kernel rattling off with these options enabled just let me know and i'll well rattle one off!
Thanks
trevd said:
Hi Folks.....
...I noticed the other day that the linux kernel 3.10 which is currently used by the android-x86 project has android efi drivers/patches which maybe what you require. I'd also have a poke around the Android-IA sources which is the official intel android open source project from what I recall there's more efiboot goodies in there.
As an extra bonus the 3.10 kernel also includes a patch for Binder which allows a 32bit userspace to function correctly with a 64bit PAE kernel which means "BIG RAM" so if you have more than 4 gig and a 64 bit processor you can get access to the full ram allocation, not quite the pure 64bit Android that I want but it'll do for now while I figure out the finer points of x86_64 assembly language.
If Anyone wants/needs a kernel rattling off with these options enabled just let me know and i'll well rattle one off!
Thanks
Click to expand...
Click to collapse
If the offer still stands, I would be interested in this (..or even just a how-to).
I have a multiboot system with PCLinuxOS, Ubuntu, and Win8.1 running right now, and I can get the recent 4.4rc1 release from android x86 to boot if I switch to legacy bios and use legacy grub from PCLinuxOS or the android_x86 thumbdrive, but I cannot get it to boot from Ubuntu's EFI capable Grub2 (..d/t kernel panic). On my Acer m5-583p it works great in legacy mode (wifi, touchscreen, keyboard, etc), but I would like to be able to use an EFI bootloader so that I don't have to change to/from legacy/efi before selecting the OS at boot.
Thanks! :good:
I posted this in the Desktop Apps Ported To... thread and it was recommended that I take this topic to its own discussion.
I stumbled across this the other day and found it quite interesting.
WinKexec
https://www.jstump.com/projects/kexec/wiki
Basically a Windows Kexec port wrapped up in a driver. I'm waaay out of my league here, but it would seem like it should be possible to port this driver to RT and install it since we now have kernel mode access in the most recent Jailbreak.
The idea of kexec in RT was tossed around earlier in some threads but never really go off the ground. Perhaps porting an existing Windows driver would be easier.
Thoughts?
I have not looked into sources, but I really think that the process is too x86-specific. I don't think that ARM HAL uses HalReturnToFirmware function as we have UEFI, not BIOS, and so on.
The same can be done for RT too, and even much easier. Just make a driver that would flush the disk cache, and then run the Haret code that was used to turn off MMU and boot Linux on Windows Mobile devices. Probably the code should be modified for newest ARM CPUs (at least to shut down the second and other cores), but this should not be too difficult.
mamaich said:
I have not looked into sources, but I really think that the process is too x86-specific. I don't think that ARM HAL uses HalReturnToFirmware function as we have UEFI, not BIOS, and so on.
The same can be done for RT too, and even much easier. Just make a driver that would flush the disk cache, and then run the Haret code that was used to turn off MMU and boot Linux on Windows Mobile devices. Probably the code should be modified for newest ARM CPUs (at least to shut down the second and other cores), but this should not be too difficult.
Click to expand...
Click to collapse
Reading the implementation doc, probably some of the steps are still the right idea, if they have Windows RT equivalents. It's using the kernel to halt the other CPU cores (definitely a good idea) and then finally executing the boot. I imagine having a kernel driver via our jailbreak is the right way to go in any case (whether or not it's "this" kernel driver) because we pretty much need to do the basic concept of halting everything Windows is doing and overwriting it (in memory) with a new bootloader binary.
Why would RT not use HalReturnToFirmware? First of all, a lot of x86 Windows installs are on UEFI these days. It's almost impossible to find a new motherboard with BIOS, in fact (though many will emulate it on top of UEFI). Second, what do you think the "F" in UEFI stands for? RT certainly does have HAL as well.
In any case, there is *some* function that implements the "OK, kernel is done, turn everything off at the hardware level now" functionality. It might not be called HalReturnToFirmware on RT (though it probably is), but I guarantee you it exists.
GoodDayToDie said:
Why would RT not use HalReturnToFirmware?
Click to expand...
Click to collapse
There just may be no sense in it. As RT does not need to implement lots of legacy BIOS interactions and directly call UEFI interfaces when needed, like HalEfiResetSystem. But this is just my guess, I have not looked into the HAL disasm for a long time.
Anyway I've already wrote how loading Linux could be done from a driver without patching the HAL in RAM by reusing the old Haret code. You are in kernel mode in your driver - so you can really do anyting.
Boot from SD card
This is a placeholder for some work I was doing on booting and alternate copy of Windows RT from SD card
by adding extra entries in the bcd store and a ‘copy’ of windows on the SD card
(or a reinstalled version of Windows RT installed onto the SD card)
Note it actually still boots from the system partition on the internal flash but tries to boot an alternate Windows installation from \windows on the SD card
However having problems getting it to find the SD card volume at boot time
Still working on that
and on how to use the recovery environment to install the OS onto SD card
Best to have a Class 10 SD card
But now moved on to dual booting Windows RT and RT 8.1 (both from internal flash)
http://forum.xda-developers.com/showthread.php?p=43062190#post43062190
Also working on booting a full OS from USB stick
That'd be quite cool. It'd also be an important part of a Linux or Android port to Surface RT. You could make an extremely-stripped-down Windows RT installation that boots just enough to run some exploit automatically. The exploit could load a kernel driver to do the equivalent of kexec() into Linux.
Such an installation on a USB stick could be a bootable Linux live "CD" as well.
Myriachan said:
That'd be quite cool. It'd also be an important part of a Linux or Android port to Surface RT. You could make an extremely-stripped-down Windows RT installation that boots just enough to run some exploit automatically. The exploit could load a kernel driver to do the equivalent of kexec() into Linux.
Such an installation on a USB stick could be a bootable Linux live "CD" as well.
Click to expand...
Click to collapse
Someone just needs to actually come up with that exploit first. I'd totally convert my surface to a Linux device if it was available ... Windows is nice and all, but I love that warm, fuzzy feeling of having full control of hardware I own. I got CyanogenMod on just about every Android device I have, and getting out of the restricted RT arena would be awesome.
southbird said:
Someone just needs to actually come up with that exploit first. I'd totally convert my surface to a Linux device if it was available ... Windows is nice and all, but I love that warm, fuzzy feeling of having full control of hardware I own. I got CyanogenMod on just about every Android device I have, and getting out of the restricted RT arena would be awesome.
Click to expand...
Click to collapse
The general idea behind netham45's exploit (which originates with a Google guy) would actually work for this. If you control the entire boot image, you can make cmd.exe start a script and cdb very early. There exists a modification to the technique to do the exploit without the two-minute instability problem.
If Microsoft doesn't lock out the 8.0 bootarm.efi, this would keep working after 8.1's release--just boot 8.0 to do this part.
The difficult part of this entire thing to me is how the hell to write Linux drivers for hardware we know nothing about.
Myriachan said:
The general idea behind netham45's exploit (which originates with a Google guy) would actually work for this. If you control the entire boot image, you can make cmd.exe start a script and cdb very early. There exists a modification to the technique to do the exploit without the two-minute instability problem.
If Microsoft doesn't lock out the 8.0 bootarm.efi, this would keep working after 8.1's release--just boot 8.0 to do this part.
The difficult part of this entire thing to me is how the hell to write Linux drivers for hardware we know nothing about.
Click to expand...
Click to collapse
Linux for tegra might be a start, think that is now upto tegra 3 specs. But there are still several unknowns like you say. Some disassembly might clear up a few more unknowns (is the screen DSI or LDVS, which interface is used for the storage as there is more than one which would be capable for eMMc usage).
We do know that all the sensors are i2c devices at least.
But yeah, there is alot of work for a community to do in order to port linux to the surface. Not unless microsoft release a few datasheets which they have no reason to. Making matters worse, not all RT devices would be the same so the surface RT would need a different port than dells qualcomm based tablet. Even the tegra based tablets might need a different BSP to each other.
I do think though that if there was linux on the surface RT then I would probably consider getting one. Would at least double the chances at any rate.
SixSixSevenSeven said:
Linux for tegra might be a start, think that is now upto tegra 3 specs. But there are still several unknowns like you say. Some disassembly might clear up a few more unknowns (is the screen DSI or LDVS, which interface is used for the storage as there is more than one which would be capable for eMMc usage).
We do know that all the sensors are i2c devices at least.
But yeah, there is alot of work for a community to do in order to port linux to the surface. Not unless microsoft release a few datasheets which they have no reason to. Making matters worse, not all RT devices would be the same so the surface RT would need a different port than dells qualcomm based tablet. Even the tegra based tablets might need a different BSP to each other.
I do think though that if there was linux on the surface RT then I would probably consider getting one. Would at least double the chances at any rate.
Click to expand...
Click to collapse
I'd imagine focusing on one at a time would keep you from getting overwhelmed, and I would think the stock Microsoft Surface RT is the one that makes the most sense to start with, at least get a proof of concept working. As far as "hardware we know nothing about", the Tegra itself is pretty well documented and I imagine it operates essentially the same as it does anywhere else.
I would imagine stages to doing this:
1) Figure out the exact sequence to stop Windows and disengage the kernel, watchdogs, or whatever else in a stable way to start executing arbitrary code in RAM, with some kind of POC demo, e.g. getting data out over I2C or something, which we ultimately will need to debug a kernel.
2) Once this has been accomplished, start playing with ARM-based Linux bootloaders, with console output happening over I2C or whatever else works. This can allow for just trying to get the kernel to run, even if at first this renders a completely non-interactive device.
3) If you get this far, obviously now it's all about getting the magic mix of drivers...
With an actual kernel running, most likely a lot of hardware would become more easily identifiable, and we could at least figure out where we stand. Of all these things, I imagine #1 is the most difficult to overcome, but there's been some suggestions.
southbird said:
2) Once this has been accomplished, start playing with ARM-based Linux bootloaders, with console output happening over I2C or whatever else works. This can allow for just trying to get the kernel to run, even if at first this renders a completely non-interactive device..
Click to expand...
Click to collapse
I dont think anyone knows the exact pinout but there is i2c on the connector for the touch/type covers, they are themselves i2c devices. If someone knew the pinout, theres your access. Stick some magnets on some card with a few pieces of wire sticking out of it, should be able to hold against the connector. But that doesnt matter so much.
I've heard of linux consoles being accessed over UART (infact I have done this with a raspberry pi) but not i2c. The tegra does have at least 1 UART though (I have a feeling it might have 3 or 4). Whehter you would have to tear a surface apart to get at it though is another matter. I know that several devices actually make the uart externally accessibly via either the USB or audio jacks with a quick pinmux. A nexus 4 for example you stick a certain resistor between the mic and ground channels on its audio jack and I think the left audio channel becomes Tx and right Rx or vice versa. A few android tablets (I think HTC are big on this) use the microUSB, certain resistor value between the sensor and ground lines as is often used for enabling USB host triggers D+ and D- to become Tx and Rx instead. No microUSB on the surface though. My guess if they ran one externally it would either be on the cover connector (there are 5 connected contacts yet only worked out a purpose for 4 of them, then there is 1 pin not connected to anything for some reason, probably future expansion, perhaps this 5th pin enables a UART instead of i2c???) or the audio jack, there might well not be one accessible externally at all :/
I would assume the surface screen is either LDVS or DSI, the prior is more likely to be documented than the latter (DSI isnt even fully standardised, in theory it is but in practise DSI devices are rarely compatible even with the same res, colour depth etc). May well be possible to output direct to that initially.
With the keyboard being i2c it may well be possible to write a driver to use it on linux on an existing device, not sure how well USB-i2c adaptors work but the pi has 2 native i2c buses.
I do agree that the surface is the logical starting point. Its probably sold the most units at any rate and is the first thing people think of when you say windows RT. Other tegra devices would be the most logical to follow on with, qualcomm would perhaps be able to reuse step 1 but step 2 you would likely have to start from scratch all over :/
Oh well, 1 hurdle at a time. Honestly though, the existance of a functioning linux port for the surface would make me tempted to buy one. That or microsoft unlocking RT to literally be windows 8 on ARM not windows 8 stuck in a cage.
southbird said:
1) Figure out the exact sequence to stop Windows and disengage the kernel, watchdogs, or whatever else in a stable way to start executing arbitrary code in RAM, with some kind of POC demo, e.g. getting data out over I2C or something, which we ultimately will need to debug a kernel.
Click to expand...
Click to collapse
There is already a method of running any unsigned EFI file (for example a GRUB loader). But it works only on Asus tablets and requires USB stick inserted on boot and Bitlocker turned off in Windows (as the "trusted boot environment" is broken). I'll publish it later - probably after 8.1 official release, as it can be easily closed by Asus in a next firmware update that may be required for 8.1.
So I know pretty much how my jailbreak is going to work from end to end, except with regard to PatchGuard. I don't need to burn my "Holy Grail" exploit in order to release a jailbreak, but it means that I have to deal with PatchGuard.
In Windows 8.1, Microsoft modified the kernel and ci.dll so that PatchGuard protects the signing enforcement mode variables. This means that if you modify the variables that were modified by 8.0's jailbreak, some random time in the next hour from that point, your system will bugcheck (bluescreen) because PatchGuard detected something tampering with the kernel. It is very obvious that the addition of these variables to PatchGuard's protected list was a deliberate attack against the RT jailbreak, because there is little other reason to care about enforcing these variables' integrity after startup.
I need to get around PatchGuard somehow. PatchGuard itself is designed to be an obfuscated mess, deliberately difficult to modify in a stable manner. It does a lot of nasty tricks, things that you would typically find in copy protection systems. Obviously, disabling it would be nice, but quite difficult. So is stopping it from bugchecking.
I can load kernel drivers, so I know of a way in which I can hook parts of the system that would not anger PatchGuard such that arbitrary unsigned DLLs and drivers could be loaded without hassle. For things like the lockdown in WinDbg, VBScript and PowerShell, I can hook NtQuerySystemInformation in the user-mode ntdll.dll and intercept the request to check the lockdown setting. Even though the system lockdown state would still be active, as long as user mode programs don't know about it, it won't be enforced. (The kernel doesn't care at all.)
However, this leaves one thing to be desired: executing ARM code. I already know how we can patch the kernel so that ARM code can execute without the CPU being switched back to Thumb2 all the time. However, patching the kernel definitely will get PatchGuard's attention, so there's no way to pull that off without defeating PatchGuard.
The optimal solution is definitely to defeat PatchGuard, but I don't know how. I'm not an expert in the field of low-level NT kernel stuff.
please release your jailbreak so that other people can help you.
If i got it correctly, it will BSOD in a hour of running, so releasing it to public is not a good idea. Maybe via PM to other devs, but that depends on OP.
why not change the variables back after you launch your unsigned exe?
windowsrtc said:
why not change the variables back after you launch your unsigned exe?
Click to expand...
Click to collapse
I think about doing this too. Can we discard hacked? If it can done. Will it have problem with running unsigned exe? And did we know exactly when did PatchGuard notice about hack?
Myriachan said:
However, this leaves one thing to be desired: executing ARM code.
Click to expand...
Click to collapse
Perhaps I'm missing something, ... why do you want to do this? The reason I ask is because this seems to be your motivation for wanting to "defeat" patch guard.
WRT simply running native applications/driver - If you can successfully load a driver, even once, then there are a few easy ways to support this without a patch guard defeat.
Cheers!
bfosterjr said:
Perhaps I'm missing something, ... why do you want to do this? The reason I ask is because this seems to be your motivation for wanting to "defeat" patch guard.
WRT simply running native applications/driver - If you can successfully load a driver, even once, then there are a few easy ways to support this without a patch guard defeat.
Click to expand...
Click to collapse
That it's currently impossible to execute ARM code reliably on Windows RT is a major reason that Firefox hasn't been ported. Fixing that would require patching two context-switch routines in ntoskrnl.exe.
You're right that there are various ways of loading unsigned executables and drivers once the initial driver is bootstrapped. ci.dll and ntoskrnl.exe have so many variables that aren't protected by PatchGuard that this is pretty much inevitable. Ironically, removing the lockdown from WinDbg, PowerShell and VBScript is actually harder than running unsigned code when using this attack.
Defeating PatchGuard would be the optimal experience for users.
...
...
Myriachan said:
That it's currently impossible to execute ARM code reliably on Windows RT is a major reason that Firefox hasn't been ported.
Click to expand...
Click to collapse
Actually, I don't agree. There is no hard requirement for ARM code that I can see. The major reason for a lack of FF port is that the native RT community is too small to get behind the port to sort out re-writing parts of the code base. There is also the large build system/process that needs to be shifted to VS. Throw in the lack of a public RT 8.1 JB.. and there is little motivation for this community to invest the time/effort in making FF work.
Don't get me wrong, FF will likely come to RT (even 8.1) eventually.. but I don't see the lack of ARM code being the roadblock. Its time and effort along with a new JB.
bfosterjr said:
Actually, I don't agree. There is no hard requirement for ARM code that I can see. The major reason for a lack of FF port is that the native RT community is too small to get behind the port to sort out re-writing parts of the code base. There is also the large build system/process that needs to be shifted to VS. Throw in the lack of a public RT 8.1 JB.. and there is little motivation for this community to invest the time/effort in making FF work.
Don't get me wrong, FF will likely come to RT (even 8.1) eventually.. but I don't see the lack of ARM code being the roadblock. Its time and effort along with a new JB.
Click to expand...
Click to collapse
The javascript JIT engine is to ARMv7 not THUMB_2 though.
SixSixSevenSeven said:
The javascript JIT engine is to ARMv7 not THUMB_2 though.
Click to expand...
Click to collapse
I gathered as much. I'm suggesting a re-write of that as part of the port.
Cheers!
Possible, but not easy. The result would likely be significantly less efficient... but better than no JIT at all. It substantially increases the effort required for porting, though.
As for PatchGuard... I don't know as much about it as I'd like, but the fact that it only checks periodically suggests something that we can anticipate and head off, assuming we can get our own drivers loaded... hmm. This is a pretty "out there" solution, but is there any chance that the version of PG from RT8.0 could be substituted in? That may assume a greater degree of encapsulation of PG functionality than is actually warranted, but it does seem to me that, if we can't modify it, we might be able to just replace (or possibly remove) it. Another option: rather than modifying the value itself, modify the code that checks it? I mean, if they were smart, that's under PG as well, but it *might* not be. Either bypassing the check for the values, or the signature check, or just spoofing the signature check, or taking it a level even further and replacing the whole loader function with a clone that lacks the check (which allows the original to remain intact, aside from however the shim is injected).
Any which way, a lot of binary RE... ick, but that's life.
A few ideas:
1) Put a memory read breakpoint on the memory addresses you wish to change, check the context reading it and change it to what it should be if it's PatchGuard, and what you want if it's not.
2) Hook BugCheck to make it just return if PatchGuard calls it (I seem to recall reading something about PG wiping the stack/any context before calling BugCheck, so this may not work)
3) Forcibly enable Debug mode VIA setting the required kernel flag/calling the proper function (kdStartDebugger? something like that; I had found it at one point) to enable the debugger. I have no idea if PG will sense this on pre-existing threads or not, but if it does then it should shut itself down.
4) Check if THIS approach works in 8.1 (I suspect not, since it was published for 8.0 previews)
5) (This would work for g_ciOptions, but not patching the interrupt handlers), hook the usermode function that queries the state of the signing, make it call a driver that changes the bit back, check, then call the driver to set it to default again. You would only get a BSoD if you were really unlucky and PatchGuard happened to run during the 30ms that the flag was changed.
I'd like to play with some of these ideas, but without access to the current prototype (hint hint), and not having a PC I want to upgrade to 8.1 right now, it's difficult.
netham45 said:
A few ideas:
1) Put a memory read breakpoint on the memory addresses you wish to change, check the context reading it and change it to what it should be if it's PatchGuard, and what you want if it's not.
2) Hook BugCheck to make it just return if PatchGuard calls it (I seem to recall reading something about PG wiping the stack/any context before calling BugCheck, so this may not work)
3) Forcibly enable Debug mode VIA setting the required kernel flag/calling the proper function (kdStartDebugger? something like that; I had found it at one point) to enable the debugger. I have no idea if PG will sense this on pre-existing threads or not, but if it does then it should shut itself down.
4) Check if THIS approach works in 8.1 (I suspect not, since it was published for 8.0 previews)
5) (This would work for g_ciOptions, but not patching the interrupt handlers), hook the usermode function that queries the state of the signing, make it call a driver that changes the bit back, check, then call the driver to set it to default again. You would only get a BSoD if you were really unlucky and PatchGuard happened to run during the 30ms that the flag was changed.
I'd like to play with some of these ideas, but without access to the current prototype (hint hint), and not having a PC I want to upgrade to 8.1 right now, it's difficult.
Click to expand...
Click to collapse
1. You can't set a read breakpoint because PatchGuard is also checking the contents of the interrupt vectors/registers. It would notice that someone is using the hardware breakpoints before it tried to read kernel memory.
2. Yes, PatchGuard overwrites KeBugCheckEx with a pristine copy among other tricks.
3. PatchGuard knows that the debugger was not enabled at boot, and will not allow it to be enabled. It will bugcheck if you try to enable it.
4. It's possible that the approach where you look for the self-decryption code at the beginning of the DPC handlers would work.
5. There is a better way, closely related to how I'm writing my installation program, to allow unsigned PEs to load. It would escape PatchGuard's notice. A user-mode hook would be required in order to neuter wldp.dll, though, since ntoskrnl.exe would still tell programs that the current policy was locked down.
I think I can do everything I need to do except execute ARM code reliably without harassing PatchGuard.
Melissa
As a plain user, I have a question:
Why do we have to use ARM Instruction Set? Isn't just Thumb-2 okay? I thought other part of Windows all runs with Thumb-2 fine.
sahack said:
As a plain user, I have a question:
Why do we have to use ARM Instruction Set? Isn't just Thumb-2 okay? I thought other part of Windows all runs with Thumb-2 fine.
Click to expand...
Click to collapse
There is a lot of software that we would like to port over that is written in arm assembly. We would have to rewrite it to THUMB-2 to use it on Windows RT, though. Porting software is (relatively) easy, rewriting it is difficult.
sahack said:
As a plain user, I have a question:
Why do we have to use ARM Instruction Set? Isn't just Thumb-2 okay? I thought other part of Windows all runs with Thumb-2 fine.
Click to expand...
Click to collapse
Common one that needs the ARM instruction set would be a javascript engine. V8 which is the javascript JIT used in chrome only has x86 and ARMv7 versions available, it doesn't have a THUMB_2 version. Although V8 itself can compile for THUMB2, that is only the JIT'er itself, it will only ever JIT to the full instruction set. So to port chrome we wouldnt be able to use V8, there might be a way to get it to compile using the windows javascript engine (which is slower than V8 but perfectly fine) or something but its still a significant obstacle.
The same applies to quite a few other softwares.
Then as netham says, we have software written in arm assembly which people have requested, thats great but it takes alot of effort to rewrite it in thumb2 assembly.
If you have software which can indeed compile for thumb2 and function on thumb2, yeah thats great. But there is some which doesnt.
netham45 said:
There is a lot of software that we would like to port over that is written in arm assembly. We would have to rewrite it to THUMB-2 to use it on Windows RT, though. Porting software is (relatively) easy, rewriting it is difficult.
Click to expand...
Click to collapse
Okay... I used to think that only JIT compilers and media decoders needed that...
But that gives another question.... Were we able to let the CPU stay in ARM mode in Windows RT 8.0?
(And if PatchGuard checks periodically, is it possible to just reset its timer once in a while?)
sahack said:
Okay... I used to think that only JIT compilers and media decoders needed that...
But that gives another question.... Were we able to let the CPU stay in ARM mode in Windows RT 8.0?
(And if PatchGuard checks periodically, is it possible to just reset its timer once in a while?)
Click to expand...
Click to collapse
First question, no.
Second question, thats what the thread is discussing although your suggestion is perhaps worth a look into (if myriachan hasnt already)
SixSixSevenSeven said:
First question, no.
Second question, thats what the thread is discussing although your suggestion is perhaps worth a look into (if myriachan hasnt already)
Click to expand...
Click to collapse
Sure, you could reset the timer on PatchGuard continuously, if you can find all its timers and perfectly distinguish them from those that were created by legitimate drivers. That's the harder part, unfortunately. =/
Asking this question because the attempt to get TWRP on my device is becoming a compound problem as the distance to being able to build it approaches 1. Otherwise known as the law of inverse noobness: Hindsight is always 20/20. Personally, not even half way to 1 in being able to do this, as am fairly new to doing things at the operating system level of programming. Not brand-new though, and knowing how and where to look things up helps, so if you have hints or can point me in the right direction that'd be great. First question is sort of along the lines of "how do you setup your dev environment" if you want to make it modular? More precisely:
So right now, the build page for AOSP concerning my device says to use Ubuntu 14.04 and do all those things to set it up for that. Do I need to do that in order to get TWRP built for my device? To have it set up the same way as the AOSP advises? Having a different computer for each dev environment would be a bit much, but running them in qemu seems even more ridiculous. Perhaps a better idea is to set up a "build environment" on bootable USB sticks that do all the work? That would simply a lot of things, like not having to swap out hard drives, and being able to easily clone a USB drive to "just work" and build AOSP/TWRP at will on any computer.
For reference, it is the Moto G Power (2021) "Sofia" device. They've released sources for it, but not much development going on. So learning how to do this for my device might just unlock TWRP (and with it, probably the Nethunter kernel/chroot environment) for other devices not yet supported.
Help me, help you. Thanks.
(Have other questions, too).
Why not use WSL2?
How to install Linux WSL2 on Windows 10 and Windows 11
The latest version of the Windows Subsystem for Linux is a significant upgrade; for most, it's now easier than ever to install.
www.windowscentral.com
jwoegerbauer said:
Why not use WSL2?
Click to expand...
Click to collapse
I don't use windows.
Bump.
Asking this because it seems that, being new to programming and having no formal training, I'm missing something from tutorials (like the TWRP git page, or some of the tutorials here on this forum that haven't been updated since 2013) and other material that might be thought to be "known" or "implied" and I just can't seem to understand what. Because when I go to build projects or whatever, following tutorials to the letter, still end up with errors and other problems that aren't covered in the tutorial. Part of that problem is installing dependencies, and then having them conflict with other installed things, like having two of python and three versions of java. So having a "build environment" to prevent conflicts is something that wasn't taught, but learned through trial and error, but that isn't the only problem I'm having.
McChadwicke said:
For reference, it is the Moto G Power (2021) "Sofia" device.
Click to expand...
Click to collapse
Hmm. I have the same model, but it's "borneo".
Did you build TWRP for your device? Any pointers or tips?
I usually just modify stock recovery to have rooted, permissive ADB.
I really don't need more than that in a recovery.
I haven't done much with my GP21 since the Firehose loader is restricted.
Renate said:
I usually just modify stock recovery to have rooted, permissive ADB.
I really don't need more than that in a recovery.
I haven't done much with my GP21 since the Firehose loader is restricted.
Click to expand...
Click to collapse
Not sure why the last reply didn't quote you...
Setting up a build environment is an evolving problem. As of this writing it seems the Ubuntu team is switching to a "pro version" system, a paywall, for some services...
Also, AOSP recommends Ubuntu 14 for a build environment. Gave up trying to run it from USBs lol, it is running on a dedicated system. But android-sdk is no longer available in apt, while running Ubuntu 14.04 + latest updates? So went to check why and now AOSP is using its own system for build environment setup and management. Tried running it in Ubuntu 14, but gave errors with the setup script provided.
Seeing now if I can't get the android sdk to run in Mint-XFCE... Will check back. TWRP build page says I need these things to build it (TWRP), right?
Also, how much of the preinstalled vendor crud can be pruned before it breaks?
Thanks.
Edit: reference on the TWRP guide I'm using is https://forum.xda-developers.com/t/...ompile-twrp-from-source-step-by-step.3404024/ (posted 2016)
I think that all build environments are getting more restricted.
"Just do it OUR way" seems to be the new corporate slogan.
I build Android apps without Android Studio, Gradle or an IDE.
Renate said:
I think that all build environments are getting more restricted.
"Just do it OUR way" seems to be the new corporate slogan.
I build Android apps without Android Studio, Gradle or an IDE.
Click to expand...
Click to collapse
Does TWRP have its own build control system? Considering all these changes, should it?
To keep things isolated, clean and manageable on host system, that has no dev tools
or anything extra besides standard desktop stuff. (under main linux distros)
#1 For smallest , fastest deployment of various build/dev environments i use schroot
on devuan/debian , it is a system to manage/automate the use of chrootable containers.
like regular manual chroot but most thigs are automated/preconfigured with
just a few commands and config files.
Basicaly a new root filesystem (userspace) that is independent of hosts root filesystem and just
uses hosts kernel (or as much/little acces to kernel as you give it trough schroot config files)
has its own packages and dependencies and will only see specific sections of hosts filesystem sections you give it access to like say /src/myproject from host. can be a separate /home
or shared with host, all depends on your config.
Using debootstrap to create the filesystems for containers of specific distributions/verions.
Or can just manualy copy an install and rip out the kernel etc...
(Can install ubuntu userspace in debian with debootstrap , if need be.)
(like lineageOS was hard to find all the correct/matching dev tools under devuan, so ubuntu it was)
#2 For something a bit beefier LXC on top of libvirt.
(regular chroot wont run services, or have its own networking , LXCs can , with some extra configuration)
#3 For when you just need an actual full blown VM os installation use KVM/qemu on top of libvirt .
(like installing 15 year old redhat 5.1 in a container wont work, kernels and main libs too far apart)
(or anything that is just too different from current linux kernel , other OS s etc...)
virt-manager is nice for graphicaly managing VMs and LXCs
#1 But schroot is essential and will suffice for more then 90% if not whole 100% of your needs.
if you want a clean host system from being clobbered by constant installing and testing and such . Keeps the environment contained in its own filesystem namespace , have as many as you need .
start fresh,rollback,clone etc.............
Once configured just start another tab in a terminal emulator and schroot in to the container
and your main host system in unaffected, always clean .
#4 Running all of this on top of ZFS takes it a step up, to the next level of effeciency.
zfs helps quite a bit with cloning,branching,snapshots, rollbacks but not essential,
like git versioning for things that are too big for or are not made for git management
(but is another system on to itself to learn, so ignore it if new to linux )
just cloning a 300Mb-1Gb base bootstrap install folder takes no time on regular filesystem on ssds .
With these 3 tools , you can have 10s if not 100s of different environments on a single host
quickly deployable once you get to know the procedures. all usable at the same time without
reboot,
#5 The most important is learning how to hunt for the right version of tools and all of the
dependencies and the correct versions of those , as each project will have their own
and will base it on their own distribution of choice at a specific point in time.
(by being able to install/test/restart in container makes this whole process , easier)
you can test many different ideas at the same time , and merge what works in
to your own dev-build-env for a specific project.
(like hunting down correct tutorial for specific/old/obscure phone and a rom and recovery
and rooting tools associate from a time long past. using wayback machine to source
correct versions of each , as normal web has erased them )
even used schroot to install games for nephew from untrusted sources without hesitation,
and just delete the container when done, but that was a bit more involved as proprietary
nvidia drivers had to be installed on host and partially in containers.
dandudikof said:
To keep things isolated, clean and manageable on host system, that has no dev tools
or anything extra besides standard desktop stuff. (under main linux distros)
#1 For smallest , fastest deployment of various build/dev environments i use schroot
on devuan/debian , it is a system to manage/automate the use of chrootable containers.
like regular manual chroot but most thigs are automated/preconfigured with
just a few commands and config files.
(like hunting down correct tutorial for specific/old/obscure phone and a rom and recovery
and rooting tools associate from a time long past. using wayback machine to source
correct versions of each , as normal web has erased them )
Click to expand...
Click to collapse
neat. schroot looks like a solution. answers a lot of questions, anyway. that last part scares me though. using the wayback machine to source things jeez. there's gotta be a better way, but probably not unless i want to do it myself which will only add time to "the project".
McChadwicke said:
neat. schroot looks like a solution. answers a lot of questions, anyway. that last part scares me though. using the wayback machine to source things jeez. there's gotta be a better way, but probably not unless i want to do it myself which will only add time to "the project".
Click to expand...
Click to collapse
That was just worse case scenario if you get in to very obsolete/old/abandoned stuff (10-20 year old) projects/hardware etc...
dandudikof said:
10-20 year old
Click to expand...
Click to collapse
yeah some of the hardware is in that range. actually upgraded one of the old rigs (because parts are cheap) from an athlon to a phenom lmao thing has 16gb ram, it is stacked now with top of the line things from that era. keeping it around for nostalgia's sake at this point since it still works.
xmrig gets abysmal hash rates, not even worth running on older hardware.