pipeline_tux

I haven't tested with either of those unfortunately, but I do regularly test when connected to a VPN using OpenVPN.

From a PC/Mac, if you can reconfigure your browser to proxy traffic via Pākiki, it should work with them (and then subsequently route traffic over the VPN).

Unfortunately I'm not sure what the network routing/proxying behaviour is on mobile when you have a VPN like those configured, but my assumption is that it probably wouldn't work.

Thanks for the kind words and feedback!

There should be a real-time table when you're running a scan so that sounds like a bug. Having a real-time table is surprisingly light on resources. I haven't done a huge amount of testing on WSL, so I'll take a look and fix it in the next release.

Thanks for the suggestion. I've added it to the todo list.

Hi!

Yeah, it seems like we've identified similar problems and addressed them in reasonably similar ways. Likewise, I've went with SQLite as the project file format, with the files being compressed when saving so that users can transfer/share the project files easier.

Thanks for the insight on the pricing. I've been working under the assumption that if a few people on my team at work wanted to spend $100US each on tools, that they think would improve their productivity, it'd be a no-brainer and easy to justify.

I definitely think that more competition in this space is good for the industry as a whole, and likewise wish you the best of luck!

Thanks! Yeah, it was definitely an ambitious choice, but I think it results in a better product, and I'm really happy with how it's turning out. For now it's just me part time, but I'm hoping to go full time or near full time next year.

In terms of stack, there's an open source core written in Go which exposes an HTTP API. The UIs then use that API. There's a cut down web frontend written in VueJS (useful for forward deployments), a GTK frontend for Linux written in Vala, and the MacOS version is using Swift/SwiftUI (with some use of AppKit where that's not applicable).

Then (because this isn't ambitious enough) once those are polished, I plan on doing a native Windows frontend too (likely using C# with WinUI 3, but to be confirmed).

Usability and performance (for example when deployed on lower-end customer machines) are two major ones. Admittedly they have been getting better over time.

It's also not uncommon to have sites behave a bit differently when running via Burp, so given it's not open source, it can be hard to diagnose/debug what's going on.

No, it doesn't unfortunately. In a professional testing world, we'd normally just ask clients nicely to disable that for our testing. If you're testing something where you don't have a relationship with the developers, then Frida is my go-to tool to get around that. Although once you've disabled SSL pinning, you can use Pākiki to intercept the traffic itself.

Correct. Burp is the main competitor, but it's been around a long time and I wanted to develop something from scratch to address a number of the problems myself and other pentesters have had with it.

Correct, ZAP is one of the main competitors, and the core functionality is the same. While there's a browser Head-up Display, the primary UI is still a Java desktop-based application.

Thanks! There's a few points of difference in terms of approach/philosophy.

Firstly, I really wanted to focus on usability. So there's a native UI on each platform, using GTK on Linux, and SwiftUI on MacOS. This means that we can integrate fully with the desktop, and adhere more easily to the human interface guidelines on each platform. I'm also not necessarily trying to go for 1-1 feature parity with Burp, so that I can keep the UI simpler (especially where good standalone tools exist).

I'm trying to target it to be more resource-friendly. Some of my pentesting colleagues at work struggle to run all of their tools in less than 32GB of RAM, and most need 16GB of RAM, and Burp is a not insignificant contributor to that. By comparison, I've been primarily testing this in a Kali VM with 2GB of RAM allocated, and while it doesn't always run smoothly, it often runs pretty well.

Lastly, there's embedded automation with Python scripts. There's a number which are built in, but it's also easy to expand on those and create your own. You can use those for reconnaissance, custom discovery of vulnerabilities or exploitation. I've got plans to expand that engine and capability even further.

Torrents are filling the gap where the traditional media companies are still failing. Here in NZ there are 7 different streaming services that I can immediately think of, each with exclusive rights to some content. I'm not paying $80 a month to sign up to each so I can watch their popular "exclusive" show they own the rights to.

If the rights-holders made their content accessible and at a reasonable price to consumers, torrents would disappear.

As someone who works in infosec, this doesn't surprise me at all.

I've tested many applications which claim to be secure, designed for security/privacy sensitive tasks, yet are very easy to compromise (simple OWASP top 10 stuff).

Even if the app developers are great and know their stuff, I can still see them slipping up on the distribution. It's normally handled for most developers and is outside the realm of any secure development guidelines they might be following.