Database Info

Windows 8 RT for TF300t?

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

Dual Boot Tegra 3 Vivo Tab

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.

WinKexec - Kexec via Windows driver

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.

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

Hi,
I've buy from at lest one mont a surface rt, i've jailbreak it and install filezilla and notepad+++ so.... but i'd like anymore. Like many people i'd like to install a linux distribution on it but i dont really understand what is the problem...
I've know about:
Surface get a secure boot (EFI) and we can't disable the secure boot on surface RT caused windows need a valid key (?). I've read that linux got some distributions arm based (ubuntu, debian, fedora) and i think i've understand about ubuntu got a valid microsoft signature with a ssl provider that can bypass the useless verification... am i right?
So, if ubuntu (or another distro), got a valid sign for bypassing the limitation to due EFI why can't we normal install linux such like surface pro??
Best regards and sry for my bad english ^^'
----------------------------------------------

Some distros has keys to X86 UEFI. No one (other than Microsoft) has keys for ARM.
And (afair) due to some limitations of jailbreak we have no way to execute linux kernel.
This applies to any RT device.

kitor said:
And (afair) due to some limitations of jailbreak we have no way to execute linux kernel.
Click to expand...
Click to collapse
Is this true for sure? I figured especially since we have driver-level access we could possibly tear down the Windows kernel in reverse and start execution of arbitrary code. But I might have missed something.
The bigger issue about trying to port Linux to any device without official Linux support is usually in getting the kernel to boot and then making the hardware itself useful after that. This usually means you have to work "blind" and rely on some kind of low-level serial output to monitor the kernel boot to see where it panics. Only after getting a successful kernel boot can you even begin to think about drivers for the display, touch screen, etc.
So the prerequisites to even beginning to port to e.g. a Surface would be to find some way to kick out Windows and start arbitrary execution, enable some kind of low-level serial debugging for the would-be kernel, and then tediously poke and prod until it can successfully start. I'm not sure anyone knows of a dependable way to get serial debugging information.
Embedded devices on the whole are a lot more finicky and a lot less tolerant than normal PCs, generally due to their proprietary nature requiring a lot of hardware knowledge to initialize everything properly. About the only thing we'd have going for us is that it's a Tegra chipset, so if you can get the underpinnings working, you can probably at least get the basics like video and USB working without too much trouble.
I think the biggest thing about it is like the rest of RT ... there's just not enough interest in those with the skills to even attempt this because this is such an extreme minority platform. I imagine a Surface RT would make an excellent little Linux tablet, but I'm not holding my breath.

Well, If somebody would write something like WinKExec, or HaRET (haret allowed to analyse gpios and memory on WinCE/WM devices) then things may be possible. I own XPS10, so quite different device (as it has Snapdragon CPU), but I have some (small) experience on porting Linux on ARM devices - some time ago I was able to get Linux working on Bsquare Maui: http://pdasite.pl/kitor/maui_linux/ (including hardware reverse engineering - tracking gpios using multimeter - this way i found hidden usb host )

There's been talk of a WinKExec-like approach for months. Nobody has attempted it yet, though, or if they have they kept quiet about it.
One of the problems getting something like that working on RT is that it blocks kernel debugging, so you have to work pretty blindly. Then there's all the driver issues.

What about getting android to boot on it? There's drivers and such for tegra 3. I think its possible to build and deploy if we can get a kernel exploit. Am I wrong?

Android depends on Linux. If you can't get a Linux kernel booted, you won't be able to get Android to start up either.
skiman10 said:
What about getting android to boot on it? There's drivers and such for tegra 3. I think its possible to build and deploy if we can get a kernel exploit. Am I wrong?
Click to expand...
Click to collapse

The kernel by itself would be *relatively* easy (translation: still quite hard, but we could probably do it if people cared enough). However, getting all the other hardware (you know, things like the touchscreen, WiFi, and such) would likely be difficult, and without all that, it's pretty useless as a tablet. This is true for both Android and "desktop" Linux.

Where should I start to get a kernel to boot? I'm an android exploiter trying to dabble in Windows exploitation.
Sent from my HTC6500LVW using Tapatalk

Well, unless you think you can break Secure Boot, you should start by writing/porting a way to use the NT kernel to launch the Linux kernel. That probably means a lot of NT driver development stuff (done without the aid of a kernel debugger, just for extra fun).

There's a doc on internet from the blackhat usa 2013 seems to be interesting.
The man from the pdf get the exploit of injecting some code from the boot, so i think we can done this, no ?
If anyone tried and arrive he'll get amout of money from me

graphsys said:
There's a doc on internet from the blackhat usa 2013 seems to be interesting.
The man from the pdf get the exploit of injecting some code from the boot, so i think we can done this, no ?
If anyone tried and arrive he'll get amout of money from me
Click to expand...
Click to collapse
Can you PM me the article?
---------- Post added at 10:59 AM ---------- Previous post was at 10:57 AM ----------
GoodDayToDie said:
Well, unless you think you can break Secure Boot, you should start by writing/porting a way to use the NT kernel to launch the Linux kernel. That probably means a lot of NT driver development stuff (done without the aid of a kernel debugger, just for extra fun).
Click to expand...
Click to collapse
I think there is an exploit for Secure Boot, it just hasn't been shared yet...

If you mean the exploit I think you mean (discovered by an XDA member), it's a Windows bug, not actually a Secure Boot bug. It doesn't actually allow booting a different OS directly, just messing with Windows after bootup. We already have the jailbreak (for 8.0), which is pretty much equivalent.

GoodDayToDie said:
If you mean the exploit I think you mean (discovered by an XDA member), it's a Windows bug, not actually a Secure Boot bug. It doesn't actually allow booting a different OS directly, just messing with Windows after bootup. We already have the jailbreak (for 8.0), which is pretty much equivalent.
Click to expand...
Click to collapse
Im researching the doc i've found to provide you it.
Its not the jailbreak done by clockr ported by neman its another jailbreak who's available from the boot, but if remember they dont give sources... search in progress i'll post the link

There is one theoretical way to remove secureboot on a jailbroken device. It is rather easy: write a driver that reads/writes physical RAM. Find EFI_RUNTIME_SERVICES in memory and look for SetVariable function. Patch it so that it does not check for a valid signature. Than write your own certificates to UEFI with this patched function. Profit.
I've already done the first part - wrote a driver and found the table in memory (this is really an easy part). But my device died before I was able to successfully overwrite the certificates.
As far as I know similar method was once demonstrated for an x86 UEFI, just noone made it for ARM.

That... is a rather clever option too, although I'm tempted to avoid things which require modifying the firmware (too much option for future updates to break things). Still, a good option for those of us with gen1 devices who would like to be able to upgrade without losing the jailbreak, and also a good option for those who would like to install different OS images...

mamaich said:
There is one theoretical way to remove secureboot on a jailbroken device. It is rather easy: write a driver that reads/writes physical RAM. Find EFI_RUNTIME_SERVICES in memory and look for SetVariable function. Patch it so that it does not check for a valid signature. Than write your own certificates to UEFI with this patched function. Profit.
I've already done the first part - wrote a driver and found the table in memory (this is really an easy part). But my device died before I was able to successfully overwrite the certificates.
As far as I know similar method was once demonstrated for an x86 UEFI, just noone made it for ARM.
Click to expand...
Click to collapse
Can we get in contact? I'd love to get a more detailed plan that I can try. Gen 1 Surface RT on Windows 8 RT.

One demo about bypass: youtube.com/watch?v=i9ULYwRK1iU searching again the pdf mens

GoodDayToDie said:
Well, unless you think you can break Secure Boot, you should start by writing/porting a way to use the NT kernel to launch the Linux kernel. That probably means a lot of NT driver development stuff (done without the aid of a kernel debugger, just for extra fun).
Click to expand...
Click to collapse
About the only way you could possibly break secure boot is possibly by spoofing a key or potentially modify the UEFI to have secure boot disabled. While both are technically possible, you'd have to find an exploit to do it because I'm sure the UEFI probably can't be easily flashed

ThatGuy94 said:
About the only way you could possibly break secure boot is possibly by spoofing a key or potentially modify the UEFI to have secure boot disabled. While both are technically possible, you'd have to find an exploit to do it because I'm sure the UEFI probably can't be easily flashed
Click to expand...
Click to collapse
if you got a device with a jtag interface left open, that should be easy enough. The problem is that EPROM "fuses" are usually burned on the SOC. The secureboot check is hardcoded check that flag. You can't alter the bootloader without invalidating its signature, and it's practically impossible to unset an EPROM fuse.

windows 95 running on surface rt

start windows 95 Help on surface rt, really need the program electronic workbench 5.12, via an x 86 emulator, it is not.
I will use bochs, downloaded the BIOS file and VGA in tab CPU put the bad CPU, but still does not work. The configuration file can only be downloaded in the format of the bxrc format, the txt he does not understand. If that happens, put Please setup and working windows 95 image

I kind of doubt anybody else is going to bother with the effort needed to get Win95 running (it would run very slowly, although I suppose it was intended to run on very slow CPUs...) on a first-gen Surface RT, but hey, maybe I'm wrong.
Anybody familiar with Bochs configuration want to weigh in on the configuration issue? I never really did much with it.

GoodDayToDie said:
I kind of doubt anybody else is going to bother with the effort needed to get Win95 running (it would run very slowly, although I suppose it was intended to run on very slow CPUs...) on a first-gen Surface RT, but hey, maybe I'm wrong.
Anybody familiar with Bochs configuration want to weigh in on the configuration issue? I never really did much with it.
Click to expand...
Click to collapse
I really need the electronic workbench 5.12 "want to run it in any way, it is not a resource, the minimum requirements in the area of pentium 200 MHz

You'll be lucky if you get that equivalent of speed, actually. Typical estimate is order of 10x overhead for emulation, which means each core of the Surface RT is basically like a 130MHz x86 chip. Unless the emulator runs across multiple cores and the program does too (unlikely), you probably won't get much.
Have you considered running it on a real PC and just having the Surface remote desktop into it? Unless you're somewhere without an Internet connection, that's at least a little more likely to work.

Deleted due to forum software screwup

If they can run windows 95 on Android wear, Surface RT is certainly capable. If that's what you want to do, and have the ability to get it done knock yourself out.
https://www.youtube.com/watch?v=GZx-LJH5J_I

Whether or not it's *possible* to run 95 wasn't really in question - people have, in fact, booted later versions of Windows via emulators - but rather whether it's a practical way to run even a very old program.
If anybody were still maintaining the RT x86 dynamic recompilation layer, I'd say to work on getting it working in that; the performance is a lot better when you don't have to support an entire OS and can execute OS library code in native instructions rather than emulating even the low-level functions. However, I don't think even the source code for that program was ever released. :-/

Weigh in here
Deleted due to forum software screwup
Click to expand...
Click to collapse
What happened? HAHA
Also I would like to weigh in here. You (mickel2255) should have done a simple forum search. Gooddaytodie has a list and in it is an x86 emulator that I tested with electronic workbench 5.12 and it works no problem.
List of desktop apps for hacked RT devices http://forum.xda-developers.com/showthread.php?p=36534446
Click to expand...
Click to collapse