I believe the binaries are signed (so renaming it would potentially break the signature hash validation), and also must be run from one of the trusted locations in Windows (\Windows and \System32 or \Program Files). There may be ways to get a non-shipped ARM binary to run on a Surface, but I'd wager you'd need Microsoft's signing certificate to get it to run.
Just moving the file around or renaming the file shouldn't break a digital certificate though. A certificate is meant to break when the actual byte data of the file is changed around a file is just a pointer if you will towards that collection of bytes if I can try painting the best picture I can. However, all I really did was copy the file to the same directory, and I couldn't use it. This was System32 folder though, so it was a trustable location, and I didn't invalidate the signature either. That crosses those things out, but i'm wondering, if it's not to do with certificates, and it hasn't anything to do with the trusted locations... What's stopping it?? :confused2:
There's got to be something else we're missing here...
The file that I'm trying to run:
- Is (still) signed by Microsoft with an SHA256 hash digest
- Is in the System32 folder ("trusted location")
I'm a guy who knows a fair bit about digital certificates, and the binary data itself has to change in order for it to invalidate, disregarding any flaws it has, that's what it's meant to do. Have any other ideas? lol I can't understand this right now... ARM or Windows RT, information seems scarce at this point in time with it being so new.
I appreciate any kind of feedback or hints you can give me if you have any.
Edit1: ..
.. Nope, I copied regedit.exe from Windows to System32, and tried running it from the System32 folder, regedit.exe (same name as file in Windows folder), and nothing showed up. Running as administrator gives no results either.
I'm starting to wonder if there's some cached version of the $MFT around which would allow the system to only run the files it knows exist in it's factory locations on the filesystem as absolute paths? Otherwise this just doesn't make sense to me. If that were the case, if somebody could find it, it may be possible to get that much closer to running your own programs on Windows RT. Right now i'm just speculating however. Still need to be able to compile executables that will run on the Windows RT environment under an ARM based processor instead of Intel.
Edit2: It's confirmed, as far as I know. Somehow it's using that absolute filepath to the executables it knows are meant to be run (provided by Microsoft). I tried copying regedit.exe to the same original folder, it did NOT run, so I renamed the original to regedit.exe.bak, renamed original to some other filename so I could rename the copy to the actual filename ("regedit.exe"), and it ran PERFECTLY! So this seems to be an issue of maintaining an expected filepath including the filename.
Now the new question: WHERE would it be validating that I wonder? :confused2:
Edit3: Uhh, that's odd. I found a file that was in the Windows directory, called write.exe, which is another notepad-like device, only it supports rich text. The odd thing is that it displays the same refusal to run that the other tested executables show when I just copy them and try to run the copied file. Perhaps this is not in that mysterious "database" of "allowed-to-run" files? Did Microsoft forget this application? How come write.exe will not run for me (Note: I did not edit or change or fool around with this file in ANY way.) Perhaps if I can't run some more executables, that the file's list can be shrunk down a bit with a friend I call
delete? :lol:
Something seems to be preventing certain files from running, i'd like to know what that would be though...
~Ace