Some points of difference from the existing tools:
* The UIs are built using the native platform frameworks, meaning they look and behave like other applications on the desktop.
* It has a fully embedded and integrated Python scripting engine.
* It’s fully native meaning it’s nicer on system resources.
* It has a number of built in scripts to automate reconnaissance, content discovery, authorisation checks, etc.
* The core of it is open source.
I'm really keen to get any feedback!
The macron (āēīōū) lengthens the vowel sound (Latin has this too) otherwise pronounce the vowels the same as Spanish. Lengthened vowels are harder for most American speakers to get right: https://youtu.be/tPi2jtU7Tl4?t=6m23 Vowel length matters in New Zealand (e.g. pronunciation of can't causes problems).
Perhaps could be added to the docs?
Also, don't listen to those who say things like "soo, like Burp?" (the ones who do it to belittle the effort).
People used to say (and still do) Postman is "just a wrapper around curl", and I was like, "So is Operating systems, they're a wrapper around hardware, and C is a wrapper around assembly, and Python is a wrapper around "I don't want to manage memory, let's make a web app instead", What's your point?" lol Postman is now worth couple of billions btw.
You're doing a great job - keep at it. Ping me if you needed testers (I work in AppSec/Red teaming).
Glad to see more competition in the space, we also went the route of using an API (built in Rust). We decided to focus only on a web UI in vue.js I will look how you are storing data and all, we went the sqlite way to save on RAM.
Looks like we are both going after Burp, it's not going to be an easy ride for sure. What we found is it is very hard to make people in enterprise switch and the 100$/y pricing really isn't enough to build a serious business without enterprise clients at a higher price point.
Anyway, best of luck!
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!
Yes and your 400$ plan is a good idea. But we did the math at 100$ (Port Swigger financial records are public) and it is not easy to make them work as a full time gig. And it's not really possible to get funded just for that market, it would need to 10x to be VC viable.
If you ever want to talk further, do shot me an email (emile [@] caido.io).
This may be a really broad question, but would you mind touching on why you developed this in Rust? Is that the reason why this application feels snappier than Burp (JVM), or is it just less taxing on system resources? Please feel free to tl;dr it if that's easier :)
Also, the coolest looking feature is the AI assistant undoubtedly -- is there any chance that customers can BYOT in the future and supply a personal OpenAI API token for example?
We developed it in Rust because we wanted to create a client/server architecture that you can deploy everywhere (Caido runs even on a rapsberry pi). We worked a lot on the frontend to make it snappy too, so its a combination of both.
Yes for sure, there is a privacy concern too with us forwarding request. It is in the issues of https://github.com/caido/caido.
One UX point: I may have missed this, but when I start an injection attack, it would be nice to see a real-time table of the output so that I can see which injections have been tried (kind of like how you can see it in Burp Suite with Logger++ or the sub-window that opens up when you start an Intruder attack). Totally respect a conscious choice to not go down this (potentially) resource-intensive 'view', but curious if that's on the roadmap. Right now I just get a spinning animation after I hit Run, and I don't see any output in the sidebar where it says "Scans will be shown here once they have started".
In all honesty, I probably will stick with Burp Suite for my bread-and-butter web app testing flow (also helps that my org pays for a Pro license), but I want to thank you for the effort put into this and the courage to explore a new modality (web app testing without a resource-heavy proxy tool like Burp).
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.
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.
I won’t pay for subscriptionware. I switched from Premiere to Resolve just to avoid having to be someone’s MRR and I now pirate Lightroom pending its replacement.
It’s a terrible, user-hostile model.
I don’t think developers should be entitled to payment in perpetuity for work they did once.
I'd never buy subscriptionware for hobbyist or fun purposes. Or so I thought. Because I do pay for a WoW sub :/
You seem to be conflating future updates with the software as it stands today.
I am not buying support, I am not buying upgrades. I’m buying software once today (and even that is an exception, as the majority of my tools, including 100% of the most critical ones, are free software).
Additionally, I find proprietary software vendors who do open source cosplay (“open core” is something made by people who dgaf about software freedoms) to be generally disdainful. Open core is a slap in the face; nobody is forcing proprietary software vendors to be in denial about being proprietary software vendors.
I have one question though, how do you intercept TLS. Let’s say i would connect my phone to your proxy, and try to search something on the web. Wouldn't the connection not be trusted?
This is the standard pattern for these kinds of tools.
As it's not always a straightforward process for people who haven't done it before, there's instructions for a variety of platforms in the documentation: https://docs.pakikiproxy.com/#/getting_started/intercepting
Cross platform native GUI and you are doing this all alone? Feels very ambitious.
Are you planning to go full time on this?
What kind of stack are you using?
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).
Did a desktop app some years back using wxWidgets. Slightly less ambitious than doing separate native UIs for each platform like you're doing here, but still gave me a native enough feel that I was happy with the compromise.
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.
This one fuzzes, so it's also an injecting proxy.
I've never liked Burp. Java, requires GUI, and subscription costing 365 USD/year. Where without a license you cannot even do trivial automated stuff (forcing you to click 'OK' all the time; easily circumvented with e.g. AHK).
At the very least a personal license for Pākiki is only 100 USD/year. Which is a lot less barrier of entry for amateurs (if you're a for-profit web pentester /care). How does Caido and Pākiki compare to mitmproxy?
It runs entirely in the browser so it uses the browser "native" frameworks.
