Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a CI and a basic integration test #194

Merged
merged 19 commits into from
Mar 25, 2020
Merged

Add a CI and a basic integration test #194

merged 19 commits into from
Mar 25, 2020

Conversation

Res260
Copy link
Collaborator

@Res260 Res260 commented Mar 19, 2020

I had a burst of motivation and did this, I don't really care if you want it or not but offer it nonetheless, I mostly did this as a personnal challenge :)

Basically, I added a Github Actions workflow that does two things on push and on Pull Request on the repo:
1. Try to build the Docker Image.
2. Try to install PyRDP and run a new integration test I made on ubuntu and windows.
3. Show a coverage report and fail it it falls under 50%

This test is based on an RDP session I just recorded which try to use as most RDP features that PyRDP supports as possible.

Right now, it does assertions on these:

  • Asserts that PyRDP correctly build the requested virtual channels;
  • Asserts that PyRDP sees a clipboard PDU with the pasted data;
  • Asserts that the number of mouse clicks parsed matches the number of total clicks;
  • Asserts that PyRDP clearly sees some text that was typed on the keyboard at the end of the session;

Beyond those assertions, it executes a large portion of the PyRDP codebase:
image
image

It does NOT test these:

  • TLS, RC4 and anything else crypto
  • Logging
  • Replays
  • Device Redirection Channel
  • Executables in the "bin" folders
  • The first two packets of the RDP connection

This test could be better (and can be improved in the future), but I believe it will catch most low-hanging fruits/bugs!

Because of (what I believe is) a synchronization problem, I disabled testing for the device redirection channel.

It is heavily based on the pyrdp-replay branch (requires scapy as well).

@Res260 Res260 added the enhancement New feature or request label Mar 19, 2020
@Res260 Res260 requested review from obilodeau and alxbl March 19, 2020 02:47
@alxbl
Copy link
Collaborator

alxbl commented Mar 19, 2020

This is very cool! I think it's a great first step towards having proper unit testing and integration testing in PyRDP. I have a few comments but the general approach looks good to me.

Good use of dependency injection for the configs, too.

.github/workflows/ci.yml Show resolved Hide resolved
test/test.py Outdated Show resolved Hide resolved
test/test.py Outdated Show resolved Hide resolved
test/test.py Outdated Show resolved Hide resolved
test/test.py Outdated Show resolved Hide resolved
test/test.py Outdated Show resolved Hide resolved
test/test.py Outdated Show resolved Hide resolved
test/test.py Outdated Show resolved Hide resolved
@alxbl
Copy link
Collaborator

alxbl commented Mar 20, 2020

If you can rebase this and --force-with-lease to clean up the commit history, I'd be willing to merge this now.

@Res260
Copy link
Collaborator Author

Res260 commented Mar 20, 2020

@alxbl wouldn't squash and merge do the job?

Edit: wording as the first message seemed passive-agressive

@obilodeau
Copy link
Collaborator

@alxbl I would like to review before you merge, please. I'm very interested in GitHub Actions beyond just this repo.

@alxbl
Copy link
Collaborator

alxbl commented Mar 20, 2020

@alxbl wouldn't squash and merge do the job?

Edit: wording as the first message seemed passive-agressive

It will, but your commits will disappear. I was offering you to keep your commit history in master.

@Res260
Copy link
Collaborator Author

Res260 commented Mar 20, 2020

Ahhh I don't really care about having multiple commits for this PR, and the branch is still kept in GitHub if we really need the information

@alxbl alxbl added this to the vNext milestone Mar 24, 2020
Copy link
Collaborator

@obilodeau obilodeau left a comment

Choose a reason for hiding this comment

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

This is amazing! Thanks a lot for taking the time to build it.

Some general notes:

  • I'm not fond of the 16-megabyte pcap addition. It's large. I suspect it can be compressed efficiently (especially if it's the text PDUs). If the compression ratio is good, I'm probably going to compress it and decompress it from the test suite when testing.
  • How did you do the coverage analysis? Can you provide instructions in docs/devel.adoc, please.

.github/workflows/ci.yml Outdated Show resolved Hide resolved
pyrdp/mitm/BasePathMITM.py Outdated Show resolved Hide resolved


class RDPMITM:
"""
Main MITM class. The job of this class is to orchestrate the components for all the protocols.
"""

def __init__(self, mainLogger: SessionLogger, crawlerLogger: SessionLogger, config: MITMConfig):
def __init__(self, mainLogger: SessionLogger, crawlerLogger: SessionLogger, config: MITMConfig, state: RDPMITMState=None, recorder: Recorder=None):
Copy link
Collaborator

Choose a reason for hiding this comment

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

Note to self: this is duplicated from another active PR

return ".".join(str(b) for b in data)


def parseExportedPdu(packet: packet.Raw):
Copy link
Collaborator

Choose a reason for hiding this comment

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

Code duplicated from an active PR. One of us will rebase and refactor to avoid this useless duplication.

Co-Authored-By: Olivier Bilodeau <[email protected]>
@obilodeau
Copy link
Collaborator

A simple zip of the pcap gave a 5.9M binary (from 16M). It's not as good as I have expected. Since git stores it's pack metadata already compressed (so also on the network), I'm going to let go on this.

I might revisit if we add more pcap-based tests to reduce checkout size.

.github/workflows/ci.yml Outdated Show resolved Hide resolved
@Res260
Copy link
Collaborator Author

Res260 commented Mar 24, 2020

A simple zip of the pcap gave a 5.9M binary (from 16M). It's not as good as I have expected. Since git stores it's pack metadata already compressed (so also on the network), I'm going to let go on this.

I might revisit if we add more pcap-based tests to reduce checkout size.

Should I revert the commit then?

@obilodeau
Copy link
Collaborator

Should I revert the commit then?

Since it's already done I'm tempted to say no.

That said, are you sure this directory will always be writable to the user running the tests? It looks like the GitHub action worked so we can keep it.

@Res260
Copy link
Collaborator Author

Res260 commented Mar 24, 2020

That said, are you sure this directory will always be writable to the user running the tests? It looks like the GitHub action worked so we can keep it.

There is no garantee indeed, i'm not sure what would be the best approach. It will always work for the CI though

@Res260
Copy link
Collaborator Author

Res260 commented Mar 24, 2020

For the code coverage, I could add it to the CI if you want using https://www.codecov.io/, thoughts?

@Res260
Copy link
Collaborator Author

Res260 commented Mar 24, 2020

Actually I can do it inside the CI without a third party

@obilodeau
Copy link
Collaborator

For the code coverage, I could add it to the CI if you want using https://www.codecov.io/, thoughts?

then

Actually I can do it inside the CI without a third party

Do what you prefer.

@Res260
Copy link
Collaborator Author

Res260 commented Mar 24, 2020

Added windows installation and test, as a treat :)

It does the same thing as the ubuntu one but on windows. My reasonning behind this is that even though installation does not fail per se, execution can fail because dependencies sometime have a hard time testing for both windows and linux, so I'd rather run the test twice.

@Res260
Copy link
Collaborator Author

Res260 commented Mar 24, 2020

I added the coverage report to the CI, and it will fail if it falls under 50% (currently 53% coverage).

@obilodeau Should I still add documentation for the coverage in docs or it's not needed?

@obilodeau
Copy link
Collaborator

@obilodeau Should I still add documentation for the coverage in docs or it's not needed?

Not needed. This is self-explanatory now. Thanks!

Copy link
Collaborator

@obilodeau obilodeau left a comment

Choose a reason for hiding this comment

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

This is ready to go in. Squash merging. Thanks @Res260 for the work!

@obilodeau obilodeau merged commit ff96ed2 into master Mar 25, 2020
@obilodeau obilodeau deleted the integration_test branch March 25, 2020 02:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants