Amazing! What game was this for? I was involved in the RE efforts around UO way back in the day.

I do this a lot for my work. A tool like this that can help get me to a nice starting point is huge. Instead of developing a mental model of the API in my head by manually looking through API requests/responses in ProxyMan, this can start me off much more quickly. From there, the edge cases can be worked out.

Depends on the age of the tool. We work with a lot of legacy systems that actually want us to integrate with them but don’t have the dev resources to build a proper API surface. As a result, we end up doing a lot of painful reverse engineering. These tools look promising for purposes like this.

I curious as to why people would have a public API to begin with if they wanted to protect it from people using it. Then again, why would anyone have a public undocumented API in 2024 when a LLM can give you a cli tool to auto-generate 90% of the OpenAPI spec in a couple of hours? The last question isn't serious, I've worked in enterprise for decades and almost none of the tools organisations end up buying have good documentation for their API's. Not that those are publicly available, but still.

There are many cases where users are behind a forward proxy for security/compliance reasons. Most applications need to support these types of users.

Making a mitmproxy dump from a manual browsing session is more or less unblockable, barring some TPM or similar fuckery.

Usage of the API even with the protocol known OTOH can be quite easily made really hard.

Why would you tho?

If you're working against an GraphQL based API, you should be able to pull a schema file. And use that to implement your own API.

All you would get from an Mitmproxy is example queries and mutations. With the additional complexity of extra tooling to stich together the schema file

Presumably, because the closed source one got some traction, so people are pointing out the open source alternative.

Likely because of this comment[1] in the other thread which made people submit this link, and when multiple independent people submit the same link in a short period of time you're very likely to end up on the front page (this exact situation happened to me once)

[1] https://news.ycombinator.com/item?id=42568121

Offtopic and meta, but, you share a screenshot using Twitter/X? That's really bizarre to me. That is all, just had to say that.

Depends on the app. If it uses some online functionality probably yes. You could also try decompilation, it’s decent on java apps like android’s.

A MITM proxy isn't specific to any app, it's a forward proxy for your outgoing network connection. In case of an Android app you'd need to run mitmproxy on a machine in your network and setup the connection as proxy in your Android's network settings. Then you'd need follow http://mitm.it to install mitmproxys root certificate on the Android device (to trust the connection with TLS) and off you go.

EDIT: or rather follow the docs[0]

[0]: https://docs.mitmproxy.org/stable/howto-install-system-trust...

I've used this specific tool to help me reverse engineer the private API of an Android App.

The thing is, depending on how hardened the app is, you'll have to play with Android to allow this interception, mostly because of certificate pinning. Also I remember something about apps not using the system wide trusted certificates you install (IIRC).

I remember using a rooted device with LineageOS, and downloading the APK and modifying it with a tool so the self signed certificate for the mitm proxy works with it.

The mitm proxy docs have some links to tools that can do that [0] and you could also use an Android emulator if you don't have an extra phone to mess with it [1]

  0: https://docs.mitmproxy.org/stable/concepts-certificates/
  1: https://docs.mitmproxy.org/stable/howto-install-system-trusted-ca-android/

I use burp suite combined with Frida (which can remove root check and override ssl pinning).

Nothing is RESTy

> It's not very, let's say, RESTy. It has only one endpoint,

To be fair, from what I understand an actual(tm) REST API would only have a single defined endpoint[1]: the entry point. With every other endpoint being discovered from the responses. And also from your message I'm guessing a URI still uniquely identifies a resource (specifically through the "query" part of the URI, instead of the more common "path").

So, technically, assuming there's nothing too weird with that API, it seems like MitmProxy2Swagger is failing to detect a REST API.

[1]: Corollary: If an API is RESTful, it should be possible to rename any endpoint (except the entry point) at any moment in time without prior notice, and clients would not break as long as the response types/schemas are still supported by the clients. In-flight requests might fail with a 4xx, but after a retry they should go to the correct endpoint without any code change required.

What specifically do you want to protect?

Your first line of defence should be a secure API where an attacker doesn't gain anything by knowing it.

You can add obfuscation, but ultimately if the client is shipped to the user you must assume an attacker can reverse engineer it.

Build your API assuming anything public facing will be known. This includes anything downloaded to a device.

I find this confusing because the point of an API is to be known, yes? Otherwise who's accessing it?

for me, we cant 100% protect again this type of usage but we can minimize with good observarbility and monitoring tools that always check if user is run this via verified way (signed app,web or etc) or RE'ing the api <<

because guess what??? we are the creator of such system, its easy to detect bot/such case when you have good analytical data because this type of way does not give any "traces"