Hey guys, quick update on the progress of the web browser. Recently I have been developing an application subsystem for the browser, it will allow you to download any executable file to the hardrive and "install" it as an app for the browser without going through any App Store equivalent system to do so, which in my opinion makes everything more simpler and opens the doors for any developer to develop for the browser platform.
When an application is loading, the browser verifies it and gives it the security permissions assigned by the user, if the app contains a reference to a library that is not either the SDK or mscorlib, it does not load it.
The security permissions are deturmined by whatever the user has put in place. E.G with default permissions and the application writes to "C:/myfile.txt", it emulates the directory so it translates as writing to a file in "webbrowser/apps/[appname]/data/myfile.txt" unless of course the user gives it the permission to do otherwise.
Security? Well, in order for an application to be registered (at runtime everytime the browser starts), your application must ONLY reference to the given SDK library and not referencing to any .Net framework libraries (by using the library overrider I posted here:
viewtopic.php?f=6&t=8486). Simply put, it forces you to use only the SDK or libraries/apps that are registered on the browser already.
As well as that limitation, it still allows for exploits such as
Code: Select all
//equivalent of System.IO.File.Delete("veryimportantfile");
typeof(string).Assembly.GetType("System.IO.File").GetMethod("Delete").Invoke(null, new object[] { "veryimportantfile" });
So, to prevent this exploit (as well as using object.GetType()) the browser decompiles every function in your library and looks for the IL op code "ldtoken", "call" and "callvirt", once it comes across these operations, it verifies the return type of each function or the type of object in the operand.
As well as this, the browser also checks your references. It looks for any other references other than the SDK library or the mscorlib library. If you reference to these libraries, it simply won't register.
(Btw when I mean register, I also mean, if verification fails, the browser will not load the assembly.
It's slow I know, but I think it's worth it to give the users the satisfaction that an application they are running with the browser is not performing malicious actions on your computer in the background.
If anyone knows any possible ways around this, please say.
Also, writing and reading to memory to hack the registration process is completely out of the question since it limits of [DllImport("")] or whatever the equivalent is for that language so it stops you from accessing the kernel functions WriteMemory and ReadMemory
I've just tried it and it doesn't work