The Kliegmean Government has approved additional funding to the Kliegmean-Nasphiliti Cooperation Foundation, allowing the Foundation the funds to open a branch of another cross-cultural institute in Nasphilitae.
The Foundation has already approached appropriate Nasphiliti officials to discuss this matter.
(OOC: I choose Option 2)
(OOC: Sedunn chooses option 4, or if not applicable, option 2. Will post ICly once I get back on track after a period of travelling.)
The United Provinces of Rhayna choose the twin cities agreement (2nd option)
Despite comprising only 3% of religious adherence in Nasphilitae, the Old Church Catholics (with silent approving support from the Peer House Pellmore and its rich coastline Thane) have set up a missionary congregation in Irisov, on the bank of the Itrysh. They’ve created a non-state, self-funded Office for Folklore Scholarships and Study alongside, offering financial help mostly to the lower classes of Kliegme.
In conjunction with support of other foreign actors towards the business class (which favours revitalisation of the dockyards and industries), the Old Church Catholics utilise their former Taborite and Adamite roots, giving them knowledge and service of Old Church Slavonic advantage against others in Nasphilitae.
Some conversion of Eastern Orthodox and Catholic population is expected among the impoverished youth.
Domestic officials have approved the cross-branching.
The Twin City status has been attended by NAACN journalists. Given that NAACN is funded by the Not-for-Profit Organisation NSBB (North South Bridge Briefs), they have utilised the agreement to set up an public educational program.
The program envisions monitoring of UPRAN’s media reporting for misinformation. Its aggregate reports are sent to the NSBB and local governments of the two cities, though remain freely accessible and available in electronic form.
The NSBB is somewhat controversial, as it’s a remnant of an old shipping service during the reign of Queen Dorothy Atkinsons. It has a tendency of obfuscating financial flow of donations it receives. During Independence, there have been (unproven) conspiratorial speculations of it being a trojan horse in service of the Nobility and Imperial Core simultaneously.
The Governor of Nasphilitae’s Central Bank in the Financial City of Agorport has expressed interest in UPRAN’s macroeconomic activities. As such, it has employed freelance financial experts to report, specifically, on interest rates and business opportunities in UPRAN’s natural resources.
Publicly known consequences:
→ Jonas Val of the ADLA grows in popularity and approval rating among the voting domestic public.
→ The AID’s campaign against PrototAutomatons NAPA-OS-XX is declassified, further decreasing it’s power in domestic politics.
→ KRYPTOS III replacement for NAPA OS XX is being considered by the domestic public administration. This might prompt the AID to develop KRYPTOS IV.
Speculated (IC):
→ Further information regarding NAPA OS XX development is speculated to be exchanged with a private digital company in Sedunn.
→ Speculations regarding an intent for intelligence sharing agreement is assumed to being considered by the HM Government, though no official has yet made any statement on the matter.
NUSPTF-RFC-1: Brief Overview and History of Computing in the Grand Duchy of Nasphilitae
|New Unified Systems Protocol Task Force | Reporting Facultative Commission (RFC-1) |
|SUBMMITER: The Prosecutor for Critical Infrastructure and Telecommunications.|
|Revision Author: Raymond Newman, Reporting for the NUSPTF (New Unified Systems Protocol Task Force)|
| Reasoning: Investigation into the “Broadband storm” phenomenon, providing background.|
→ RTCCS (Real Time Command Control Systems)
→ RICP (Restricted Insight Communications Protocol) (PROHIBITED)
→ TRSP (Telecommunications Radio Systems Protocol) (OBSOLETE) → UCSC (Unified Control Sysems Computing)
→ FANCP (Federated Access Network Control Protocol) (PROHIBITED)
→ GPAL (General Public Access Library) (OBSOLETE) → URSP (Unified Research and Science Protocol) (OBSOLETE) → NUCUP (New University Computing Unified Protocol)
→ SNS1 (Secure Networked Systems) (OBSOLETE) → SNS2 (OBSOLETE) → ISNS (Intrusive Security Network Schematic) (PROHIBITED) → STAR PROTOCOL (Moratorium lifted)
→ ACISP (Automated Census Interconnected Systemic Protocol): TCP/ACISPv4 ONLY
KRYPTOS Alpha → KRYPTOS Beta → KRYPTOS 0.1 → KRPYTOS 1.1 → KRYPTOS 1.5 → KRYPTOS 2 → KRYPTOS 3 → KRYPTOS 3.5
ARLS public beta → ARLS → RTALRS
GPAL → GPALS → URS OS → CURS OS → NCURS-OS
TRS → LLRCS → LLRCSI → CSC-OS → UCSC-OS
FPA → DFPA → DFPA OS → DFPAS (v7)
NUS OS X → NUS OS X2 → NUS OS XX
ARLv2, GPALv2, TRSLv3, LLRCv3, FPA, DFPAS, ISNS, GPALv3, ACISP-GLA
1: CS in Nasphilitae began by Eric Xors study of Daisy Days Cipher. Encryption was improved by the addition of a disc shifting randomisation mechanism and use of character glyphs instead of script. Introduction of punched cards made the machine output both encryptable and decryptable, on conditions that the serial discs and ink tapers matched among them. According to Xors notes, he received funding from the Military Junta at the time, as to attach: Broadband radio, signal detection, and dynamic vessel predicative mathematical functionality. This was KRYPTOS Alpha, also known as “the Military KRYPTOS”, released in 1931.
2: KRYPTOS Beta was funded by the AID and included support for: dynamic frequency switching, morse code, signal scrambling, long-wavelength detection of sound, movement, and colour. During The Great War, support for: navigation integration (platform integration), natural language real-time multi-switching, and signal cloaking was added. This formed KRYPTOS 01.
3: The Civil War redesigned components of previous versions, with storage of mathematical data condensed into hex, and natural language data into analogue tape imported into a unified machine, commonly called KRYPTOS 1.1
1: Alen Heidi was a mathematician who worked for Circuit Control Systems. In 1961., he patented an on-board integrated circuit switch, which reduced the size of KRYPTOS 1.1 into a wall-sized machine. This was the first Intellectual Property CS license in Nasphilitae, known as ARLv1.
2: Alen continued to work on improving the general functionality of the system and had, in 1964., received his own facility (Alen Research Labs), funded by the Pragmatist wing of the P3 Coalition. Him and his team released the first digital computer in 1966., with support for: binary data, BOM, control circuit (input terminals and output displays) as ARLS Alpha (Alen Research Labs System).
3: AIDs defunct Department Nine Unit Nine formed the “Radio and Steganography Research Group” in 1964., as a response to the perceived threat of P3 Coalitions funding the ARL. The Research Group facilitated all of its subsequent innovation by registering the RSL license. As the ARLS wasn’t covered by the original ARL license, the Research Group had reverse engineered the ARLS Alpha. Improvements made included support for: experimentation signals, real-time MRI output, surveillance and detection, and stochastic statistical analysis (primitive). This combination formed into the release of KRYPTOS 1.5 in 1967., with the Reserved Insight Communications Protocol.
4: The RICP required KRYPTOS 1.5 machines and software for data and memory to be transferred between one another. Otherwise, they would remain unreadable or undetectable by other devices or modified devices.
5: This prompted Alen Heidi to release ARLS Public Beta that same year (1967),as well as the formation of the Telecommunications Radio Systems (TRS) research group by the Royal Armed Forces. The TRS would register the Federated Access Network Control Protocol in 1968., as a patent under the TRSv1 license. The FANCP relied on (then confidential and unknown of) TRS computers which could breach encrypted tunnels of communications between other machines, and decrypt data transferred over, using radio towers. However, this was an expensive one-way communication, which could only retrieve and decipher data from other devices.
6: The GPAL (General Public Access Library) was a digitized catalogue library for cross-university indexing of repositorium’s. As the ARLS, KRYPTOS 1.5, and TRS, were all made by staff employed or trained in the universities, these innovations were a trade secret.
1: The GPAL groups goal was to further their catalogue and accelerate computing capabilities as to automate research. For this purpose, the group was set to: construct their own system, replicate and unify the eavesdropping of RICP and FANCP, and license them for academic purposes. They’ve released a model of an enclosed computing device (GPAL, 1974) which supported: search and index algorithms, verification of real-time states on stored data, push notifications of new papers released into the repositorium, multi-user support, and random access communication. It was limited by enclosed connection to both the devices and the university network. In their publication, GPAL had released the information they had gathered regarding the RICP and FANCP PII violations.
2: This prompted the TRS to investigate into the RSR group and retrieve further data from RICP communications. However, due to TRS own limitations, collaboration between the TRS and the GPAL began.
3: Another result of the publication and of the license were “homebrew” developments, namely: the Free Public Access advocacy group and the Secure Networked Systems private business interest group.
4: The TRS-GPAL collaboration was finalised in the Linked Layer Restricted Communications agreement of 1977., in preparation for the LLRCSystems and GPALSystems, respectively. In the mean-time, ARL and SNS released the ARLS under the new ARLv2 license in 1978.
5: AID Department Nine v General Public case was launched by the Supreme Court, upon receiving requests from the FPA advocacy group, the SNS private business interest group, and after the GPAL-LLRC filed a lawsuit against the RSR group of AID. Declassification of data gathered by AIDs RSL was made public in 1980. This prompted an influx of licensing pre-registrations (prior to proof of concept) to be released: The LLRCv2, the GPALv2, the FPA, the SNS. It demanded that KRYPTOS be separated from the AIDs management.
6: By 1981., Computer Science as a field was facilitated to being part of the Systems Theory category. This is atypical, as elsewhere, it had grown mostly out of Electronic Engineering.
1: Effects of pre-emptive licensing are evident, as the aforementioned (exception of FPA and SNS) never received any device nor innovation attached to them. This was largely the result of a sudden public release of the first standardised protocol by ENGeNs home wired telephone lines and equipment, then at record low prices. The Automated Interconnected Systemic Protocol version 1 (ACISPv1) became publicised in 1983. This was a set of standards created by ENGeN but followed by other television, phone, and pager service providers and manufacturers. The ACISPv1 was licensed under SNS.
2: KRYPTOS 2 was released in 1984. under the renewed TRSv2 license. It was an enterprise-targeted 16-bit computer, through was reliant on diskettes for data transfers.
3: Due to GPAL-LLRC cooperation finally completing support for Intranet communications, and ACISPv2 providing VoIP network, in 1985., an impulsion of new devices and OS occurred: RTARLS (Real Time Alen Research Labs Systems), URS (Unified Research Systems) OS under GPALv2, DFPA (Distributed Federated Public Access) OS under FPA, LLRCSI under LLRCv3.
4: KRYPTOS 2 did come to dominate the the enterprise market, while URS and LLRCSI were entrenched; The only home market alternative was the DFPA OS, which suffered from extensive bike shedding and an overly restrictive licensing. It should be noted that, modern forms of these systems are: NCURS-OS under GPALv3, DFPAS under FPA, CSC (command systems computing) OS under LLRCv3.
1: ACISPv3 was released in 1987., together with the home market being announced the release of NUS OS X by the ACISP Consortium, under a new ISNS license (Intrusive Security Network Schematic).
2: The ISNS license was the first which offered: No warranty, no liability, replaced copyright of software and code with mandatory trademark contribution, was network-oriented (as NUS OS X allowed for emulating ACISPv4 functionality), and allowed for any modification to be re-sold.
3: NUS OS X released in 1988. under the ISNS license with full support for ACISPv3 by the (former) ProtoGENESIS. At the time, ProtoGENESIS partnered with ENGeN to provide a “home server, user-developer device, modular to suit all needs”. It came with ACISPv4 emulation capabilities named the “STAR” Protocol". Essentially, it emulated/emulates a switch, in place of a hub which provided mitigation for the formerly abundant broadcast storms.
4: However, it could also transcend topographic network layers. As a response, the LLRCSI license filed a lawsuit against the ISNS license.
5: In the mean-time, KRYPTOS III was being developed with more orientation towards the home market, which also included support for the STAR protocol.
6: In LLRCSI License v ISNS License (1992), the Supreme Court was for the first time met with a case of two conflicting licenses as parties. Its ruling placed: A 32-year moratorium on the use of the STAR Protocol, obligated PrototGENESIS to release and replace NUS OS X without backwards compatibility, permanently limited LLRCSI from communication outside of its own intranet; and prohibited henceforth the use of RICP, FANCP or any other similar protocol which would be intrusive of citizen privacy; While the RAF was obligated to fund research into total transitioning of all public networking and connected systems to the ACISPv4.
7: As consequence, KRYPTOS III was delayed by 8 years, releasing in 2000., while NUS OS X2 was released in 1996. as a replacement for NUS OS X. ACISPv4 became deployed in 1995., and was made standard by 1998.
1: Due to Innsbolts 2004. introduction of the Top Level Domain firewall and 2007. Intranet-exclusive use of networking, neither KRYPTOS III nor NUS OS X2 gained as much traction as had been anticipated. Meanwhile, the ACISP Consortium suffered heavily.
2: However, ACISPv4 was revitalised in 2021., as TCP/ACISPv4, while KRYPTOS 3.5 was released in 2019. NUS OS XX was released in 2024. by the succeeding firm of PrototAutomaton. Moratorium on use of the STAR Protocol ended in 2024.
NUSPTF-RFC-02: The Bluetooth Profile (Detailed)
|New Unified Systems Protocol Task Force | Reporting Facultative Commission (RFC-02) |
|SUBMMITER: The Prosecutor for Critical Infrastructure and Telecommunications.|
|Revision Author: Raymond Newman, Reporting for the NUSPTF (New Unified Systems Protocol Task Force)|
| Reasoning: Investigation into the “Broadband storm” phenomenon, providing background.|
Bluetooth is a remote, bandwidth technology, whose default features are seemingly limited in its ordinaryintended implementation.
By design of the protocol [See “Profile”], it allows access to the entire OSI framework as part of its basic features. This is required as to allow for its intended use of supporting seamless connectivity.
It is capable of transfersing the four [see “High and Low Bluetooth”] application designs gained throughout its development.
Furthermore, by handcrafted hardware expansions, coupled with exploiting unregulated or outdated software data transmissions, it is highly modular, for its non-intended use-cases.
First we will demonstrate the list of exploits [see List of Exploits] and how they relate to the functionality Bluetooth offers. We will proceed by showcasing “High” and “Low” Power modes of the Stack, or its development phase. Finally, we will use the UML or visuals [see “Profile once again”] for better approachability.
Seamless connectivity allows for its use-cases by the various features it depends on. We will now present a list. It is recommended to read them chronologically, as the end might seem senseless. Like always, if you do not know what some of these terms mean, you may always search them. We have provided a minimal explanation needed for this context.
A wireless bridging of two ethernet networks is extensively used in “PROFINET”. Recalling Audio transmission of 64, 16 and 56 bits, coupled with FTP, Scatternets, Remote control and display, Data streaming, Telephony, Serial communication, and real-time connectivity — Packets can be sent to any link, which are limited in size.
These packets arrive in low profile or band, with LC3 Codec. However, while high band Bluetooth supports LC3 Codec implementation as intended; low band Bluetooth uses CRC encryption.
|Specification|High|Low|
|-----------------------|
|Ramge|100m+|-100m|
|--------------------------------|
|Data rate|1-3 Mbits/s|Up to 1 Mbits/s|
|--------------------------------|
|Throughput|0.7-21 Mbits/s|0.3-1.4 Mbits/s|
|--------------------------------|
|Active slaves|7|Unregulated|
|--------------------------------|
|Security|56-bit modifiable through the Application layer|128-bit AES modifiable through the Application layer|
|--------------------------------|
|Control Access|Adaptive hopping, FEC, then ACK|Adaptive hopping, 24-bit CRC, 32-bit or header check|
|--------------------------------|
|Network topology|Scatternet to Cellular|Scatternet to Ethernet|
|----------------------------------------------------------------------|
Those packets arrive in low profile with CRC encryption. Serialisation of a Bluetooth controller is shorter than any other connectivity UID profile. Furthermore, it can merely be a mask if used in PPP transfers of data. This may further be obfuscated if the PPP inbound is connected through a switch, thus disallowing traceability.
We will first cover some basic things such as Byte Frame formats, specifically focusing on PPP then Ethernet and Wireless; Finally showcasing how the Bluetooth Profile design looks. If We do not address these by order, it will not be comprehensive, why the Bluetooth Profile or Stack or Protocol design is VERY insecure.
In bit oriented framing, data is a sequence of bits, transferred to upper OSI layers. There exist two implementations of access control. HDLC and SDLC. We are interested in the HDLC here.
In byte oriented framing, data is a sequence of bytes ( ! sequenced bits). There exist numerous access control implementations. We are interested in BISYNC also called BSC, and PPP.
HDLC Frame Format:
|BEGIN|Header|Body-Network layer|CRC|END|
|---------------------------------------|
|8 bits|16 bits|UNKNOWN|16 bits|8 bits|
|01111110|Address Control Dependent|UNKNOWN|Error Detection|01111110|
Address Control Dependent determines the type of frame. I-Frames of 0, S-Frames of 10, or U-Frames of 11 bits.
BISYNC Frame Format:
|SYN|SYN|SOH|Header-Network|STX|Body-Network|ETX|CRC| |---------------------------------------------------| |8 bits|8 bits|8 bits|UNKNOWN|8 bits|UNKNOWN|8 bits|16 bits|
To be clear, “STX” stands for “Start of Text”; while "ETC stands for “End of Text”. This means that the body, which is in the network (upper) layer, is in plain text. Likewise, “SOH” is “START OF HEADER”.
This is a very insecure frame format and its main vulnerability is how prone it is to DLE, which refers to exactly what it says when hovered over it. It escapes the Data Link Layer.
|Flag|Address|Control|Protocol|Payload-Network|Checksum|Flag|
|---------------------------------------------|
|8 bits|8 bits|8 bits|16 bits|UNKNOWN|16 bits|8 bits|
|01111110|11111111|11000000|1 or 2 bytes|UNKNOWN|HIDDEN|01111110|
|---------------------------------------------------------------|
Address (11111111)
: It is the broadcast address.
CONTROL (11000000)
: IT IS ALWAYS this.
Protocol:
: It can be 1 or 2 bytes. This defines the type of data, WITHIN THE PAYLOAD.
We will refer to “bits” as “bits” and to “bytes” as “B” from hereon.
LEN and PAD
: LEN is the length of the frame payload. It is of 2B in size. It serves to tell the PAD how much data is being received. Minimum is 512bits which is 64B. Maximum frame length is 12 144 bits which is 1518B.
: PAD then adjusts accordingly. The reason why is, when you receive an internet connection, your own device likely cannot receive as much data as the ISP is sending. For this reason, the Minimum is 46B, while the maximum is 1500B.
If you are counting and paying attention to this RFC as you should, you will notice consistency of what we mentioned in exploits.
|Desination Address|Source Adress|LEN|PAD|CRC|
|--------------------------------------------|
|6B|6B|2B|46-1500B|CRC|
|----------------------------------------------|
An “Ethernet Address” has the BOM of the most significant byte being the first. For instance;
06:01:02:01:2C:4B <=> 6B <=> 12HEX <=> 48bits.
WI-FI:
As observable in the above image, Wi-Fi’s frame format has its most significant byte as “Frame Control”. This allows for exploits.
|Frame Control|Duration|Add1|Add2|Add3|SEQ|Add4|Data|Checksum|
|------------------------------------------------------------|
|-----------------------------------------------------------|
|2B|2B|6B|6B|6B|2B|6B|23x2 standard|4B|
|------------------------------------------------------------|
|-------------------------| {(->down
|-|--Application Layer--|-| )"Application Layers"}
|A|---------------------|C| -
|U|LLC|RFCOMM|TELE|SerDi|O| {()"Middleware"}
|D|******Logical********|N| -
|I|******Link***********|T| {(->down
|O|******Layer**********|R| (->down
|-----------------------|O| )->down
|********BASEBAND*******|L| )->down
|-------------------------| ->"Data Link Layer"}
|*******Physical (RADIO)**| {())"Physical Layer"}