[Windows RT Development and Hacking] CrackTheSurface:
Grub doesn't as expected and next steps

TL;DR:

Grub doesn't work as expected but there are commands which could be useful

tips for searching debugport

I played a bit with GRUB and got frustrated.

First I couldn't make GRUB chainloading any EFI file.

It can't chainload bootarm.efi, test.efi nor boot.efi itself. [MENTION=2022267]ShapeShifter499[/MENTION] [MENTION=10784299]coherixmatts[/MENTION]

I took an binary editor and changed the string which is displayed on top in "BOOT.EFI". (GNU GRUB version 2.02~beta2 -> GNU GRUB version 2.03~beta2). This image boots fine and displays the change I made. So BOOT.EFI shouldn't be signed as mentioned earlier.

But even this image cant boot the original BOOT.efi or the otherway around. This was very disappointing.

I played a bit with insmod (insmod chain to load chainloader module) and after a typo Grub responded with something like "can't load module from disk because of secureboot"

This is the default behavior of GRUB because it got the secureboot key passed from uefi and Grub wants to keep the chain of trust alive.

I found a GRUB Envoirment Variable named check_signatures which could be set to "enforce" | "no" and should prevent GRUB from verifying anything it loads. (EFI files, linux kernel, devicetree, initrd, etc.)

But this didn't made any difference (at the moment i am not sure if i tested correctly).

I will try to chainload Windows. this should work, because winload.efi (or however it is called) works fine and is signed by microsoft.

If this fails, the provided GRUB image isn't worth our time and we should try to compile a newer version or go straight to linux efi boot (EFI_STUB) without any bootloader

[MENTION=10784299]coherixmatts[/MENTION]

with your instruction to build grub the grub.efi only has ~330kb but he original grub has ~700kb

I guess there are some module missing 400kb of platform specific code would be horrible

maybe we should go with "grub-mkstandalone" instead of "grub-mkimage"

this results in ~4MB (yes MB) but still wont boot :( but maybe a better try?

Here are some Grub commands which are imo essential:

I will try adding set "check_signatures, root, pager" to grub.cfg to avoid problems in future.

set pager=1 #only fills one page with output then waits for key press, useful for long text outputs
set debug=all #nightmare with pager=1 but could be helpful
set check_signatures=no #like mentioned before
set root=hd0,gpt1 #chooses disk where you want to load files from. hd0 is the disk and gpt1 is the partition eventually need to enter your specific usb name which should be found by "ls"
ls <dir>
"ls /" -> test.efi, boot.efi, grub.cfg, unicode.pf2, efi/ #after configuring "root" to your usb drive
"ls hd0,gpt1/" -> lists file from specific harddrive + partition
"ls /efi/boot" -> bootarm.efi
"ls" -> lists harddrives something like "(hd0), (hd0,gpt1), (hd1), (hd1,gpt1), (hd1,gpt2), (hd1,gpt3), ..."
chainloader #used to start other .efi files
linux #specify kernel file
devicetree #specify devicetree
initrd #specify initial ramdisk
boot #after linux, devicetree, initrd should boot your linux system

[MENTION=10790381]JukeBox344[/MENTION]:

- Booting from SD card is something even most PC aren't capable to do, even with an sd->usb converter (but Grub should be able to boot from sdCard with appropriate drivers).

- To find an debug port (serial preferred) you should start jailbreaked windows. press "WindowsButton on Keyboard" -> type msconfig -> tab: start -> advanced options -> check debug -> select debug port: COM1 -> check Baudrate & select 115200 or 9600

I read 115200 when i browsed the BCD file which loads test.efi and found that value under:

BCDStore -> Settings -> dbgsettings : SerialDebuggerBaudRate

and under:

BCDStore -> Settings -> hypervisorsettings : HypervisorDebuggerBaudRate

This value is also a well known by microprocessors folks (I guess you know that ;) )

Does your Surface RT has an J14 Connector visible when you open up your backcover? It is not soldered and you need scratch CAREFULLY to get to the copper. I bet my ass that there is a serial port hidden and some jtag pins but unfortunately i dont know anything about jtag but google said it isn't helpful for what we are doing. (I am not responsible for any damage)

This are the steps i also want to try but I would be very grateful if you could do this too, to reduce the errors i will probably make.

Probing with an oscilloscope sounds good, depending on the voltage level I suggest to use an usb->serialconverter or arduino with "Software serial" to get multiple RX lines to probe further to get useful output

- Display-drivers on 1 & 2 share the same microarchitecure Tegra4: Surface RT 2 & Tegra3: Surface RT