SkyLine's Development

The SkyLine programming language is a programming language designed for security experts or security practitioners who write their own programs tailored to cyber security. You might be asking how can this even exist? What exactly makes a programming language " cyber security tailored "? We are glad you asked! This document and part of the gitbook will be talking directly about the language, how it exists, why it exists and what exactly our plan is!

Why and how was SkyLine created / Radical background

SkyLine never had any initial direction, it has been talked about many times that the programming language itself was not exactly designed for any security related topics, it was just a single project started up to find something new to the original developer and to create a modern version of RPC ( not what you think of ). RPC was the original birth programming language of SkyLine, it's original name was Radical Processing Core which was a very radical and syntactically advanced and esoteric programming language tailored towards game cheat development. This is because at the time of development the developer did not want to make exploits for specific games without using something unique, thus RPC was born. RPC in itself had many different distinct qualities, as the language itself took a much more extreme hence radical approach to syntax, functionality and execution. Below is an example of a program in RPC that would output hello world.

RPC -> RPCL15_Count | RPC.BRICK => {{{
                    RPC:::Unit::SYMBOL | RPC.BRICK START
                      RPC::Unit->StartKerel()
                      RPC::Unit->Driver()->_result
                      Call SubROUTINE95 ==> RPC::DEBUGUNIT()->modulename#*&>RESULTS
                                         ||
                    RPCO INIT {{{
                        (  ----> RPCOUTPUT << PREPARE(RESULTS)    )
                            ~> RPCOUTPUT
                    }}}
                  ||  
                      !!!-> rpcn 
                                This is where the HTML code will be renedered by the engine
                      !!!<-  

                    RPC::Unit::SYMBOL | RPC.BRICK END
                }}}

@#{<lualib>}#@
@#{<libc>}#@
@#{<supersetc>}#@
@#{<stdlib>}#
@#{CLASS(filename.rpc++)}#@
@#{$$MOD(rpch++)$$}#@

RPC Class Structure {
    RPC>*MODULE (modulename) START* 
            ||
                RPCO INIT {{{

                        (  ----> RPCOUTPUT << PREPARE("hello world")    )

                            ~> RPCOUTPUT
                }}}
            ||  
    RPC>*MODULE (modulename) END^
}

String : String : interface{} => CALL_LUA(X, Y, Z) -> LUA {
    a=math.abs(Y-Y) 
    b=math.abs(X-X)
    c=math.sqrt(a*a+b*b)
    print(c)
}

VOID : => CALL_CPP() -> C++ {
    const auto data = nullptr;
    namespace functions {
        void functiontocall();
    };
}

String : => CALL_C(message) -> C {
    printf("%s", message);
}

RPC->INITATE_______BACKENDCALLTOKERNELEVTERMSOCKS__#(ALLOW C++20, C++11, C++13, PYTHON, LUA, GO)-? IMPORT FROM("ENGINE.DLL")

{{{{{{
  @TEMPLATING_ROFF_RUN [
          (
            RPC->INITATE->TREECUT ||  
                JOB -> INI_FILE_CONFIG_LOAD_FROM("/USR/SHARE/BACKEND")
                PROG MAIN()
                {
                  IMPORT("ALL")
                  seq->:All, Seq, 2s, CPP/PY/L/GO/RB, ;;; -> to sequence of type ...interface{}
                }
                END PROG MAIN()
            ||
          )
      ]
}}}}}

This as you can see is- very very confusing, and before you ask and question yourself, yes this was an actual syntax that did work. The language itself after a few months into development failed, this is because due to the extreme sets, idea's and syntactic rules that needed to be put in place it just was not possible to finish. Well, let us put it this way, it was, but it was not something that was going to be performant in the end. The idea behind the language was to be extremely low level and when the first example and demo byte code compiler came out, the language ended up becoming self hosted right out of the gate but could load plugins for language's like go utilizing a halfed backend or standard function with go while also generating specific configuration formats. The language was then kept as a design concept and later scrapped due to the amount of bugs, horrid issues, annoying bloat and things that a programming language should never be. While the syntax itself was designed for only the developer and only the developer to understand, it would eventually get out there if specific exploits got leaked. Not to mention, the language itself would just be an extreme pain to work along with it since you would have needed to know some base idea of Fortran95 and if you wanted to call lua or C++ code you would need to know the templating side of the language. RPC also had an enigne well three actually.

Engine Name	Language Implementation	Description
RPCT	RPC	Radical Processing Core Templating engine was designed and used to generate specific templates such as assembly payload or shellcode templates, perl code templates, html code, work with RPC's inline HTML templating language and other various project files.
RPCC	RPC	Radical Processing Core Configuration was an assitant that would help configure and work with current project environments or generate project environment's based on RPCCFF's ( Radical Processing Core Configuration File Format ) which had its own unique syntax
RPCIW	RPC	Radical Processing Core Inline Web was an engine that would help run local HTTP servers with custom HTML files with inline RPC code.

All of these engine's were extremely helpful but by the time RPC was even a language and a base design was implemented and some basic engine functions were put into place the language become so horribly bloated with broken and buggy code that it just was impossible to rewrite. This lead to a ton of confusion between the developer and the language itself, then the idea clicked. RPC was never going to succeed because it was a language no person would bother to learn when they can type up some weird python script flooded with third party libraries to run their exploits this was of course that it was decided that RPC would eventually get out there in the case of reverse engineering of exploits occurred. A few nights later after canceling everything with RPC an idea for another language started to form but was not actually taken seriously, it was going to be a modern day version of RPC. During those nights there were some idea's and by some I should say around 20-30 idea's of a language that could solve problems, but each way and idea became so- hard and complex to implement that it fell flat. The project was then abandoned and any hope to create a real programming language would just trip instantly down the rabbit hole. Fast forward a few months and one night an idea pops up, the developer of the language wants to develop a language that inherited the RPC syntax to an extent while also respecting the language's core design. For context, the RPC interactive code console looked like this when running files.

The language itself as you can see was quite radical, even its errors were quite wacky and the console was so round? When the idea of a modern language started to form, within a singular hour that night the syntax, banner, design, idea of the language was all directly developed and the language had a singular end goal. That goal was to be as modern as possible while also keeping the radicalism of RPC. It is important to note that when we decide to use the word radical we are referring to how extreme, different and unique the language was as well as how aggressive the original language was.

The programming language's rebirth would just be called SkyLine. The original banner design of the language was the one shown below.

SkyLine Original Banner

This banner is quite confusing to some people, why did it exist? what was the purpose? let alone what were the idea's that the banner would bring? The idea behind the banner was to show a form of modern day radicalism silently. This means that the banner seems simple yet could be manipulated to represent hundreds of things in different forms. Since the language itself brings new idea's, new syntactic rule sets, new forms of libraries the banner would then later make people think that the language is simple then show its true side. The banner also represents the logo SL where the backwards L represents an attachment to a prime skyscraper which is the arch in the image. Thus forming the words SkyLine to represent a modern, urban, stealthy and skyline representation.

Syntax Porting / Syntactic development

The rebirth also brought in idea's from RPC's initial syntax and since SkyLine did not have plans to become a machine code compiled language, it would still like to hold syntax rules that belong to machine code compiled language's and then of course implement those by inheriting the original syntax but instead again putting a modern side to it. The first syntax during the very first hour of development looked like the brick below ( core concept design ).

import|"std"|

CLASS -> SkyLine_Class {
  MODULE --> SkyLine_Module {
      cause setup = function() {
        println("hello world");
      }
  };
};

cause Main = Func() {
  SkyLine_Class::SkyLine_Module->setup();
}

This still did not seem to be modern enough and would still be quite confusing for people to grasp, but it was a good base to start with and a good base design for the language. As the language was developed and being more and more developed each hour meaning the first interpreter was implemented, the syntax completely changed and the syntax eventually became something like this.

register("std")

cause Function = Func() {
    std->prepare("hello world")
    std..::..CallOut()
    // return
    ret 
}

This was much more easier but had some base issues, the functions were just closures and never were actually full fledged functions the way a modern language would define a function. This syntax was also very confusing for libraries to work with. However, the language was slowly having its main idea and getting its point. After a total of 10 hours of pure development, non stop programming even without a break the final syntax of the language became something like this.

!- 

    This is a multi line not 

-!

register("std")

set x := "h_"; // define string   -> Type::String | Char 
set y := 1.0; // Define float     -> Type::Float64 | Float32
set z := 20; // define integeinhertingr    -> Type::Integer64 | Integer32
set b := true; // define boolean  -> Type::Boolean(true)
set c := false; // define boolean -> Type::Boolean(false)

 // functions 
 
 result_cause Information(x=y, y=x) {
   return x - y * x
 }; 
 
 Information()

Over time the syntax became much more modern still and has much more rules, but you can still see some form of weirdness and implementation to RPC with different idea's. The prime idea of RPC was to be completely different, take NO form of inspiration from any programming language in the world, take no design, take no idea, simply to be itself. This still actually held true and still does today.

Engine Porting / RPCT, RPCC, RPCIW

SkyLine wanted to try to take as much ideas from RPC as possible such as its reason for existing, its idea's and more. One of the prime benefits of RPC was how easy it was to develop with outside of syntax and rule sets. The language was purposely designed for lower level projects and would carry engine's to auto generate projects, check project configuration files, check databases, load environments, stabilize environments and much more along that list. SkyLine however wanted to take a much more different approach. Instead of porting everything over into separate engine's and having individual syntax bases it wanted to have its own code base, its own system, its own file type, its on verification system and token system based on its root syntax. This then became quite easy to think of and develop.

Introducing SLC as shown in the image below.

SkyLine Configuration Engine (SLC) in active syntax design

As you can see the engine has kept most of the base syntax well did anyway from RPC. This was the very first verison of the engine and was a base concept design for the engine. But what exactly was SLC? SLC is an entire project configuration/management engine that would interact internally with SkyLine. One thing that SkyLine ported from RPC was customization. RPC would allow you to view and change about everything which included the behavior of the error system along with the messages and output formats to the way standard libraries, files, systems and variables are allowed or modified. This would allow users to make development of their projects strict and locked down or would make the development easier and more fluid which would change the way the error system worked. In much more strict environments the error system would be 100 times more accurate than inside of a non strict environment. The engine would take this data and run it through its own interpreter since these instructions did not directly need to be compiled or need to be speedy since the engine would work prior to the project being executed. Many people ask why does the engine not use something like YAML or JSON or even CONF and INI files? The idea of the engine came from RPC and RPC did not rely on anything external which means everything internal was its own including its configuration not to mention parsing JSON and CONF files would be heavy and would take a whole system + interaction and libraries to internally interact with SkyLine if we wanted to modify the behavior of its environment. YAML would require a whole extra library since SkyLine does not want to rely on third party libraries unless they are plugins that require Gopacket or other various go libraries. This engine also gives users the option to check configuration syntax and in the most recent case the output looks like the following image.

SkyLine Configuration Engine | Recent Test

This engine is quite confusing to understand for some people and that will be explained later but the primary reason this exists is for project management.