DEV Community: Demian Brecht

Automating Android Burp API Testing (Because Rebuilding This Sucks)

Demian Brecht — Fri, 06 Feb 2026 01:41:42 +0000

Reproducing mobile security findings is one of those tasks that sounds trivial until you actually try to do it.

Desktop traffic? Easy.

Android → API → Burp? Suddenly you’re juggling emulators, system certificates, proxy configuration, and half-remembered setup steps you only touch a few times a year.

If you’re primarily a backend engineer, this usually means losing time just getting to the point where you can see the traffic, let alone reason about the bug.

I got tired of rebuilding the same fragile setup, so I automated it.

The problem

When a security researcher reports an issue involving a mobile client, validating it often requires recreating an environment you don’t normally live in.

On paper, the setup is straightforward:

Android emulator
Burp Suite acting as a man-in-the-middle
Burp CA installed into the system trust store
Emulator traffic routed through Burp
Requests flowing into your API

In practice:

Emulator images behave differently
Cert installation is easy to get wrong
HTTPS breaks silently
You end up debugging the tooling instead of the issue

None of this is hard. It’s just annoying, fragile, and repetitive.

The goal

I wanted something that would:

Get me from “report received” to “inspectable HTTPS traffic” quickly

Require minimal Android knowledge
Be repeatable and disposable
Let me focus on validating the issue, not the plumbing

That’s it. No grand framework. Just removing friction from a recurring workflow.

What android-burp does

android-burp automates standing up an Android emulator wired through Burp Suite into your API.

Specifically, it handles:

Provisioning an Android emulator
Installing Burp’s CA certificate into the system trust store
Routing emulator traffic through Burp
Getting you to inspectable HTTPS traffic with minimal ceremony

The intent is not to replace understanding how this works — it’s to avoid re-learning it every single time.

A note on AI assistance

I’m a backend engineer by trade, not a mobile specialist.

This project was built with heavy AI assistance while working through unfamiliar Android internals. Not as a replacement for understanding, but as a force multiplier for:

Exploring tooling quickly
Validating assumptions
Iterating without spending days in docs

The result is something that’s already paid for itself in saved time.

Who this is for

This will probably be useful if you:

Work on APIs that have mobile clients
Validate security reports involving Android apps
Don’t want to become an Android expert just to reproduce an issue
Are tired of rebuilding the same setup from scratch

If you live in mobile tooling every day, this might feel boring.

If you don’t — it’s a relief.

The repo

The project is fully open source here:

https://github.com/salesforce-misc/android-burp

Feedback, issues, and PRs are welcome. If it saves someone else from the same yak-shaving, it’s done its job.

Gen AI: Feeding the dormant hacker

Demian Brecht — Tue, 27 May 2025 23:16:15 +0000

I can be a bit of a tech curmudgeon at times. I once even went as far as to write that you would pry vim from my cold, dead hands. I have a set of tools and processes that I’ve built up over the years that I’m comfortable with. Because of the comfort level, I’ve also traditionally been my most productive with them. In over 20 years of professional software development, I’ve never come across productivity enhancement that has gotten me to throw everything out of the window and start anew. The use of Cursor and Gen AI has done just that. Here’s the story of my experience thus far, which I’m sharing in hopes of turning my level of stoke contagious with a wider audience than my immediate circle.

I'm an 80s kid. A xennial. My father was a musician, a one-man band who was a very early adopter of MIDI. I grew up around computers. I fondly remember the days of the Vic 20, Commodore 64 and the Amiga and being wide-eyed and full of wonder at the pixellated images that took what seemed forever to load. I finally got some bigger-boy shoes in the late 90s with the home PC of my dreams running Windows ‘95. Much time was spent trying to establish dial-up connections when someone was already on the line elsewhere in the house. Gaming was my main interest (from Zork to Wolfenstein 3D), but getting computers to do things was also high on my list of interests, mostly tinkering first with Logo and eventually getting into BASIC.

Over the following years, I toyed with web development, hosting my very first Diablo fan site on Geocities. It wasn’t until I saw someone yell “Hack the Planet!” (groan, I know), found a local 2600 crew and did a little dumpster-diving when I got a little more serious about programming. I found the internet fascinating. I found the weak points fun.

I started my professional career out at a small local business automation shop. I got my hands dirty with a number of different aspects of the business: Software (good ol' VB6 with an MS Access database), wiring up customer sites with cat5 cable for card scanners and providing training. I'd gotten a foot in the door. This was an exciting time for me. I was doing a lot of grunt work, but was still able to code every now and then and I actually got paid for it. I was also still spending time supplementing the more mundane aspects of my job with the hackers and the phone phreaks.

Then the excitement increased by an order of magnitude when I was lucky enough (after a multitude of attempts) to get a foot in the door at Electronic Arts. At the time, I was a gamer and I finally was going to get the chance to work myself into a position where I could contribute to the games I played. By the time I’d left EA, I’d worked on a number of AAA titles, got to do some prototype work for the Wii that ended up being the basis of one of the Playground mini-games and even got to do some voice work for an NCAA Football title. During that time, my tinkering time went from network security to the open source community, particularly Python’s. While continuing my career between Popcap Games, Demonware (Activision) and then finally landing at Salesforce, I contributed to the Python Software Foundation (PSF). I contributed here and there to some of the issues in the tracker and to the http library. I even released a couple of (really unused) open source libraries.

This is a synopsis intended to highlight how much I actually love what I do, not to be an autobiography. This isn’t just a job for me, it’s something I look forward to every day. Solving tough problems with computers is something I genuinely enjoy.

However, along the way I lost a large portion of the drive to tinker and hack on things.

Maybe it’s because I picked up too many outdoor activities. Maybe it’s because my software-related hobbies started to blend too much with my professional work. Maybe it’s because adulting cut into personal time and felt like I no longer had the chance to accomplish my lofty technical goals. Maybe it was a combination of all the above. At the end of the day, it boiled down to just not being able to find the time to achieve what I wanted to on my personal time.

Then Gen AI came along.

At first it seemed like a passing fad. The failure rate was high. Hallucinations were real. It seemed like it could maybe be useful for helping me to throw together some shell scripts or other mundane routine things but it wasn't likely going to be of any real use as I had to spend just as long fixing the output as I would have writing it in the first place.

Then it got better. Companies started to introduce productivity initiatives which became a forcing factor for me to really give it a shot and find out where the ceiling was. I found I wasn't getting the opportunity to muck with it to the extent that I wanted to during the work day, so I started using it after work hours and over the weekends after the kids went to bed. What did I find?

This.
Shit.
Is.
Fun.

"Vibe coding"? Not quite. I’ve tried multiple paths to get me to this panacea of AI-assisted software development but never got close with anything outside of the simplest of use cases. I found that the most effective approach was to carve off a small, very specific piece of functionality, be extremely clear about the expected inputs and outputs, sometimes writing it down in some documentation and feeding that as context and instructions to the LLM. Then, begin the back and forth with the LLM. Having kids, especially teenagers, had prepared me for this:

Ask it to do something. Aim low, shoot high or in other words hope for the best but expect something half-assed.
Suggest it wasn't done optimally and suggest an alternate approach.
Watch it correct itself and get it a little closer.
Have some back and forth while whittling away at the cruft to get where you want it to be (test coverage, etc).
Expect it to do something underhanded: "No, I really do want this to use a Red Hat base image. Please don't change it to Debian... Again".
Expect it to not understand some things: "Yes, I actually do want to keep the async request handlers but keep the database transactions synchronous".
Expect to be caught in the wrong at times, admitting to yourself you were being dumb and that you can learn a thing or two from the LLM.

But expect that after a healthy amount of back and forth and, similar to working with your teenager, learning how to most effectively communicate with them, you will eventually get to your destination in a far shorter amount of time than it would have taken you on your own.

The aspects that have been the most fun for me so far?

I've gotten to play with tools and libraries that I would have likely otherwise skipped over because they're not part of my daily work (uv - yes I know, you don't need to tell me how good it is, alembic, sqlalchemy core to name a few).

I’ve learned some tips and tricks that I can use in my daily work (i.e. using pg_isready as the health check in a docker-compose file like demonstrated here instead of a hacky shell script).

A healthy amount of code can be written in a relatively short amount of time, though you do have to keep an eye on general correctness and needless complexity. My first real attempt at a putting something together outside of one-off scripts or Splunk queries ended up as a FastAPI project that had:

Dockerfile
docker-compose config for local dev with postgres tie-in and sane dependencies
CRUD endpoints for users and related models with unit tests
E-mail verification for new user accounts with modular providers
Migrations courtesy of alembic (properly configured)
Beginnings of authentication endpoints with OAuth providers

In 2 hours!

It's probably a stretch to think I could have accomplished that with the tools and libraries that I use on a daily basis. There's no chance I would have come close with frameworks that I've never really used.

If you’ve found yourself being an AI curmudgeon, or are only using it because you’ve been told that you have to, I challenge you to play around with it more. A lot more. Explore its capabilities. See where it fails. See where it works. See not only what it can do for you but what you can learn from it. If you’ve had similar experiences to mine, you may just find yourself having fun again, looking forward to playing with technology outside of your daily work life. All while still being able to achieve your goals and putting in your adulting time.

Dude, I'm slagging your code. Not you.

Demian Brecht — Sat, 11 Apr 2020 19:31:04 +0000

I wrote this a few years ago on Medium, but thought I'd re-share it with this community as I strongly believe that the experience and resulting realization were incredible for my career progression. Hope others can learn from or identify with it.

I spent the first decade of my now roughly 16 years of writing code being overly attached to the code that I wrote. I took pride in what I designed and wrote. It was my baby. I’d spent hours painstakingly writing, refactoring, rinsing and repeating. I watched my code and libraries mature. I was generally happy with the output. Nobody could attack it without me immediately taking on the role of the parental defender. After all, that code was a part of me. It was the sum of all of my years of learning and practice. I was blinded by love. No child is cuter than your own.

I’m sure many folks who have spent years writing code can identify with the above. Unfortunately, it’s really a horrible mindset to have in practice. Here’s a case study, based on an experience years ago from yours truly:

I put an inordinate amount of time into writing an OAuth 2.0 client in Python (this is during spec draft days before many clients were available). There was another client available at the time, but it was a monster and really seemed like overkill to me. I spent a good deal of time digging through the RFCs, understanding the protocol to the lowest level. I spent just as much time researching deviations in provider implementations, which reminded me of early client side browser development days. I then spent a good amount of time designing and implementing a library that I was proud of. It beat the code footprint of the other library by over two orders of magnitude and as far as I could tell, offered just as much functionality.

I understood that I’d written this library in a vacuum and wanted to get some feedback from someone more entrenched with the Python community. I’d watched a talk given by someone and enjoyed it, so decided to reach out to them and ask for a code review. Much to my horror, he ripped it apart. It felt like I was having my heart torn out and stomped on. How could he ever see anything wrong with this body of perfection that I’d created?! I found messages on his social media accounts poking at various areas in the code (not actually linking back to the code as to maintain anonymity). My jaw hit the floor. I couldn’t believe what had just happened.

I fired back. I sent him an email directly with my feathers all ruffled. Something to the effect of “)&#$ #$()& #$)#(&ASD&!!!”. His response was:

“Dude, I’m slagging your code. Not you.”

I slept on it. While I still felt there’s a much better way to deliver feedback, it did force me to consider some bigger questions. How on earth could he have a clean separation between my person and my code? Weren’t they effectively one and the same as my code is a product of my efforts?

Then the lightbulb went off. I was wrong. What I realized is that, while code that I’ve written is indeed mine, in no way, shape or form does it represent me as a person. Not only that, but no two software engineers will ever solve the same problem in the same way. The trick is to listen to what others are saying, to understand that:

Everyone solves problems differently,
Everyone has a different delivery mechanism, with wildly varying degrees of tact, and
They’re not talking about you, they’re talking about code

The person with the least amount of tact will say “this code is terrible”. They’re not calling you a jerk. They’re not saying you’re incompetent. They’re saying your code is suboptimal. Funny as it may sound, once you come to this realization, handling the most brutal code review or even having code that you’ve written entirely obliterated from source control becomes a cakewalk. No longer are you taking things folks are saying as personal attacks, but as sources of knowledge to enhance your own learnings and professional development. If someone says “this code sucks”, you tend to ask why they think that and how it can be improved rather than getting into arguments that are based on passion instead of sound technical reasoning. You’ll also likely be surprised by the number of times people think your code sucks because they don’t understand the problem domain well enough. You’ll be surprised at how often you can learn great stuff from those who are a little less savvy around conversational tact.

Of course, I’m not advocating that ripping someone’s code apart verbally or over social media is a good thing by any stretch. It’s usually best to have one on one discussions with someone who’s reached out to you for a review. What I’m trying to get at here is the importance of being able to separate yourself from the code that you write. It’ll help you tons throughout your career.

Entry points in Python

Demian Brecht — Thu, 09 Apr 2020 19:56:27 +0000

What's an entry point?

The most relevant bit of the description in Wikipedia is:

In computer programming, an entry point is where the first instructions of a program are executed, and where the program has access to command line arguments. To start a program's execution, the loader or operating system passes control to its entry point.

What we're going to cover in this blog post is the various methods that you can define entry points in your Python programs. Some with obvious downsides as we'll discover.

Keeping it simple: Python scripts

The simplest thing that you can do is treat your Python file as a self-contained script. Here's the old "Hello world!" example:

#!/usr/bin/env python
def say_hi():
    print('Hello world!')
say_hi()

Running this file directly gives us an implicit entry point: Just by running the script we get right into execution:

$ ./hellow_world.py
Hello world!

Easy, right? So what's the problem here?

The downside

What if your project became complex enough to warrant multiple modules? What if you want to import and say hello from another module? With the above, this is what would happen:

In [1]: import hello_world                                                                                                                                                          
hello world!

As you can see in the above, the problem with the Python script approach is that it's overly simple and functionality is executed at import time, which is typically not what you're after. Not only is it functionally not what you're going to be after, but writing unit test for it will be difficult if not impossible, especially if there is any state change through side effects.

So how can we solve this? Read on!

Leveling up: What's my name?

So now we know that sticking all of our functionality in a Python script isn't the best approach if we want to reuse or write unit tests. So then, what's the next best thing? Using the if name == 'main' pattern.

From the Python docs:

'__main__' is the name of the scope in which top-level code executes. A module’s name is set equal to '__main__' when read from standard input, a script, or from an interactive prompt. A module can discover whether or not it is running in the main scope by checking its own name, which allows a common idiom for conditionally executing code in a module when it is run as a script or with python -m but not when it is imported.

If we adopt this new learning to hello_world.py, it would then look like this:

#!/usr/bin/env python
def say_hi():
    print('Hello world!')

if __name__ == '__main__':
    say_hi()

So, now running it from the command line will still yield the same result:

$ ./hellow_world.py
Hello world!

The major difference though, is that now our import time problem has been solved. Rather than seeing "Hello world!" at module import, we have to explicitly call say_hi():

In [1]: import hello_world                                                                                                                                                          
# No output here anymore!
In [2]: hello_world.say_hi()                                                                                                                                                        
Hello world!

This will now also allow us to write and run unit tests against the hello_world module without having to worry about import time side effects.

The observant reader will notice that the Python docs also refers to running Python modules directly with python -m. This would allow you to run hello_world without making it executable and adding the shebang at the beginning of the file:

$ python -m hello_world
Hello world!

Another example of this is the standard module's json.tool:

$ python -m json.tool <<< '{"hello": "world"}'
{
    "hello": "world"
}

"This is awesome! All my problems are solved!" says you. "Nay" says I. "Not quite yet".

The downside

Now we have entry points in Python files that we can unit test against. Great. But what are we to do if our project really increases in size? How do we find which modules have entry points defined and which ones don't? There must be a better option than:

$ grep -r "if __name__\s*==\s*['\"]__main__['\"]"`

Indeed there is, dear reader. Indeed there is.

Come together: Script organization

Now that we know about the if __name__ == '__main__' pattern, how do we avoid the confusing aspect of figuring out which files are actually executable? Well, this one has two facets, both of which are fine on their own but shine when used together:

Add a `scripts` directory to your project

By adding a scripts directory, you can lump all of your entry points into a single directory, making it ridiculously simple for anyone looking at your project to find all of the various entry points for your project. After doing this with hello_world.py, this is what our directory structure looks like:

$ tree .
.
├── scripts
│   └── hello_world.py
└── setup.py

For a new user or developer just coming into the project, this makes it tremendously simple to figure out what entry points are available in your project.

How can we enhance this experience you ask? That part comes with the introduction of setuptools. In the above, you'll notice a setup.py file. It's within there that we want to define scripts to be installed when the user installs your package:

setuptools.setup(
    name='hello_world',
    version='0.1.0,
    scripts=['scripts/hello_world']
)

For ease of use, I've also dropped the extension in hello_world.

Now when a user installs the package, here's what they'll see:

$ python setup.py develop
running develop
running egg_info
creating hello_world.egg-info
writing hello_world.egg-info/PKG-INFO
writing dependency_links to hello_world.egg-info/dependency_links.txt
writing top-level names to hello_world.egg-info/top_level.txt
writing manifest file 'hello_world.egg-info/SOURCES.txt'
reading manifest file 'hello_world.egg-info/SOURCES.txt'
writing manifest file 'hello_world.egg-info/SOURCES.txt'
running build_ext
Creating /path/to/.venv/lib/python3.7/site-packages/hello_world.egg-link (link to .)
Adding hello 0.1.0 to easy-install.pth file
Installing hello_world script to /path/to/.venv/bin

Installed /path/to/hello_world
Processing dependencies for hello_world==0.1.0
Finished processing dependencies for hello_world==0.1.0

The important thing to note in the above is Installing hello_world script to /path/to/.venv/bin. This means that users now don't have to fiddle with running ./scripts/hello_world or python -m hello_world, they can simply run the script directly:

$ hello_world 
Hello world!

"What is this magic?!" you ask?

For each entry in the scripts entry, a file will be created in your environment's Python bin dir. The resulting file looks like this:

#!/path/to/.venv/bin/python3.7
# EASY-INSTALL-DEV-SCRIPT: 'hello_world==0.1.0','hello_world'
__requires__ = 'hello==0.1.0'
__import__('pkg_resources').require('hello==0.1.0')
__file__ = '/path/to/hello/scripts/hello_world'
exec(compile(open(__file__).read(), __file__, 'exec'))

So the executable script written to the bin directory effectively acts as a redirect to your source file, executing it.

The combination of the approaches to this point should be enough to satisfy even complex projects. However, if you want to know a completely different option (and my personal favorite), read on!

And now for something completely different: `entry_points`

The combination of console_scripts and entry_points in a project's setup.py can help us achieve the same results as the previous sections, but without the need for the if __name__ == '__main__' pattern. This is achieved by specifying a callable entry points in the setuptools config:

Noting that we're back to the original directory structure:

$ tree .
.
├── hello_world.py
└── setup.py

Our setup.py file might now look something like this:

import setuptools

setuptools.setup(
    name='hello_world',
    version='0.1.0',
    entry_points={
        'console_scripts': [
            'hello_world=hello_world:say_hi',
        ]
    }
)

The observant reader will notice that as we're configuring the entry point to be a callable, this is now something that can easily be unit tested directly.

The magic sauce that allows us to run the script directly looks a little different than the treatment it gets from scripts:

# EASY-INSTALL-ENTRY-SCRIPT: 'hello-world','console_scripts','hello_world'
__requires__ = 'hello-world'
import re
import sys
from pkg_resources import load_entry_point

if __name__ == '__main__':
    sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
    sys.exit(
        load_entry_point('hello-world', 'console_scripts', 'hello_world')()
    )

Definitely has some functional differences, but at a high level the results are effectively the same:

$ hello_world 
Hello world!

Gettin' jiggy with it: Single entry point

"So I have a couple ways to define entry points" you say. "But what if I want to have multiple entry points? Does that mean that I need to have multiple executables for my single application?"

Great question! And of course, the answer is "no", but how you solve that problem is entirely up to you.

An approach that I've used in the past is to define a single entry point and to create a commands directory and a module for each sub-command I want available.

The project structure would now look like this:

$ tree .
.
├── hello_world
│   ├── app.py
│   ├── commands
│   │   ├── __init__.py
│   │   └── say_hi.py
│   └── __init__.py
└── setup.py

setup.py:

import setuptools

setuptools.setup(
    name='hello_world',
    version='0.1.0',
    entry_points={
        'console_scripts': [
            'hello_world=hello_world.app:main',
        ]
    }
)

The app.py module is simplistic, but captures one potential approach (how it does what it does is an exercise left to the reader):

import argparse
import importlib
import sys

def main():
    parser = argparse.ArgumentParser('Say hello to the world')
    parser.add_argument('command', type=str, help='Which command to run')

    args = parser.parse_args()
    try:
        module = importlib.import_module(f'hello_world.commands.{args.command}')
    except ModuleNotFoundError:
        print('Invalid command')
        sys.exit(1)

    getattr(module, 'Command')().run()

And the actual command (say_hi.py) looks like this:

class Command():
    def run(self):
        print('Hello world!')

If you have multiple commands, which I would hope you are if you're using this approach, then you could either rely on duck typing as I am above, or define an abstract base class and ensure the command being imported in app.py is an instance of that interface. The latter is likely the better of the approaches if multiple people are contributing to the code base.

Then running it after installing becomes:

$ hello_world say_hi
Hello world!

Or... Y'know... You could use a sane library like click to do this instead of rebuilding the wheel.

You're just a wee bit more dangerous now!

Hopefully you've learned some new tips and tricks here and your next project won't make your new hire want to pull their hair out trying to figure out how the entry points in your project work.

Why the hell is my code so slow?! (aka performance analysis in Python)

Demian Brecht — Tue, 10 Mar 2020 05:56:15 +0000

Setting the stage

So you've finally finished that feature that you've been grinding on for a while. It's polished up. It's passed the unit tests you've written for it locally. It's passed your local integration tests. The pull request has been reviewed and iterated on. You're happy you still have hair left after a few back-and-forths with the team pedant who kept hitting "request changes" in their review even though everyone else on the list approved it already. Your pull request has been finally been accepted by all. It's time to merge it.

You hit the button.

It's in master.

You're proud of the work you've done as well you should be. You've put in the time and the effort into understanding what your producer, product owner or customer was looking for and bridging the technical requirements to pull it off successfully.

Nothing broke the master build.

You go have a celebratory scotch that night. Or a glass of wine. Or a coffee. Or a water. Whatever. Your feature has been deployed and is being used by the general public. This is awesome. Another feather in your cap.

And then you get the email.

Thanks for all your hard work on this great new feature! We haven't seen any new bugs come out of it as a result and no complaints from our users. Awesome work! Buuuut, we were noticing some slowness when using the feature and dug into it a bit. Seems like the main endpoint you wrote is causing our average response time down by 500ms.

Your world crumbles around you. You can feel the heat as your face reddens. This feels worse than breaking master. How did this happen?! How on Earth are you going to solve this problem?

Sound vaguely familiar? Not experienced it and are hoping to avoid as much as possible in the future? Hoping to get past this completely unnecessary possibly fictional story in order to find some nuggets that may help in the future? Never fear, I'm now finished attempting to needlessly blow up the reading time of this post!

(The astute reader may notice the distinct lack of load tests in the above story. Of course, this never happens in real life... RIGHT?!)

The feature

Let's say the amalgamation of my blood, sweat and possibly a few tears is incredibly complex. The feature that was merged into master and brought my team's servers near to a state of DoS looked like this:

def print_this(value_a, value_b):
    print("{} did this thing to {}".format(value_a, value_b))

(The observant reader will notice that this is in no, way, shape or form complex code. However, it should be enough to demonstrate my typical approach to investigating and solving performance issues)

What's slow?

If what's causing the bottleneck is unknown to me, my first stop will typically be cProfile. There are a few different methods of running cProfile and printing statistics, but I'm only going to concentrate on the process that I typically use¹.

First, I'll instrument the entry and exit points of the code. In this incredibly complex case, it'll be where print_this is called:

import cProfile

profiler = cProfile.Profile()
profiler.enable()

print_this('foo', 'bar')

profiler.disable()
profiler.dump_stats('print_this.profile')

It's worthwhile to note that Python 3.8 introduced a context manager implementation which is pretty nifty, but I wrote this using 3.7 so we're just going to have to deal with the archaic method.

The results of the profiling will be dumped to the file print_this.profile for analysis by other tools, namely pstats². Alternatively, you can print the results directly using profiler.print_stats():

In [1]: import pstats                                                                                                                                                                       

In [2]: stats = pstats.Stats('print_this.profile')                                                                                                                                          
In [3]: stats.sort_stats('cumulative').print_stats()                                                                                                                                        
Mon Mar  9 21:14:09 2020    print_this.profile

         4 function calls in 0.000 seconds

   Ordered by: cumulative time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000    0.005    0.005 print_this.py:1(print_this)
        1    0.005    0.005    0.005    0.005 {method 'format' of 'str' objects}
        1    0.000    0.000    0.000    0.000 {built-in method builtins.print}
        1    0.000    0.000    0.000    0.000 {method 'disable' of '_lsprof.Profiler' objects}

I usually sort by cumulative time to get an idea of what the problematic call stack might look like (you can find the other available values and descriptions of each here).

A worthy mention here is that you can also limit the number of lines output. Integers will limit to line count while a fraction between 0.0 and 1.0 will output a percentage. See here for other possible filters.

(The astute reader will shame me for the numbers in the above table. To be clear, the numbers are fudged for the sake of keeping the code simple.)

Looking at the output from pstats...

AHA!

I can easily tell what's chewing up the time. There are two functions at the top of the pile, one of which has a percall and tottime of 0.000, but cumulative time of 0.005. This tells me that this is isn't the target but is part of the call stack. On the other hand, {method 'format' of 'str' objects} is taking a ridiculous 0.005s per call! Problem found! Call in the cavalry!

Oh wait... I'm the cavalry. Crap.

So what to do?

Thankfully (and completely intentionally), the scope of this particular performance issue is small. It's limited to a single line. In real life, it will almost certainly be more complex, so brace yourself for iterative code profile instrumentation and experiments. It's not always a simple task to nail down performance issues, but it's oh so satisfying when you've identified and squashed a bottleneck.

In this case, I know that the problem with the performance is the call to <str>.format(), so I have to figure out a replacement for it. Again, thankfully (and again, entirely intentionally) I'm aware of a few different methods that it can be replaced with. But which one should I use? The choices I have available to me are:

concatenation (value_a + ' did this thing to ' + value_b)
interpolation ('%s did this thing to %s' % (value_a, value_b)), and
f-strings (f'{value_a} did this thing to {value_b}')

Rather than having to iteratively refactor, instrument, output and analyze performance metrics, I can use a simple tool I have at my disposal: timeit:

# Concatenation
$ python -m timeit -n 500000 -s "value_a, value_b = ('foo', 'bar')" "value_a + ' did this thing to ' + value_b"
500000 loops, best of 5: 65.2 nsec per loop

# Interpolation
$ python -m timeit -n 500000 -s "value_a, value_b = ('foo', 'bar')" "'%s did this thing to %s' % (value_a, value_b)"
500000 loops, best of 5: 134 nsec per loop

# F-Strings
$ python -m timeit -n 500000 -s "value_a, value_b = ('foo', 'bar')" "f'{value_a} did this thing to {value_b}'"
500000 loops, best of 5: 56.7 nsec per loop

It's also possible to import and use timeit from within a Python shell. Check out the interface here if interested.

Two notables in the above example are:

a) I'm explicit about the number of loops to run (-n)
b) I don't want to measure the cost of variable assignment (i.e. value_a = 'foo'), so I pull that part out into the setup argument (-s).

Based on this, I can easily tell which method I should use in my code: f-strings!

Righting the wrongs

So now that I know what needs to change, those changes are made:

def print_this(value_a, value_b):
    print(f"{value_a} did this thing to {value_b}")

And just for sanity sake, I re-run the instrumented code and load and dump out the results:

In [1]: import pstats                                                                                                                                                                    
In [2]: stats = pstats.Stats('print_this.profile')                                                                                                                               
In [3]: stats.sort_stats('cumulative').print_stats()                                                                                                                                     
Mon Mar  9 22:02:13 2020    print_this_fstring.profile

         3 function calls in 0.000 seconds

   Ordered by: cumulative time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000    0.000    0.000 print_this.py:1(print_this)
        1    0.000    0.000    0.000    0.000 {built-in method builtins.print}
        1    0.000    0.000    0.000    0.000 {method 'disable' of '_lsprof.Profiler' objects}

And indeed, the performance problem has been resolved. Huzzah! Not only has my feature been shipped, but I've successfully been able to resolve a nasty performance issue! Pull request has been created along with details of the performance analysis, accepted and merged. Now I can go go home and partake in that celebratory scotch. Or glass of wine. Or coffee. Or water. Whatever.

Hold on, WHY is `<str>`.format() slow?

If you're not so interested, feel free to stop reading here as you likely won't need to use the following tips 'n tricks in your daily life of performance analysis.

For those of you who are interested, oh I'm so glad that you asked! When trying to figure out why solution A is better than solution B, there's no better method than using the dis module. For our purposes, here's what string formatting and f-strings look like in Python 3.7:

# String formatting
In [1]: from print_this import print_this                                                                                                                                               
In [2]: from dis import dis                                                                                                                                                             
In [3]: dis(print_this)         
  2           0 LOAD_GLOBAL              0 (print)
              2 LOAD_CONST               1 ('{} did this thing to {}')
              4 LOAD_METHOD              1 (format)
              6 LOAD_FAST                0 (value_a)
              8 LOAD_FAST                1 (value_b)
             10 CALL_METHOD              2
             12 CALL_FUNCTION            1
             14 POP_TOP
             16 LOAD_CONST               0 (None)
             18 RETURN_VALUE


# F-Strings
In [1]: from print_this import print_this                                                                                                                                                
In [2]: from dis import dis                                                                                                                                                              
In [3]: dis(print_this)                                                                                                                                                                  
  2           0 LOAD_GLOBAL              0 (print)
              2 LOAD_FAST                0 (value_a)
              4 FORMAT_VALUE             0
              6 LOAD_CONST               1 (' did this thing to ')
              8 LOAD_FAST                1 (value_b)
             10 FORMAT_VALUE             0
             12 BUILD_STRING             3
             14 CALL_FUNCTION            1
             16 POP_TOP
             18 LOAD_CONST               0 (None)
             20 RETURN_VALUE

Now unfortunately for our purposes, it isn't immediately obvious what the difference is between the two. However, this also presents us the opportunity to dig into the interpreter implementation and at least derive a theory³:

The notable differences between the two are that string formatting calls LOAD_METHOD and CALL_METHOD, while the f-string implementation simply calls FORMAT_VALUE. Looking at those opcodes (defined in opcode.h and their respective implementations in ceval.c, we can relatively safely come to the conclusion that LOAD_METHOD and CALL_METHOD are far more costly than FORMAT_VALUE, which actually formats the entire string directly in the opcode handler.

Wrapping things up

Going into this depth of performance analysis isn't always required. Most of the times things will work to an acceptable level of performance. Having these tools in your back pocket can sometimes promote the want to analyze everything you write. However, one should always remember that "premature optimization is the root of all evil"!

Feel free to heckle in the comments ↩
I prefer using pstats to dumping stats directly because of the additional niceties it offers. Also because I frequently screw up and need to have a stable copy of the profile output. ↩
Interpreter execution is not an area of expertise for me, so I very much welcome feedback here. ↩

The lesser known (but incredibly useful) way of settings breakpoints in Python

Demian Brecht — Tue, 03 Mar 2020 21:15:35 +0000

Everyone knows that in order to set a breakpoint in Python you need to modify your source code with the somewhat unintuitive

import pdb; pdb.set_trace()

# or if >= 3.7
breakpoint()

Right?

But

Did you know that there's a way to set breakpoints that doesn't involve modifying your code?

"What's this silliness you speak of?" you say?

There may be times when you have to jump through ridiculous hoops in order to modify code¹ and the more common method of setting breakpoints in Python isn't worthwhile. For those cases, you have the ability to run your code interactively through a pdb shell:

python -m pdb <script>.py

That's right, pdb can be run as an executable module! Neat-o, right? Now you'll be dropped into the pdb shell, from which you can run your usual pdb commands (next, list, continue, etc). For our particular use case however, the most interesting and useful command is break:

    b(reak) [ ([filename:]lineno | function) [, condition] ]
            Without argument, list all breaks.

            With a line number argument, set a break at this line in the
            current file.  With a function name, set a break at the first
            executable line of that function.  If a second argument is
            present, it is a string specifying an expression which must
            evaluate to true before the breakpoint is honored.

            The line number may be prefixed with a filename and a colon,
            to specify a breakpoint in another file (probably one that
            hasn't been loaded yet).  The file is searched for on
            sys.path; the .py suffix may be omitted.

The break command is incredibly flexible. You can specify breakpoint locations by line number (prefixing it with a filename is optional), by function and even slap on a condition.

As an example, consider the following example.py:

import requests

def foo():
    print('foo')

def bar(value='bar'):
    print(value)

def get():
    print(requests.get('https://example.com/'))

if __name__ == '__main__':
    foo()
    bar()
    bar(value='foo')
    get()

Setting a breakpoint with (filename):lineno

This can be useful when we know the exact file and line we want to break execution at. This can be really useful if you want to break into the debugger shell at import time rather than execution (debugging circular references, etc).

$ python -m pdb example.py 
> /home/dbrecht/src/p/playground/example.py(1)<module>()
-> import requests
(Pdb) b example.py:5
Breakpoint 1 at /home/dbrecht/src/p/playground/example.py:5
(Pdb) c
> /home/dbrecht/src/p/playground/example.py(5)foo()
-> print('foo')

Setting a breakpoint by function

This is generally the easiest way to set breakpoints, especially when dealing with dependencies. For this example, let's say we already know that requests.get eventually calls into requests.request and we want to stop at that point rather than having to step through preamble code in requests.get:

$ python -m pdb example.py 
> /home/dbrecht/src/p/playground/example.py(1)<module>()
-> import requests
(Pdb) import requests
(Pdb) b requests.request
Breakpoint 1 at /usr/lib/python2.7/dist-packages/requests/api.py:16
(Pdb) c
foo
bar
> /usr/lib/python2.7/dist-packages/requests/api.py(57)request()
-> with sessions.Session() as session:
(Pdb) w
  /usr/lib/python2.7/bdb.py(400)run()
-> exec cmd in globals, locals
  <string>(1)<module>()
  /home/dbrecht/src/p/playground/example.py(19)<module>()
-> get()
  /home/dbrecht/src/p/playground/example.py(13)get()
-> print(requests.get('https://example.com/'))
  /usr/lib/python2.7/dist-packages/requests/api.py(72)get()
-> return request('get', url, params=params, **kwargs)
> /usr/lib/python2.7/dist-packages/requests/api.py(57)request()
-> with sessions.Session() as session:

It's worthwhile to note that it's possible to import and set breakpoints in dependencies even before your code has done any importing itself.

Setting a breakpoint with a condition

Let's say we want to break in the example file's bar method, but only when the parameter value is equal to "foo". This can be incredibly useful when we don't want to break into program execution on every iteration of a function or method:

$ python -m pdb example.py 
> /home/dbrecht/src/p/playground/example.py(1)<module>()
-> import requests
(Pdb) b bar, value=="foo"
Breakpoint 1 at /home/dbrecht/src/p/playground/example.py:8
(Pdb) c
foo
bar
> /home/dbrecht/src/p/playground/example.py(9)bar()
-> print(value)
(Pdb) value
'foo'

Setting a temporary breakpoint

tbreak is another useful way to set breakpoints if we only want to break into execution once. The breakpoint is then automatically discarded. In this example, we only want to cause a break at the first call into bar:

$ python -m pdb example.py 
> /home/dbrecht/src/p/playground/example.py(1)<module>()
-> import requests
(Pdb) tbreak bar
Breakpoint 1 at /home/dbrecht/src/p/playground/example.py:8
(Pdb) c
foo
Deleted breakpoint 1
> /home/dbrecht/src/p/playground/example.py(9)bar()
-> print(value)
(Pdb) value
'bar'
(Pdb) c
bar
foo
<Response [200]>

These methods have definitely been useful to me in the past. If you didn't already know about them, hopefully they will be a new tool to add to your debugging arsenal!

For instance, when running on an intentionally immutable container ↩

You will pry vim from my cold, dead hands

Demian Brecht — Tue, 03 Mar 2020 20:13:31 +0000

I get funny looks from people quite often.

Random person: "What IDE do you use?"
Me: "I don't use an IDE unless I absolutely have to. I use vim."

There's that funny look again.

"Why on Earth would you use something so archaic?!"
"How can you live without a GUI-driven debugger?!"
"Why would you want to spend half your life configuring your editor?!"

Those are just a few of the typical questions that accompany those funny looks. Here are my typical answers for posterity's sake:

On using an archaic editor

Yes, it's archaic. But hey, there are advantages to being archaic other than being able to pull the old "I've been doing this longer than you've been alive" line. Because it's archaic, it's literally the single most commonly available editor on *nix-based systems. If vim isn't available, you can usually rest assured that vi is. If you're accustomed to most of vim's basic features, you won't feel entirely out of place in vi. In today's world of distributed systems, having the ability to speak nearly each and every distro's editor language is an incredible useful skill. I feel as much at home editing on a RHEL system as I do on Debian as I do on OSX.

On living life without a GUI-driven debugger

I've actually found that there's elegance and freedom in using command-line debuggers directly. Yes, there is a relatively steep learning curve (I'm looking squarely at you, gdb). Yes, setting a breakpoint will likely take longer when on the command line or may be a little unintuitive (I'm looking squarely at you import pdb; pdb.set_trace()). And yes, once you get into bed and begin to love using command line debuggers, you may catch yourself spending hours trying to continue living in your beautiful, magical world with languages that don't support it or support it very well (I'm looking squarely at you Java).

But, once you get past those hurdles, the flexibility and power that you have at your fingertips is really unparalleled by anything else. Oh, and did I mention that debugging on a remote machine is as easy as SSH'ing into it and running the debugger in the shell¹? Good luck getting your <insert favorite IDE here> to do that across bastions or docker containers².

On spending half your life in config

Well, here's the beautiful thing: I don't. To be fair, there was a day that I spent a ridiculous amount of time configuring a zsh shell and ran all ridiculous number of vim plugins to be all 1337. Problem is, they're not easily portable, especially when you start throwing ephemeral containers and VMs into the mix. I learn to rely on the near bare bones offerings that vim has. Here's my current .vimrc³ (pathogen is only used for solarized):

execute pathogen#infect()

"--------------------------------------------------------
" general 
"--------------------------------------------------------
set nocompatible
filetype on
filetype plugin on
filetype indent on

set nobackup
set noswapfile
let mapleader = ','

set noerrorbells
autocmd! GUIEnter * set vb t_vb=

" status 
set ls=2
set statusline=%t[%{strlen(&fenc)?&fenc:'none'},%{&ff}]%h%m%r%y%=%c,%l/%L\ %P

" general
set background=dark
colorscheme solarized 
set tabstop=4
set shiftwidth=4
set showmatch
set number
set smarttab
set linebreak
set nowrap
set autoindent
syntax enable

" rfc
au BufRead,BufNewFile *.rfc set filetype=rfc
autocmd Filetype rfc setlocal textwidth=72 softtabstop=3 tabstop=3 shiftwidth=3

" yaml
autocmd Filetype yaml setlocal expandtab textwidth=79 softtabstop=2 tabstop=2 shiftwidth=2

" python
set expandtab
autocmd Filetype python,rst setlocal expandtab textwidth=79 softtabstop=4
"autocmd BufWritePost *.py call Flake8()

" markdown
au BufRead,BufNewFile *.md set filetype=markdown
autocmd Filetype markdown setlocal textwidth=80

" rst
au BufRead,BufNewFile *.rst set filetype=rst
autocmd Filetype rst setlocal softtabstop=3 tabstop=3 shiftwidth=3

The above is simple enough that I can easily set the most important settings directly within an open editor without having to open a reference guide or weed through hundreds or thousands of lines of configuration. But there's also just enough to keep me happily editing files in my primary language (Python) and make adjustments should I start writing other languages again.

At the end of the day

In no way, shape or form am I saying that one shoe fits all. I don't believe that everyone should adopt my editor of choice. It's not the One True Editor (although I'll never admit that in person). Yes, there is some masochism involved. It's simply the editor that has worked best for me over the years and even though I try new IDEs (PyCharm, VS Code⁴, Visual Studio, Emacs, etc), I always find myself coming back to the warm, comforting security blanket that is vim.

So yes, you will have to pry vim from my cold, dead hands.

Of course, this assumes that the debugger is available on the target system ↩
Although support for this may be getting better ↩
Yes I know there are little niggly issues with it, so pedants please put your pitchforks away. ↩
To be fair, VS Code was the one editor that held my attention for the longest time. It's pretty damn slick. ↩

DEV Community: Demian Brecht

Automating Android Burp API Testing (Because Rebuilding This Sucks)

Gen AI: Feeding the dormant hacker

Dude, I'm slagging your code. Not you.

Entry points in Python

What's an entry point?

Keeping it simple: Python scripts

The downside

Leveling up: What's my name?

The downside

Come together: Script organization

Add a scripts directory to your project

And now for something completely different: entry_points

Gettin' jiggy with it: Single entry point

You're just a wee bit more dangerous now!

Why the hell is my code so slow?! (aka performance analysis in Python)

Setting the stage

The feature

What's slow?

So what to do?

Righting the wrongs

Hold on, WHY is <str>.format() slow?

Wrapping things up

The lesser known (but incredibly useful) way of settings breakpoints in Python

Setting a breakpoint with (filename):lineno

Setting a breakpoint by function

Setting a breakpoint with a condition

Setting a temporary breakpoint

You will pry vim from my cold, dead hands

On using an archaic editor

On living life without a GUI-driven debugger

On spending half your life in config

At the end of the day

Add a `scripts` directory to your project

And now for something completely different: `entry_points`

Hold on, WHY is `<str>`.format() slow?