Speed up completion hook shellcode
See original GitHub issue@evanunderscore interest
In the course of looking into #278, I’ve become concerned about the performance impact of pkg_resources.iter_entry_points()
in https://github.com/kislyuk/argcomplete/blob/master/argcomplete/_check_console_script.py.
I’d like us to profile the completion hook shellcode. We might want to use techniques developed by https://github.com/DropD/reentry to speed up entry point scanning, or look for other ways to speed up the shellcode.
Issue Analytics
- State:
- Created 4 years ago
- Comments:6 (3 by maintainers)
Top Results From Across the Web
WOW64 Subsystem Internals and Hooking Techniques
This blog post is broken up into two sections. First we start by diving deep into the WOW64 system. To do this, we...
Read more >PE Parsing and Defeating AV/EDR API Hooks in C++
This post is a look at defeating AV/EDR-created API hooks, using code originally written by @spotless located here.
Read more >Path to Process Injection — Bypass Userland API Hooking
We can inject: 1. Entire portable executable (PE) into another running process such as injecting a reverse shellcode binary or executable;. 2.
Read more >Command and Shell Code Injection Scenarios with Commix ...
Of course, nobody has harmed at Monastiraki during this article. Instead, several Virtual Machines were set up to substitute the cafe clients.
Read more >scdbg shellcode analysis - Sandsprite
D:\>scdbg -i -f ./sc/dropz.sc Loaded 21b bytes from file ./sc/dropz.sc Initialization Complete.. Interactive Hooks enabled Max Steps: 2000000 Using base ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
We are not actively maintaining support for Python 2, and I expect to drop all Python 2-specific compatibility code sometime later this year. In general we will follow EOL announcements from upstream to decide when to drop support, and in case of Python 2.7, EOL was January 1, 2020.
Are we similarly considering dropping support for Python 2? It reached EOL at the beginning of this year, but I can understand making a special case for it given how prevalent it still is. However as time goes on, our dependencies will drop support for it and the burden of maintaining it will grow. Do you have any thoughts around this?