About varocarbas.com

--

About me

--

Contact me

--

Visit customsolvers.com, another side of my work

--

Valid markup

--

Valid CSS

--

© 2015-2017 Alvaro Carballo Garcia

--

URL friendly

--

Optimised for 1920x1080 - Proudly mobile unfriendly

R&D projects RSS feed

All projects in full-screen mode

PDFs:

Project 10

Project 9

Project 8

FlexibleParser code analysis:

UnitParser

NumberParser

Tools:

Chromatic encryption

(v. 1.3)

Pages in customsolvers.com:

Upcoming additions

Failed projects

Active crawling bots:

Ranking type 2

(
)

FlexibleParser raw data:

Unit conversion (UnitParser)

Compound types (UnitParser)

Timezones (DateParser)

Currently active or soon to be updated:

Domain ranking

FlexibleParser (DateParser)

NO NEW PROJECTS:
Project 10 is expected to be the last formal project of varocarbas.com. I will continue using this site as my main self-promotional R&D-focused online resource, but by relying on other more adequate formats like domain ranking.
Note that the last versions of all the successfully completed projects (5 to 10) will always be available.
PROJECT 8
Completed (26 days)

Usage of CoreRun.exe >

Minimum requirements

Completed (47 days)
Completed (19 days)
Completed (14 days)
Security implications of open CoreCLR (CoreRun.exe)
Completed on 05-Feb-2016 (26 days) -- Updated on 23-Nov-2016

Some of the conclusions of this project aren't applicable anymore.
To know more about all this, read "OVER-8-MONTH-LATER UPDATE" in the Open .NET & CoreCLR section.

Project 8 in full-screenProject 8 in PDF

This project comes from the assumption that CoreRun.exe can be a security threat because of allowing to easily modify .NET applications. It has to be noted that "easily" is a very important part of the previous sentence, equivalently to what happens in the definition of any other software security analysis. This point is specially worth noting here on account of the fact that the source code of CoreRun.exe has been made publicly available.

The aforementioned paragraph explains why this section and the next two ones, Windows version and Visual Studio & .NET version, are needed: the default constraints of CoreRun.exe (i.e., how easily the default version can be used under different scenarios) is a key part of the current analysis. Additionally, there are other issues to bear in mind in order to properly understand this project:
  • Neither CoreRun.exe nor the Visual Studio files associated with it (e.g., CoreRun.sln) can be found in the CoreCLR repository, but just the C++ files containing its source code. The executable and the VS files are included among the outputs generated when building the whole CoreCLR code (i.e., running build.cmd); in Windows machines, these files are stored under \bin\obj\Windows_NT.x64.Debug\src\coreclr\hosts\corerun\.
  • I did all my tests on Windows 8 & 10 (64-bit). That's why I am not completely sure whether the conclusions of this project are also applicable to other operating systems, although this seems the most likely scenario.
  • The majority of this project has been focused on testing CoreRun.exe under different conditions, rather than on analysing its source code. Nevertheless, I did skim through the code and did perform slight modifications on it as a way to confirm certain assumptions. Doing a more detailed analysis of the code would have been against the aforementioned expectations of this project (i.e., CoreRun.exe being an immediate security threat).

Basic CoreRun.exe requirements:
  • 64-bit Windows version. Its target platform is 64-bit, equivalently to what happens with all the CoreCLR code.
  • Visual Studio installed. CoreRun.exe requires certain files which are present in the supported versions of VS.
  • Using it with a .NET executable. For example: typing "CoreRun.exe MyExecutable.exe" in the command prompt, where MyExecutable.exe was built on a .NET language.
  • Including all the required libraries in the same directory than CoreRun.exe; at least, coreclr.dll and mscorlib.dll. In this context, "required" means used by the given .NET executable. For example: if MyExecutable.exe relies on Decimal.Parse, the library including this method would have to be included (i.e., mscorlib.dll).