BytecodeApi

BytecodeApi.dll - The mighty DLL file that will be shipped along with DevExplorer. It contains all common classes and additional ones that make it not just an API, not only a framework, but a Library. A framework (like .NET) comes with a lot of classes that make things easy. If you do both C++/WinAPI and C#, then you are probably very glad .NET Framework and C# exists as well.

Just to give you a small teaser, this is what the internals of BytecodeApi look like.

namespace BytecodeApi
{
	public static class Encryption
	{
		public static byte[] GenerateIV();
		public static byte[] EncryptRaw(byte[] data, byte[] iv, byte[] key);
		public static byte[] DecryptRaw(byte[] data, byte[] iv, byte[] key);
		public static byte[] Encrypt(byte[] data, string password);
		public static byte[] Encrypt(byte[] data, string password, int passwordHashPasses);
		public static byte[] Decrypt(byte[] data, string password);
	}
}

namespace BytecodeApi
{
	public static class Compression
	{
		public static byte[] Compress(byte[] data);
		public static byte[] Decompress(byte[] data);
	}
}

So, BytecodeApi is not only useful for DevExplorer's apps, but can also be used stand-alone. And these two classes are just exemplary. They simplify compression and encryption code, however BytecodeApi has lots of features that aren't part of the .NET Framework at all. There are especially a lot of extension classes on String, Stream, IEnumerable, etc.

namespace BytecodeApi
{
	public static class ProcessExtensions
	{
		public static ProcessLoadLibraryResult LoadLibrary(this Process process, string dllPath);
		// [...]
	}
}

DLL injection? An absolutely normal thing. HTTP api's for blackbox automation? I didn't invent data scraping... Pentesting, sandbox detection, inter-process operations? Well...

Considering DevExplorer's target audience (you), BytecodeApi implements these features as well. So code including it will almost write itself.