FlowCoder is a software framework for rapid visual prototyping, testing, fuzzing and verification of networking stacks at all stack layers. The packet processing logic is defined by an executable flowchart built from graphical blocks interconnected with software wires. FlowCoder can play a role of a client, server, or MITM network nodes.
Q: What network stacks/protocols are supported by FlowCoder today?
A: If you can decode the stack with WireEdit, it is supported by FlowCoder.
XFL Studio or just Studio, the main element of FlowCoder.
XFL (EXecutable Flowchart Language) is a Domain-Specific Language (DSL) for programming, fuzzing and pen testing of computer networks. XFL makes creating of packet driven state machines easy and fast, with no or minimum amount of coding.
XFL is a Visual Programming Language. Its source code is a flowchart. The edges of the flowchart graph indicates control flow, while vertices send/receive network packets and perform operations on the packets’ data. XFL primitives are called Blocks and Connections.
XFL supports automatic parallelization and is highly scalable.
XFL Flowchart, or just a Flowchart is a central element of FlowCoder. It defines an executeble finite state machine with network packets as inputs/outputs.
A Flowchart can execute under Win10 and Linux.
Multiple copies (instances) of a Flowchart can execute concurrently.
Atomic graphical primitives comprising a Flowchart are called Blocks. Blocks are placed on a background grid of XFL Canvas worksheets.
Blocks are used for sending and receiving network packets, manipulating packets data, making decisions, controlling timers, calling scripts, etc.
Blocks share data with other Blocks via variables.
XFL Canvas is the pane in the center of the Studio window where a Flowchart is drawn. See more about XFL Canvas …
Blocks are connected by a “wire” built out of background grid segments. For a directly connected Block pair, an egress point of one Block is connected to an ingress point of the other with no blocks in between.
Connections are built by selecting segments of the background grid with Connector pointer tool (black arrow) from the toolbar.
In this document we say “Block B is a child of Block A” or “Block A is a parent of Block B”, if Block A egress point is connected to Block B ingress point with no Blocks in between. Sometimes we use an equivalent notation of “Block B is a direct descendant of Block A”. It is possible for a Block to be both a parent and a child of another Block.
A Flowchart supports variables of primitive (integer, character string, etc.) and complex (arrays, structures, etc.) types. Variables of any data type present at a supported protocol specs can be defined. Variable scope can be local or global (shared by all instances).
Variables are used to send data into the network, capture incoming data on the receive side, store and process data internally. Read more on variables…
Instances are concurrent threads of control executing a Flowchart. Instances execute the same state machine (stack logic described by the Flowchart) but have separate contexts (env, local data, etc.). One can think of instances as concurrent calls/transactions.
Read more about instances…
Point of Control and Observation - point in the protocol stack, where FlowCoder can intercept network data. Usually a PCO is located at the point where PDUs of a certain stack layer are exchanged over the network, and is named after that layer - like HTTP, FTP, DNS, etc.
Sometimes a PCO resides at the top of a network service, and in this case it operates not with actual PDUs, but with local service primitives. Such PCOs usually have “Service” postfix in their names.
Protocol Data Unit - a basic unit of exchange at a given PCO. PDUs are “sent at PCO” and “received at PCO”. E.g., HTTP.GET and DNS.Response are PDUs at HTTP and DNS PCOs respectively.