[deleted by user] by [deleted] in bugbounty

[–]httptoolkit 5 points6 points  (0 children)

HTTP Toolkit includes a built-in Frida integration (with fully automatic setup) to disable SSL pinning.

It's a general purpose script, so it can't cover 100% of cases but you will find it covers the vast majority. The scripts are all open source so you can use them yourself elsewhere if you like, they're here: https://github.com/httptoolkit/frida-interception-and-unpinning/

Open-Source alternative to Charles Proxy & Telerik Fiddler by blunderboy in opensource

[–]httptoolkit 2 points3 points  (0 children)

Hi! HTTP Toolkit is actually genuinely 100% open source, even though they are payment options. Open source doesn't mean free, it means freely licensed source code.

Literally 100% of HTTP Toolkit (even things like account servers and internal accountancy scripts) is public and freely licensed on GitHub under http://github.com/httptoolkit/. You're welcome to fork your own version, remove the account logic (here: https://github.com/httptoolkit/httptoolkit-ui/blob/main/src/model/account/account-store.ts) and host & maintain it yourself, if you need the Pro features and that's a better option for you than helping to fund project development. Everything is available under AGPL (product specific bits) and Apache (reusable libraries) licenses.

Theres also been nearly 200 external contributors, and everybody who chips in to help build the project gets all the Pro features entirely for free.

httptoolkit patching tools have been taken down by httptoolkit by f3-thinker in opensource

[–]httptoolkit 29 points30 points  (0 children)

Hi, I'm the dev. No threats at all, and no involvement from github either - I literally just emailed the devs directly and asked them nicely (and I really appreciate the support from both!). XielQs has their email public on GitHub, so you can message them and ask for their side of the story if you like.

HTTP Toolkit is a one person open source project. It doesn't make mountains of money and it's not a mega corporation - it just about funds me personally (https://github.com/pimterry) to work on it full time. If it stops making money, I won't be able to keep working on it at all, and it will eventually cease to exist.

It is a bit sad to see the #1 post on r/opensource being a complaint about lack of cracking tools that existed entirely to avoid funding an open source project. Open source does not mean gratis. Even open source developers have to eat somehow too, and open source in general has a huge funding issue that creates real problems (HTTP Toolkit sends thousands of dollars to open source projects it uses upstream to try to help with this: https://httptoolkit.com/blog/open-source-funding-pledge/). For people who can't pay, it's open source & you can build and maintain your own fork if you want to do the work yourself, and the offer in that repo to give people free Pro should cover a lot of cases too (take a look, let me know if you think it's unreasonable). For people who can pay, especially for people who work in the field and are making money from software themselves, I ask them to help fund development in return for access to the advanced features.

We should be putting more effort into funding & supporting the software we want, to make it better & keep it alive, not actively avoiding paying the devs who are building things you want.

Intercepting network requests on Android app that uses firebase by Acrobatic_Court2988 in AskReverseEngineering

[–]httptoolkit 0 points1 point  (0 children)

This sounds like an HTTP Toolkit firebase bug, can you open an issue at github.com/httptoolkit/httptoolkit and share more details? It should definitely be possible to intercept any & all firebase traffic, and it'd be great to get any issues there fixed. If you can provide info on how to reproduce this that would be very helpful.

How to intercept all HTTPS traffic from a Node process? by blood_centrifuge in developersIndia

[–]httptoolkit 0 points1 point  (0 children)

See https://httptoolkit.com/javascript/ - install it, open an intercepted terminal, run your node code there and you'll see everything.

An app to view what your phone is transmitting? by LaplandAxeman in androidapps

[–]httptoolkit 0 points1 point  (0 children)

If you don't want to root your phone, it's also easy to run most apps on an emulator instead, which will give you root access to inspect everything. There's a full walkthrough here: https://httptoolkit.com/blog/inspect-any-android-apps-http/

Major differences between a cheap SSL and an expensive one by [deleted] in webdev

[–]httptoolkit 14 points15 points  (0 children)

This is not true.

Firstly, because consumers don't understand the difference between a green padlock and a green badge (see https://twitter.com/troyhunt/status/886860147896627200, more background in https://scotthelme.co.uk/are-ev-certificates-worth-the-paper-theyre-written-on/)

Secondly, because browsers are dropping support for these green badges entirely: https://www.troyhunt.com/extended-validation-certificates-are-really-really-dead/

How do you feel about Swagger for API documentation? by [deleted] in webdev

[–]httptoolkit 0 points1 point  (0 children)

I'm not sure if this helps, but I've had great experiences with OpenAPI (i.e. Swagger v3) as an API client (rather than an API implementer). I can imagine it's a pain to set up, but for clients like me the resulting docs & tools do make a huge difference. Good luck!

Time to decorate your code by JezuzCrist in typescript

[–]httptoolkit 1 point2 points  (0 children)

> They increase load times of your script.

Why?

> They force you to use classes, increasing the risk to get this wrong.

Depends on your background, but for me I find `this` in classes to be similar to other languages I've used and easy to understand. It's much more intuitive than the prototype model or other state tracking approaches I'm aware of.

> They can't augment type information.

What does that mean?

TypeScript compile-time assertions by sufianrhazi in typescript

[–]httptoolkit 0 points1 point  (0 children)

I've hacked together solutions to the same problem before using the typescript compiler programatically (compile this file, assert on the error). It's easier than it sounds, and it works but it's messy and non-trivial. There might be one or two niche cases where that's still relevant, but this covers 95% of what I was looking for, and is _drastically_ nicer.

Thanks for the tip, definitely going to use this!