Skip to content
This repository has been archived by the owner on Jan 10, 2023. It is now read-only.

Add pyadb keygen command to generate keypairs #144

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

joeleong
Copy link

@joeleong joeleong commented Jan 7, 2019

Should address #95 and #131

  • (I think) I reimplemented the custom public key structure from AOSP.
  • Add pyadb keygen command to mimic adb keygen

Note: I did update the dependencies since the pubkey code uses pycryptodome and six.
I was having problems similar to #109, so I think you need M2Crypto or rsa and pycryptodome (2 libraries). There is probably a way to implement the pubkey stuff with the other crypto libraries but I didn't bother. Happy to change things if necessary.

@coveralls
Copy link

coveralls commented Jan 7, 2019

Coverage Status

Coverage decreased (-2.2%) to 41.385% when pulling 01614ea on joeleong:add-custom-pubkey-encoding into d0be33c on google:master.

@Halastra
Copy link
Contributor

Let's help this thing reach master!

  1. I'm not experienced in creating proper test cases, but I'm willing to try.
  2. I have a minor improvement suggestion for struct usage in decode_pubkey (will post proposed patch soon).
  3. I'd also like to try and make this work with the cryptography library (recently supported by this project).

Hopefully I'll be able to do it soon.
Thanks for your great work!

Copy link
Contributor

@Halastra Halastra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Started a review for adb/android_pubkey.py.
This is currently just a suggested cleanup, to increase readability for future reviews.
I will soon be inspecting the RSA-related code, with regards to:

  • The correctness of the algorithm
  • Library usage (specifically, porting to cryptography if possible).

Let me know what you think!

adb/android_pubkey.py Show resolved Hide resolved
adb/android_pubkey.py Outdated Show resolved Hide resolved
adb/android_pubkey.py Outdated Show resolved Hide resolved
adb/android_pubkey.py Outdated Show resolved Hide resolved
adb/android_pubkey.py Outdated Show resolved Hide resolved
adb/android_pubkey.py Show resolved Hide resolved
adb/android_pubkey.py Show resolved Hide resolved
adb/android_pubkey.py Show resolved Hide resolved
def _to_bytes(n, length, endianess='big'):
"""partial python2 compatibility with int.to_bytes
https://stackoverflow.com/a/20793663"""
if six.PY2:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Verify endianness argument:
assert endianess in ('little', 'big')

setup.py Outdated Show resolved Hide resolved
Copy link
Author

@joeleong joeleong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey! Thanks for the review. I like your changes overall.

The only ones I'm unsure about are the size_in changes.
I'm not sure it's much clearer that way and might just be adding some unnecessary machinery, especially because it looks like its only used in two places. I'm probably open to it if you feel strongly about it, but how would you feel about leaving it the way it is, but maybe adding some comments to make it clearer?

I'll take a closer look when I get a chance and probably incorporate most/all of them.
It should be pretty easy to port to the other crypto lib but I haven't looked at it specifically.
I can help with that if you'd like.
The tests are probably most important.

@Halastra
Copy link
Contributor

Hi. I completely agree :)
Let me explain, and then tell me what you think. Maybe it's redundant after all.

The size_in function lets you convert sizes between different units.
In our case, we convert 2048 bits to 256 bytes and then 64 words.

But what if the modulus length is not a multiple of 32 or 8 bits?
e.g. 2047 bits would still require 256 bytes, and 2040 bits would require 255 bytes which are still 64 words.

The size_in is a simple formula which handles these cases.
I don't really know cryptography really well. Perhaps these cases are irrelevant by design.

Also agreed on the tests, probably most important. I'll try to get to those soon 👍

joeleong added a commit to joeleong/python-adb that referenced this pull request Jul 24, 2019
Co-Authored-By: Halastra <turchy@gmail.com>
@googlebot
Copy link

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

joeleong and others added 3 commits July 24, 2019 15:42
With help from @Halastra suggestions from code review of google#144

- Define ANDROID_RSAPUBLICKEY_STRUCT
- Remove use of six package
- Fix some flake8 warnings

Co-Authored-By: Halastra <turchy@gmail.com>
@joeleong
Copy link
Author

joeleong commented Jul 25, 2019

I rebased and incorporated most of your suggestions in 0791b9.
I think I'd prefer to skip the size_in suggestion for now, just because they're constants.
I also forgot to include your suggestion about asserting the endianess argument, but I don't think that's a big deal since it defaults to little if gibberish is passed and its a local function anyway.

I also ported it to use py-cryptography instead of pycryptodome.

Let me know what you think!

@Halastra
Copy link
Contributor

@googlebot I consent

@googlebot
Copy link

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

@Halastra
Copy link
Contributor

Halastra commented Nov 28, 2019

Well that took longer than expected.. but here goes.
A few quick notes:

Add the following code under test/test_cryptography.py:

import unittest
from adb import sign_cryptography
from adb import android_pubkey
from tempfile import TemporaryDirectory
from os import path

class CryptographyTest(unittest.TestCase):
    def testKeygenAndSigner(self):
        private_key_file_name = 'adbkey'
        with TemporaryDirectory() as temp_dir:
            private_key_file_path = path.join(
                temp_dir, 
                private_key_file_name
            )
            android_pubkey.keygen(private_key_file_path)
            signer = sign_cryptography.CryptographySigner(private_key_file_path)

Regarding your previous notes:

  • I really like your work!
  • I might be tempted to add the size_in function in a future PR.
  • Same goes for the endianess (+ better default to 'little', to match bytes.fromhex)

Please add the above changes. I will review and approve them (promise!).

@joeleong
Copy link
Author

Hey thanks for your suggestions!

I haven't really been keeping up with this project, particularly #167 and all the stuff @JeffLIrion has been contributing, so it is a little unclear to me what the best path forward is. It's very possible his PR's could supersede this one.

I'm happy to incorporate your suggestions to this PR either directly or you can maybe submit a PR to https://github.com/joeleong/python-adb/tree/add-custom-pubkey-encoding and I'll push your commits here.

@Halastra
Copy link
Contributor

You are right in your observations. His work is indeed an improvement in many areas!
But since there's still no apparent USB support in adb-shell, I'll be using this package.

So I guess I'll submit a PR to your repository as you suggested.

@JeffLIrion
Copy link
Contributor

This pull request contains @joeleong's key generation code as well as tests: #170

I also copied it over to adb-shell (and attributed it to @joeleong), along with tests.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants