I haven't seen many definitive answers on this. Since the Vivo Tab RT runs a Tegra 3 processor, would it be possible to boot some sort of android onto this tablet?
amccue said:
I haven't seen many definitive answers on this. Since the Vivo Tab RT runs a Tegra 3 processor, would it be possible to boot some sort of android onto this tablet?
Click to expand...
Click to collapse
At this stage no. The Vivotab does not run an android bootloader, it runs a UEFI system, and the UEFI bootloader is locked down to only run stuff signed by microsoft
lilstevie said:
At this stage no. The Vivotab does not run an android bootloader, it runs a UEFI system, and the UEFI bootloader is locked down to only run stuff signed by microsoft
Click to expand...
Click to collapse
Any prospects for the future? or is it too unpopular with the devs?
Bypassing the "secure boot" feature that MS uses to lock out other OSes would be a major breakthrough, far above and beyond the typical effort required to support a new device with Android. This isn't a case of "oh, it's hard to port to UEFI", it's a case of "MS has deliberately used a UEFI feature to block support for other operating systems."
The best chance is something along the lines of kexec or haret to boot into Linux once code signing has been defeated by the jailbreak. I don't know if kexec was ever ported to smp arm, but it would definitely need to be rewritten to run on Windows.
In theory yes the vivotab could run android. The hardware powering a windows RT device is no different from any other android tablet.
In practise no. As said above UEFI is in the way. When a workaround for that is found then you may be able to run android but it might be a long long time until someone does find that workaround.
SixSixSevenSeven said:
In theory yes the vivotab could run android. The hardware powering a windows RT device is no different from any other android tablet.
In practise no. As said above UEFI is in the way. When a workaround for that is found then you may be able to run android but it might be a long long time until someone does find that workaround.
Click to expand...
Click to collapse
After finding a way to sidestep secureboot (UEFI is not in itself an obsticle just one of its features is a hinderance) someone will still need to spend the time porting the linux kernel
lilstevie said:
After finding a way to sidestep secureboot (UEFI is not in itself an obsticle just one of its features is a hinderance) someone will still need to spend the time porting the linux kernel
Click to expand...
Click to collapse
Linux for tegra 3 devices has been around for ages.
touchscreen drivers etc might be an issue yes but the kernel itself will run quite happily on the tegra 3. Ubuntu for various pieces of tegra developer hardware exists etc. Plenty of android devices out there.
Yes its no seemless but the kernel itself doesnt need porting. Just drivers, might be complicated via the fact that the touch screen and a few other peripherals are apparently done via i2c in RT devices which is a little unusual.
SixSixSevenSeven said:
Linux for tegra 3 devices has been around for ages.
touchscreen drivers etc might be an issue yes but the kernel itself will run quite happily on the tegra 3. Ubuntu for various pieces of tegra developer hardware exists etc. Plenty of android devices out there.
Yes its no seemless but the kernel itself doesnt need porting. Just drivers, might be complicated via the fact that the touch screen and a few other peripherals are apparently done via i2c in RT devices which is a little unusual.
Click to expand...
Click to collapse
Have you dealt with Tegra kernels? yes the linux kernel exists for tegra, but it hasn't been ported to the vivotab, pinmux et al tend to change between each of the devices, a kernel that works on one tegra device is 99% not going to work on another.
lilstevie said:
Have you dealt with Tegra kernels? yes the linux kernel exists for tegra, but it hasn't been ported to the vivotab, pinmux et al tend to change between each of the devices, a kernel that works on one tegra device is 99% not going to work on another.
Click to expand...
Click to collapse
I still wouldn't think the kernel is the big problem... people can get a kernel started and nuzzle it and its drivers until it works perfectly. UEFI is the Big Problem.
What I think would be a short term solution however is to take advantage of the existing jailbreak to run another bootloader (wouldn't even have to be as complex as a "kexec" as was suggested... just abandon Windows completely...) Does the payload sent as part of the jailbreak give us low enough level access, or does that still trip the Windows kernel into panicking and blue screening?
The latest version (1.20) allows kernel-mode code to run at the highest privileges. With that being said, I have no idea how Windows will try to hold on once Linux has been given control (watchdogs, interrupt handlers, etc will all need to be cleaned out)
My understanding of the suggestion was to create an NT kernel-mode driver that basically acts as a Linux bootloader, removign the Windows code from scheduling (and eventually overwriting it in RAM) entirely. That's likely to be a very complex project, but it's a sort of a cool idea. You'd still need to have Windows around for the actual boot process (which is appropriate, the term coming from "bootstrapping") since the UEFI won't start any bootloader except Microsoft's and I doubt that it will allow specifying the GRUB stage 1 loader or similar (although it just might... really doubt it though). Instead, we'd have to boot Windows, unlock kernel-mode code, and start this pseudo-reboot-into-Linux driver.
GoodDayToDie said:
My understanding of the suggestion was to create an NT kernel-mode driver that basically acts as a Linux bootloader, removign the Windows code from scheduling (and eventually overwriting it in RAM) entirely. That's likely to be a very complex project, but it's a sort of a cool idea. You'd still need to have Windows around for the actual boot process (which is appropriate, the term coming from "bootstrapping") since the UEFI won't start any bootloader except Microsoft's and I doubt that it will allow specifying the GRUB stage 1 loader or similar (although it just might... really doubt it though). Instead, we'd have to boot Windows, unlock kernel-mode code, and start this pseudo-reboot-into-Linux driver.
Click to expand...
Click to collapse
That's precisely my suggestion.
I'd like to think that it would be easy enough to just load the Linux kernel to RAM and mark the pages as executable, along with clearing any watchdogs/CPU caches then just set PC to the address the Linux kernel is at, but the sensible part in me knows that I'm probably oversimplifying far too much.
netham45 said:
That's precisely my suggestion.
I'd like to think that it would be easy enough to just load the Linux kernel to RAM and mark the pages as executable, along with clearing any watchdogs/CPU caches then just set PC to the address the Linux kernel is at, but the sensible part in me knows that I'm probably oversimplifying far too much.
Click to expand...
Click to collapse
Another thing I'd think about is how to tell you were successful in abandoning the Windows kernel and have successfully taken control of the CPU. This sounds like you pretty much would require some way of tapping in to a serial debug port or something to be able to tell the difference between Windows being truly departed versus arbitrarily freezing up. Before even really trying to run a kernel (since it's highly unlikely it would boot and be useful on the first try), it would be important to do some basic tests to make sure we've successfully and completely taken over hardware.
So the first of such attempts should be to run some little bit of ARM assembly to "do something" and be able to verify the results... I imagine trying to include an entire slew of instructions to make the GPU do something would be a little much, so my question is, does the Surface have some kind of internal testing connection for a serial device connected, probably provided by the Tegra, that would be reasonably easy to send data out to? We probably would need this anyway since the first few kernel attempts most likely would be failures to complete the boot cycle, probably before the GPU could be initialized.
southbird said:
, does the Surface have some kind of internal testing connection for a serial device connected, probably provided by the Tegra, that would be reasonably easy to send data out to?
Click to expand...
Click to collapse
It has at least 3 that I know of. The tegra 3 has at least 2 hardware UARTs, I think it might have more (most ARM SoC's do). It also has i2c which is being used for accessing the accelerometer in all windows RT devices. The tegra 3 has an SPI too. Its just a case of can we get at any of those.
The 3rd is on the bluetooth module. Most bluetooth modules support the serial port profile which specifically emulates a UART connection. Windows 7 and 8 (maybe RT, I dont know) even have built in functionality in the control panel to assign a bluetooth adaptor (either internal or USB) a COM number and it can then be addressed as a serial port provided it is paired with another device also supporting SPP. I think SPP is one of the most basic profiles and supported by just about all bluetooth radios. The ones in the surface should be capable of supporting it, its just whether windows RT provides access to it or not. With the kernel mode interface it might be possible to start interfacing with it again.
SixSixSevenSeven said:
It has at least 3 that I know of. The tegra 3 has at least 2 hardware UARTs, I think it might have more (most ARM SoC's do). It also has i2c which is being used for accessing the accelerometer in all windows RT devices. The tegra 3 has an SPI too. Its just a case of can we get at any of those.
The 3rd is on the bluetooth module. Most bluetooth modules support the serial port profile which specifically emulates a UART connection. Windows 7 and 8 (maybe RT, I dont know) even have built in functionality in the control panel to assign a bluetooth adaptor (either internal or USB) a COM number and it can then be addressed as a serial port provided it is paired with another device also supporting SPP. I think SPP is one of the most basic profiles and supported by just about all bluetooth radios. The ones in the surface should be capable of supporting it, its just whether windows RT provides access to it or not. With the kernel mode interface it might be possible to start interfacing with it again.
Click to expand...
Click to collapse
That's fine and dandy if Windows can support the serial mode of Bluetooth, but I'm talking about verifying success of having kicked Windows out... so we won't have that facility when we get that far. The hardware UART is really the direction that you would want to go, some low-level thing that can be easily accessed by assembler to show life initially and in the long term some kernel output from Linux.
I'd be interested in seeing what the pins on the keyboard dock can do. Does anyone know of a documented pinout for those?
netham45 said:
Is the bus that the keyboard attaches to input/output, or just input? I believe it's an I2C bus, but I'm not 100% on that.
Click to expand...
Click to collapse
Your not the only one interested in that
My guess judging by the fact it has 6 contacts is that it is not simply 1 bus.
It is already in microsofts documentation that accelerometers, gyroscopes etc will all connect to new windows 8 tablet devices via i2c. We know that the keyboard contains an accelerometer to detect whether it should be classed as in use or not. i2c requires 2 wires. That leaves us with 4 contacts left.
Both the keyboard and accelerometer also need power. Common voltages for an accelerometer are 3.3V and 5V. My guess is that the keyboard would be happier at 5V, then MS could also source that 5V power from the USB driver circuitry. They could have either regulated that 5V down to 3.3V or used a native 5V accelerometer. Either way there must be a ground and either %v or 3.3V supply. So thats 2 more pins down.
Leaves us with 2 unaccounted for and both the mouse and keyboard also unaccounted for. The mouse simply needs to return a few X and Y co-ordinates. I think the i2c bus for the accelerometer has plenty of bandwidth open for that purpose so thats the mouse down. From what I have read, the touch cover keyboard doesnt have the normal n-key rollover issue of standard USB keyboards and can return a huge number of simultaneous keypresses. Now, I dont think the i2c has enough bandwidth to deal with both mouse, accelerometer and a huge list of active keys so from that I deduce that the keyboard has its own bus. However we only have 2 wires left for it.
My first assumption would be that it was a PS/2 keyboard as many laptop keyboards at some point between going from a key matrix to the CPU are actually PS/2 devices and the PS/2 protocol is conductive to no n-key rollover. At first I dismissed this as we dont have enough pins, there are 6 on the surface and 6 on a PS/2 connector. But I decided to lookup the pinout anyway.
data
not connected
ground
+5 V DC at 275 mA
clock
not connected
So from that in a 6 pin PS/2 connector there are actually only 4 pins in use (some systems then had a second clock and second data on the 2 unused pins so that you could connect 2 keyboards or a keyboard and a mouse via a splitter cable). Of these 4 in use pins we have a +5V and a ground. Well we already have a ground and I already deduced there to be either 5V or 3.3V supplies. This reinforces that there may be a 5V supply. This then cuts 2 of them out of the equation leaving us with 2 connectors left over on the surface and 2 connectors left over for a PS/2 device.
So my guess is that the surface has the following pins (not necessarily in order):
+5V
GND
SDA
SCL
PS/2 Clock
PS/2 Data
It is also plausible that the keyboard could be a USB device. Again, this would only need 2 connectors. UART and i2c I wouldnt say are likely but are plausible options too but I maintain that the keyboard probably has its own i2c bus. It could be entirely proprietary.
that said. If the keyboard and mouse shared a bus that would explain 1 thing. Currently whenever you are typing on the keyboard you cannot move the mouse. It may well be then that the 2 wires I have assigned for PS/2 could be another i2c and that there is not enough bandwidth to register both keyboard and mouse down it so they just transmit keyboard data. Or it could be a modified PS/2 that allows the mouse and keyboard to be accessed via the same connector.
I am dead certain that my first 4 pins are correct (although not in the correct order). If there is indeed an i2c or 2 then that opens up some interesting options. Hell, it would be cool to see someone interface other keyboards to the surface via that bottom connector, or the touch cover to other computers (its a pretty portable keyboard after all).
Without actual hardware and some sort of datalogging multimeter I cant test my theories but I think they are sound.
southbird. I was more on about accessing the bluetooth radio directly rather than via windows. It is an accessible UART without any hardware hacking.
SixSixSevenSeven said:
It has at least 3 that I know of. The tegra 3 has at least 2 hardware UARTs, I think it might have more (most ARM SoC's do). It also has i2c which is being used for accessing the accelerometer in all windows RT devices.
Click to expand...
Click to collapse
Tegra 3 has 4 UART connections labeled A, B, C, and D. This is pretty standard of ARM cores. I2C is not that out of the ordinary either, usually most devices communicate using it. Up until recently ARM SoCs have not supported transports normally used in x86 pc's (PCI et al) and as such they are still not used, most touchscreens communicate over I2C, as well as various sensors (Gyro, ALS, Accelerometer, etc).
Honestly I think the biggest thing to watch out for is the UEFI subsystem interaction, UEFI isn't dropped away once a kernel loads, it remains running at all times, and usually has some level of involvement in communication between kernel space and raw hardware. When flushing out the windows kernel one will have to make sure that they are not tickling uefi into restarting the system, or that there isn't a watchdog running between the kernel and the efi framework.
{
"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"
}
Seems that it's an I2C bus.
Related
I know that Microsoft is only going to release Windows 8 RT as a pre installed OS on the specific device. I also know that they will lock the boot loaders of these devices. I know the chances of getting this seam close to impossible, but i found this device on Asus website.
http://eee.asus.com/global/event/2012/computex2012/tablet-600.html
It looks exactly like the TF300T just running windows 8 RT, it is even using the same exact processor. Do any of the developers think that it would be possible to extract the OS from this device and port it over to the TF300T? Also wouldn't Asus also have to post the image of the OS on their site to restore the device in case of a crash and you need to reload? If the second is the case wouldn't we just need to have a custom boot loader that would allow us to flash and actually boot into Windows 8 RT? I am mainly just trying to get a developers viewpoint on this to see if it would even be possible.
it had double the ram, a different resolution, NFC, led flash...
these things alone will make it near impossible to port windows 8 over to our tf300's, its seems the only spec to match is the processor, and even then it doesnt say what type of tegra 3 that is, so i really wouldn't get your hopes to high
coffmad said:
it had double the ram, a different resolution, NFC, led flash...
these things alone will make it near impossible to port windows 8 over to our tf300's, its seems the only spec to match is the processor, and even then it doesnt say what type of tegra 3 that is, so i really wouldn't get your hopes to high
Click to expand...
Click to collapse
If windows 8 RT is anything like the current windows operating system ( which Microsoft says it shares most of the same code as the x86 based version), than having more ram does not matter. The only thing that really matters is that the chip set drivers are the same and that the storage controller drivers are the same. So as long as the chip set is the same (or the diver is the same) than i do not see how it wouldn't work.
Its not an x86 PC, mind it... Embedded ARM platforms dont have plug and play, "smart" buses and standarts in general... It doesnt matter if device X is visually the same as device Y, all the meaningful stuff - GPIO, interrupts etc - maybe completely different.
As far as my experience goes (i 'launched' (cant say ported, i only 'welded' assorted driver code and kernel) linux on wince acer s200 ), CPU and miscellaneous hw initialization may be completely different on WinRT. Besides, why you want an OS which is incompatible with either WM7 or old WinCE/WinMo?
tsamolotoff said:
Its not an x86 PC, mind it... Embedded ARM platforms dont have plug and play, "smart" buses and standarts in general... It doesnt matter if device X is visually the same as device Y, all the meaningful stuff - GPIO, interrupts etc - maybe completely different.
As far as my experience goes (i 'launched' (cant say ported, i only 'welded' assorted driver code and kernel) linux on wince acer s200 ), CPU and miscellaneous hw initialization may be completely different on WinRT. Besides, why you want an OS which is incompatible with either WM7 or old WinCE/WinMo?
Click to expand...
Click to collapse
I understand your points. I was simply pointing out that Microsoft stated that the majority of the code for Win RT is the same as the x86 version. I know that it has nothing to do with the look of the product and everything to do with the hardware inside. The only reason i would prefer Win RT over Android right now is that Win RT supports the full desktop version of IE 10. Android is lacking a fully functional desktop version ( chrome does not support apps, the full version of java, ETC.) If Android where to get a fully functional desktop web browser, i would be perfectly happy. Also it would be nice to have the full suite of Microsoft office for college.
I think its more connected to limited IO and CPU resources of ARM tablets, rather than OS limitations... MS can say absolutely anything, but the fact is that there would be no software on release... especially if you take into account that Valve/major OEMs had already sent their 'f-bombs' to MS and its plans with windows 8.
Would the fact that all RT tabs ship with locked boot loaders halt anything as well? I don't believe MS wants RT out on anything but approved tabs.
Sent from my SAMSUNG-SGH-T989 using xda premium
You do know that since almost all win apps are in net frame work making them work is one click in vs2012?
Sent from my ASUS Transformer Pad TF300TG using Tapatalk 2
Hi,
is there a displayLink Software for the RT?? I have an Dockingstation with an extern SCreen and i really would like to use it, but this will only work with DisplayLink Software. So is there a solution for the RT??
Thanks a lot
HandyBesitzer said:
Hi,
is there a displayLink Software for the RT?? I have an Dockingstation with an extern SCreen and i really would like to use it, but this will only work with DisplayLink Software. So is there a solution for the RT??
Thanks a lot
Click to expand...
Click to collapse
Nope- no DDK for WinRT, so no one can make third-party hardware that doesn't fit the preloaded driver set:
http://www.displaylink.com/support/ticket.php?id=335
Well, no public DDK. There's (quite obviously) an internal one, and it has apparently been shared with certain partners, and a copy of it has leaked onto the Internet and been found (and occasionally used) in various places. That said, even if a commercial outfit were willing to entertain the use of such a thing, they would need to get the resulting driver signed by Microsoft for it to be installable on non-"jailbroken" RT devices.
this signing thing is really terrible. is there a chace to get such a driver in future??
GoodDayToDie said:
Well, no public DDK. There's (quite obviously) an internal one, and it has apparently been shared with certain partners, and a copy of it has leaked onto the Internet and been found (and occasionally used) in various places. That said, even if a commercial outfit were willing to entertain the use of such a thing, they would need to get the resulting driver signed by Microsoft for it to be installable on non-"jailbroken" RT devices.
Click to expand...
Click to collapse
Right, so effectively no DDK for general peripheral manufacturers to use unless MS decides otherwise for that device-- hence the situation with USB Ethernet adapters (and the driver that Plugable released then had to pull).
I'm a bit puzzled by the situation-- if MS' concern is that poor drivers would affect the WinRT user experience, then presumably they could enforce a testing process (as they already have w/ WHQL) and only allow driver delivery through Windows Update.
As it stands, WinRT devices, running full-blown Windows, are ironically far less useful in custom applications than iPads, which have all sorts of accessories available. Why wouldn't MS want WinRT to be usable in, say, medical settings? (even iPhones, let alone iPads, can connect to hardware accessories like medical sensors).
Android's also catching up quickly in the accessories space, and it's only a matter of time before iOS/Android destroy any advantage MS had w/ hardware manufacturers, as happened so dramatically in the software space (there are now so many more devs who've worked with iOS and Android than have with modern MS platforms).
Well, for accessories that just need "traditional" data I/O - things like what you might have done over a serial port in days of yore - you can easily use either BlueTooth or the audio jack (although the latter is a real hack, usually used only for very small dongles powered by the audio signal). The iPad is definitely less extensible with third-party hardware (note, accessorizable != extensible) than RT, but I fully agree with you that Microsoft's stance on RT drivers is just plain weird. Keep the pool smallish and/or WHQL-test the crap out of them, but make them available! Those USB ports can and should be a killer feature.
The audio channels available on many consumer devices are often perfect for bit banging various communications protocols. UART "emulation" has often been done on the headset jack with a level shifter and some trickery, often on android devices much less powerful than the surface RT (seen a demo on an 800MHz single core ARMv6 handset). If your willing to sacrifice audio output from your application on the RT (as it is being used for bit banging the UART) then you essentially have a plug and play serial port without any special drivers needed, your application just needs to be able to generate an audio signal and analyse an input. the peripheral will need an external power supply but this is common on many legacy RS232 applications too.
There is the bluetooth serial port profile. Thats often used as a replacement for RS232 or UART. I dont know if windows RT supports it though (someone would have to check).
Another trick I have seen involves a microcontroller with USB capabilities. I have seen examples of people setting a microcontroller to appear as USB mass storage and having a small file system with 1 plain text file. Writing into this text file from windows or linux etc would then cause the microcontroller to perform a particular operation in response. Sensors can also be read by the microcontroller causing it to update the text file too. You essentially have file based GPIO without.
Its all rather hacky but it works technically.
There is also an i2c bus on the RT keyboard connector.
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.
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.