git / line-protocol

Commit e24e983b4088ae5a28ea042f83fad370cbc92231

Authored by Matti Virkkunen
1 parent 71ef833b

Started documenting the Android protocol.

Inline Side-by-side
Showing 1 changed file with 88 additions and 0 deletions
line-android.thrift 0 → 100644
  View file @e24e983
  1 +LINE instant messenger protocol - Android version
  2 +=================================================
  3 +
  4 +Matti Virkkunen <[email protected]>
  5 +
  6 +Document is accurate as of 2015-04-02 (LINE 5.0.4)
  7 +
  8 +This document describes the custom protocols used by the Android version of LINE. It's meant to be a
  9 +companion to line-protocol.md, as it mostly describes the differences.
  10 +
  11 +Overview
  12 +--------
  13 +
  14 +The Android version of LINE also uses Apache Thrift as the serialization format for most of its
  15 +communications. There are however significant differences. This makes the total protocol suite more
  16 +complicated, but it saves a lot of bandwidth, which is presumably their main goal. The mobile
  17 +versions of LINE have vastly more users than the desktop versions, so it makes sense to primarily
  18 +optimize them.
  19 +
  20 +SPDY instead of HTTP
  21 +--------------------
  22 +
  23 +The Android client primarily uses SPDY (Draft 2) instead of HTTP. This has numerous advantages, for
  24 +instance the ability to use one TCP stream for multiple transactions and header compression.
  25 +
  26 +Custom SPDY encryption
  27 +----------------------
  28 +
  29 +SPDY is normally encrypted using standard SSL, but LINE implements its own custom encryption. Their
  30 +justification for it is that it does away with SSL handshakes and overhead and therefore puts less
  31 +of a burder on mobile devices and networks.
  32 +
  33 +The encryption scheme encrypts the body part of the SPDY request only. The standard headers portion
  34 +of SPDY is left unencrypted, but the body can also optionally contain encrypted headers.
  35 +
  36 +When the client connects to the server, it generates a 128 bit random key, encrypts it with an RSA
  37 +public key, and sends it to the server as a header with the first request. This key is used by both
  38 +the client and the server to encrypt the body with AES in CBC mode with a fixed IV. The AES context
  39 +is reset for each message. Cryptanalysts may have something to say about the fixed IV and new
  40 +context for each message.
  41 +
  42 +The AES encrypted messages are signed with a custom 64-bit MAC called legy_hmac, which is curiously
  43 +only available in native code. I haven't yet analyzed how it works. I am not sure if the native
  44 +library approach is taken to enable code re-use between platforms, or as some futile attempt to add
  45 +security by obscurity.
  46 +
  47 +(TODO)
  48 +
  49 +(TODO attach: RSA key and AES IV)
  50 +
  51 +(TODO add example code: custom encryption)
  52 +
  53 +(TODO add example code: legy_hmac implementation)
  54 +
  55 +Authentication
  56 +--------------
  57 +
  58 +The mobile version of LINE does not require the user to manually register an account - one is
  59 +automatically generated when the app is first installed. Therefore the user authentication method is
  60 +also different.
  61 +
  62 +The mobile client stores a 15 byte unique key which is used to authenticate it to the LINE servers.
  63 +The key is stored in an encrypted settings database, but obviously since the app needs to be able to
  64 +read it, this is easy to circumvent (it turns out they essentially use an 8-bit encryption key,
  65 +which is generated from the phone's ANDROID_ID value).
  66 +
  67 +The unique key along with the user ID is used to generate a hash that is used for authentication.
  68 +
  69 +(TODO)
  70 +
  71 +(TODO add example code: mobile authentication token generation)
  72 +
  73 +(TODO add example code: obtaining the mobile auth key from the LINE settings SQLite database)
  74 +
  75 +Custom Thrift protocol
  76 +----------------------
  77 +
  78 +The custom protocol, among other things, stores GUIDs (which are used as user IDs throughout the
  79 +system) as binary instead of strings, halving their size.
  80 +
  81 +(TODO)
  82 +
  83 +Compact message protocol
  84 +------------------------
  85 +
  86 +There is a custom, presumably non-Thrift binary protocol for sending messages.
  87 +
  88 +(TODO)
... ...