Skip to content

Instantly share code, notes, and snippets.

@xcvista xcvista/gist:5215804
Created Mar 21, 2013

Embed
What would you like to do?
WebFusion Client Coupling Protocol 1.0
Modified from MessHall 1.1 protocol.
Part 1: Common format of the package
As described in C struct:
typedef struct __MHBinaryPackage
{
uint32_t magic; // = 0xEA5EEA5E ("Ease, ease")
uint16_t flags; // Not used for now, unless indication failure.
uint16_t operation; // Subprotocol type really.
uint64_t payload_length; // Obvious thing.
uint8_t payload[]; // Real payload.
} MHBinaryPackage;
Part 2: Device discovery and key exchange.
This is the procedure how the host (e.g. a PC) discover a device (e.g a smartphone) and
safely performs a key exchange with the device with user intervention and with
confirmation in place.
Packet sequence: (H = Host, D = Device)
Seq. Direction Proto. Description (Described in JSON, transmitted in binary)
1: H --> D (Bc.) UDP (B) Host hello: {operation: hello}
2: H <-- D UDP Device hello. {operation: alloc, name: (string)}
3: H --- - --- User choose the device from a list.
4: H --> D TCP Connection. {operation: init}
5: H <-- D TCP Challenge. {operation: challenge,
data: (256-bit random: R1)}
6: - --- D --- Device display connection confirmation code.
7: H --- - --- User type in the code on host.
8: H --> D TCP Challenge response.
{operation: challengeResponse,
data: AES256(key: SHA256(code),
data: R1)}
9a: H <-- D TCP Connect establishment.
{operation: challengeOK} (if the response
matches, or)
9a: H <-- D TCP Connect rejection.
{operation: challengeRejected}
10: H --> D TCP Key exchange. {operation: keyAssign,
data: AES256(key: SHA256(code),
data: (256-bit R2))}
11: H <-- D TCP Key confirm. {operation: keyConfirm,
data: AES256(key: R2,
data: code+string)}
12a: H --> D TCP Key confirm rejected.
{operation: keyRejected} (if code mismatch
or)
12b: H <-> D TCP Communications are now encrypted using R2 as AES256 key.
{operation: (according to the payload),
data: AES256(key: R2, data:…)}
Security is based on the difficulty of breaking AES256 algorithm with plaintext/ciphertext
pair only, since the code is never transmitted over the air.
Part 2: Session transfer.
Session transferring is simpler as a simple transfer of all involved HTTP cookies. It is
done by transferring all cookies encoded as a JSON dictionary. The transfer is done over
the previously established encrypted channel.
Part 3: Notification transfer.
Transferring notifications would require transferring data that is not usually cross-
platform compatible. This would require a rewritten FKJSONKeyedArchiver &
FKJSONKeyedUnarchiver classes, as well as a notification capture & re-transmit code. This
feature is largely debug-only, thus can be done in ad-hoc fashion by adding categories
to existing classes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.