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.

Thanks! The tool has a built in certificate authority (CA) to generate TLS certificates. So to intercept TLS traffic from a phone, you export the CA's root certificate and import it onto your phone. If you're on PC, you can also launch a browser preconfigured to intercept traffic.

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

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.

The OWASP testing guide is a very good start: https://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf

It covers the process of a web application test and explains 90% of the vulnerabilities you'll find in web apps and how to test for them.

I'm sure that the 911 operator won't mind, especially if it is or could be a genuine emergency.

In which case the NSA say "Oops, it was a genuine mistake. Sorry." With 200,000 lines of code, there will almost certainly be unintentional security holes that haven't been found.

I don't necessarily think there will be one, but I wouldn't be surprised either.

Security flaws can be extremely subtle and 200,000 lines of code is a lot to review... Given that there's plausible deniability (we didn't do it intentionally, it was a genuine bug!), if you were them, wouldn't it at least cross your mind to try it?

Also, at some point, if it becomes popular, some sysadmin at a large foreign government agency or company will forget to firewall off a box running it (ignoring that they could also be connecting back directly - automatic updates anyone?)

They provide a list of backup codes which you're meant to print and put in your wallet.

> My reading is that you couldn't brute force it, you'd have one chance to set up the iframe with the cookie file in it which needs the username, or at least just one chance per clickjacked drag action that the user executes for you.

But if you made some sort of Javascript "game" (which used drag and drop) and required the users to register their name first, then you should have a fairly high chance of guessing their username without CIFS.

> Cookiejacking Exploit Hits Internet Explorer, Targets Your Login Info

This makes it sound like they're going to be able to get your password... No major website will be storing your password in a cookie. At worst the attacker will have your session id meaning they can log in as you until you log out of the website in question.

Mine cost me nothing. I got some wood scraps from a local kitchen factory and built a couple of tables, at the right height, to stand on top of my standard desk.

Yep, that's pretty much how they work. I can't find the details of it now, but the "smart" ones also do some colour transformations on the image so detection will work irrespective of what race the people in the porn are.

Relatively... The browsers themselves won't write anything to disk but this doesn't stop things like plugins (EG: Flash, Java, media players, etc) from writing to disk, or lower level operating system functions (IE: Swap) writing to disk. How likely is it that these will write to disk? I don't know exactly, but it would vary between browser plugins and operating systems.

For example: I use Linux, with no swap, and with few browser plugins and would consider myself fairly safe when in incognito mode.

You'd be surprised at what your web browser and operating system cache... That one session where you forgot to switch to incognito mode could leave hundreds of images on the hard drive ;)

There are two common approaches that forensics tools use: 1) It could be scanning the file system and looking for all files (both present on the drive and deleted), which have an image extension on the filename (.jpg, .gif, etc). The advantage of this approach is speed. 2) It could be going through looking at the raw data on the hard drive, and search byte-by-byte for the magic headers at the start of every image file. For example all GIF files start with GIF87a or GIF89a. This approach takes much longer, but would find all files (possibly even ones deleted years ago, well before the current OS install), and works irrespective of which operating systems are installed.

Given the screenshot, I'm guessing it takes the first approach.

EDIT: There are open source tools for Linux which take the second approach... Probably the best is called Foremost.

They're satellite dishes used for intercepting satellite communications, but they're covered in domes: http://en.wikipedia.org/wiki/GCSB_Waihopai

From a security perspective, this is also a bad idea. One of the golden rules of security is to validate all input. Anything which the programmers didn't expect and check for can potentially be used as part of an exploit.

I do this and the biggest issue I've had so far is trying to talk with people from the businesses in my target market, who only work from 9 until 5.

Our University had one of these courses too. They were finding that without a course like this, too many students were taking the stage one computer science courses hoping to improve their general computer skills. After introducing this course, the failure rates of the programming and data structure courses went down dramatically.

Okteta's beautiful from a user interface perspective, but like most hex editors it fails when trying to deal with large files. There are very few hex editors around that will open files that are larger than the amount of RAM that you have.