All this data is potentially out of date, and should be taken with a truckload of salt
This research is focused on establishing a number of standardised communication protocols for use in our attempts to communicate with the Rogue Drones, we should look into as many different types of software encoding and encryption protocols as possible as we do not know which will be accepted or how many layers of encryption there will be.
Initial proposal for protocols
1. Should a connection be established after sending out strings of encrypted data, it is very important that the sender keeps using the successful encryption data format instead of swapping to another format of data. The last communication broke down after the sender switched to plain text.
2. Should a connection be established, the individual(s) should attempt to contact a member of the Rogue Drone Division if one is not already present.
3. Should a connection be established, the individual(s) participating should act in a friendly/neutral manner against the drones and not express hostility or impatience of any sort during the communications.
4. Should a connection be established, the individual(s) should not accept any unsecure data packages from the drones over normal comms, as it might be potentially viral in nature and current firewalls may prove ineffective.
5. Should a connection be established, the individual(s) should consult the list of Agenda and Questions For Rogue Drones for current outstanding items of intrest to the Arek'Jaalan project as a whole in addition to any questions they themselves may ask.
6. Should a connection be established, the individual(s) should consult the list of Standardised Enquiry Responses For Rogue Drones, if an official response is not listed the individual(s) should attempt to contact a member of the Rogue Drone Division if one is not already present for advice.
7. Should a connection be established, if the drones ask the individual(s) inside a drone complex, the individual(s) should be wary of it as it might be an attempt to take over the Capsuleer's vessel, and potentially the Capsuleer himself. However we encourage this kind of activity as it will almost certainly provide useful information and the risk should be minimal to a prepared Capsuleer in a fully armed vessel.
8. Should a connection be established, individual(s) should log the entire event to Current Rogue Drone Communications for archiving and analysis by the Rogue Drone Division and the community at large.
9. Should a connection be established, and the individual(s) involved wish to try and communicate with the Drones in an easier manner, it is recommended that a Primer on our language be sent to them encrypted in the same format currently being used to talk to them with. This Primer should include multiple versions of itself encoded in all known ways and combinations possible as this should ensure the Drones can decrypt it successfully.
Encoding And Encryption
In the Dead End transmissions, the transmitting entity responded to binary code, and the communications broke down after the capsuleer in question switched to plain text (although it is at the present moment unknown if this is what caused the comms to fail). The sending entity sent out lines that were in base64 language, that could be translated to ASCII and from that, to plain text. It seems that even though the sending entity (titled S.E.1 for practicality from here on out) responded in base64, it can understand binary.
Binary code is the system of representing text or computer processor instructions by the use of a two digit number system. This system is composed of only the number 0, representing the off state, and the number 1, representing on state, combined in groups of 8. These groups of 8 bits can represent up to 256 different values and can correspond to a variety of different symbols, letters or instructions.
Binary code is the most common encoding technique encountered when interacting with Rogue Drones, many suspect this is due to their original software having been writing in Binary.
Base64 is a group of similar encoding schemes that represent binary data in an ASCII string format by translating it into a radix-64 representation. The Base64 term originates from a specific MIME content transfer encoding.
Base64 encoding schemes are commonly used when there is a need to encode binary data that needs be stored and transferred over media that are designed to deal with textual data. This is to ensure that the data remains intact without modification during transport.
ASCII is a character-encoding scheme based on the ordering of the English alphabet. ASCII codes represent text in computers, communications equipment, and other devices that use text. Most modern character-encoding schemes are based on ASCII, though they support many more characters than ASCII does.
When decoding received transmissions it should be a relatively simple task of identifying which encoding method has been used and running the sequence through a standard translator program. In the case of the transmissions received in the Dead End system 2 layers of encryption were used so be prepared for this eventuality.
To help those who may encounter encrypted data I have linked a simple translation matrix here.
As an example to decode a transmission received in the Dead End system you would need to perform the following using the linked matrix. First copy and paste the original data string into the Base 64 box (lower left) and hit decode, you will then see in the Text box (upper left) the translated sequence. As you can see gives us a new sequence of encrypted data which we must now translate, copy and paste this data string into the Dec / Char Box (center bottom) and hit decode once again. Now if you look in the Text box (upper left) you should see the unencrypted data in its plain text form. This entire process can be reveresed to encode any replies back into the same format as the orginal received data string.