This command will be sent by adbd to notify the client that the
connection will be over TLS.
When client connects, it will send the CNXN packet, as usual. If the
server connection has TLS enabled, it will send the A_STLS packet
(regardless of whether auth is required). At this point, the client's
only valid response is to send a A_STLS packet. Once both sides have
exchanged the A_STLS packet, both will start the TLS handshake.
If auth is required, then the client will receive a CertificateRequest
with a list of known public keys (SHA256 hash) that it can use in its
certificate. Otherwise, the list will be empty and the client can assume
that either any key will work, or none will work.
If the handshake was successful, the server will send the CNXN packet
and the usual adb protocol is resumed over TLS. If the handshake failed,
both sides will disconnect, as there's no point to retry because the
server's known keys have already been communicated.
Bug: 111434128
Test: WIP; will add to adb_test.py/adb_device.py.
Enable wireless debugging in the Settings, then 'adb connect
<ip>:<port>'. Connection should succeed if key is in keystore. Used
wireshark to check for packet encryption.
Change-Id: I3d60647491c6c6b92297e4f628707a6457fa9420
Rename the existing Connection to BlockingConnection, add a nonblocking
Connection, and add an adapter between the two, to enable future work
to reduce the impedance mismatch from implementing a blocking interface
on top of nonblocking primitives.
While we're here, delete A_SYNC, and remove one layer of pipes when
sending a packet (replacing it with a condition variable when using
BlockingConnectionAdapter).
Test: python test_device.py, manually plugging/unplugging devices
Change-Id: Ieac2bf937471d9d494075575f07e53b589aba20a
Try to improve the documentation by adding, for each commands explained
on the adb/protocol.txt file (CONNECT, WRITE, AUTH, ...), the
corresponding constant used by the protocol (A_CNXN, A_WRTE,
A_AUTH, ...).
I've seen a few engineers having problems matching these both
information by simply reading the doc and they loose time before
getting it. Most of the time they understand it by finally reading the
source code.
By adding this simple information at the end of each command
description I'm sure it will help onboarding developers to
understand more quickly the way the ADB protocol works.
Change-Id: Ibb949fd6a6d34a2bc7f47f0e7af2f57138c9a369
Signed-off-by: Eyal Lezmy <eyal.lezmy@gmail.com>
The reason behing this change is to increase the adb push/pull speed
with reduceing the number of packets sent between the host and the
device because the communication is heavily bound by packet latency.
The change maintains two way compatibility in the communication
protocol with negotiating a packet size between the target and the
host with the CONNECT packets.
After this change the push/pull speeds improved significantly
(measured from Linux-x86_64 with 100MB of data):
| Old push | Old pull || New push | New pull |
-----------------------------------------------------------
Hammerhead | 4.6 MB/s | 3.9 MB/s || 13.1 MB/s | 16.5 MB/s |
-----------------------------------------------------------
Volantis | 6.0 MB/s | 6.2 MS/s || 25.9 MB/s | 29.0 MB/s |
-----------------------------------------------------------
Fugu | 6.0 MB/s | 5.1 MB/s || 27.9 MB/s | 33.2 MB/s |
-----------------------------------------------------------
Change-Id: Id9625de31266e43394289e325c7e7e473379c5d8
Prior to the documentation told users to pass 0 in as
the first argument to write messages, when they should
be outting in their local-id. It is now corrected.
Change-Id: Ia2c6c84f95383baa5ca471493a29a39e5173b604
Signed-off-by: Derrick Bonafilia <dbonafilia@google.com>
Secure adb using a public key authentication, to allow USB debugging
only from authorized hosts.
When a device is connected to an unauthorized host, the adb daemon sends
the user public key to the device. A popup is shown to ask the user to
allow debugging once or permanantly from the host. The public key is
installed on the device in the later case. Other keys may be installed
at build time.
On the host, the user public/private key pair is automatically generated,
if it does not exist, when the adb daemon starts and is stored in
$HOME/.android/adb_key(.pub) or in $ANDROID_SDK_HOME on windows. If needed,
the ADB_KEYS_PATH env variable may be set to a :-separated (; under
Windows) list of private keys, e.g. company-wide or vendor keys.
On the device, vendors public keys are installed at build time in
/adb_keys. User-installed keys are stored in /data/misc/adb/adb_keys.
ADB Protocol change:
If the device needs to authenticate the host, it replies to CNXN
packets with an AUTH packet. The AUTH packet payload is a random token.
The host signs the token with one of its private keys and sends an AUTH(0)
packet. If the signature verification succeeds, the device replies with
a CNXN packet. Otherwise, it sends a new AUTH packet with a new token so
that the host can retry with another private key. Once the host has tried
all its keys, it can send an AUTH(1) packet with a public key as
payload. adbd then sends the public key to the framework (if it has been
started) for confirmation.
Change-Id: I4e84d7621da956f66ff657245901bdaefead8395
Secure adb using a public key authentication, to allow USB debugging
only from authorized hosts.
When a device is connected to an unauthorized host, the adb daemon sends
the user public key to the device. A popup is shown to ask the user to
allow debugging once or permanantly from the host. The public key is
installed on the device in the later case. Other keys may be installed
at build time.
On the host, the user public/private key pair is automatically generated,
if it does not exist, when the adb daemon starts and is stored in
$HOME/.android/adb_key(.pub) or in $ANDROID_SDK_HOME on windows. If needed,
the ADB_KEYS_PATH env variable may be set to a ;-separated list of private
keys, e.g. company-wide or vendor keys.
On the device, vendors public keys are installed at build time in
/adb_keys. User-installed keys are stored in /data/misc/adb/adb_keys.
ADB Protocol change:
If the device needs to authenticate the host, it replies to CNXN
packets with an AUTH packet. The AUTH packet payload is a random token.
The host signs the token with one of its private keys and sends an AUTH(0)
packet. If the signature verification succeeds, the device replies with
a CNXN packet. Otherwise, it sends a new AUTH packet with a new token so
that the host can retry with another private key. Once the host has tried
all its keys, it can send an AUTH(1) packet with a public key as
payload. adbd then sends the public key to the framework (if it has been
started) for confirmation.
Change-Id: Idce931a7bfe4ce878428eaa47838e5184ac6073f
protocol.txt says that the connect message should have three
fields:
<systemtype>:<serialno>:<banner>
In reality, what is transmitted is simply:
<systemtype>::
The serialno is obtained via other means so doesn't really need
to be a part of the connect message. This change puts the
ro.product.name, ro.product.model and ro.product.device
properties in the <banner> for devices. Each property is
terminated by a semicolon (;) with the key and value separated by
an equals sign (=). Example message:
device::ro.product.name=<prd>;ro.product.model=<mdl>;ro.product.device=<dev>;
Making this change will enable the device list to provide more
information to the user and to give the potential for being able
to select which device to talk to with the -s option.
Change-Id: I09200decde4facb8fc9b4056fdae910155f2bcb9
Signed-off-by: Scott Anderson <saa@android.com>
