Earlier quoted context omitted.
Amazing! What game was this for? I was involved in the RE efforts around UO way back in the day.
Gundam Evolution, going by comment history.
Different plot/game mechanics but armored core 6 is great if you like mecha
MitmProxy2Swagger: Automagically reverse-engineer REST APIs
51–60 of 82 posts
Re: MitmProxy2Swagger: Automagically reverse-engineer REST APIs
#52[flagged]
I think HAR export consumption lets you avoid the whole MITM part if we are talking about website API detection
Re: MitmProxy2Swagger: Automagically reverse-engineer REST APIs
#53Obvious question: How to protect against this ?
I find this confusing because the point of an API is to be known, yes? Otherwise who's accessing it?
It's a valid desire, but you have to be really dedicated to the effort to block it, in practice.
You might intend your API to be consumed only by your own clients. E.g. your published mobile apps.
A well-designed API won't allow a third-party client to do anything that your own client wouldn't allow of course. Permissions are always enforced on the back end.
But there are many cases where a user might want a custom/different client:
If your mobile apps are not awesome, or if they deprioritize a specific use case, or if they serve ads ... or even if your users want to automate some action in your service...
If your service is popular enough (or you attract a certain kind of user), you will have some people building their own clients.
Re: MitmProxy2Swagger: Automagically reverse-engineer REST APIs
#54Obvious question: How to protect against this ?
I find this confusing because the point of an API is to be known, yes? Otherwise who's accessing it?
Not necessarily. A common pattern is to build a 'private API' intended to be used by one's own front-end applications. For example: most client-rendered applications, like the Airbnb example on this page.
Re: MitmProxy2Swagger: Automagically reverse-engineer REST APIs
#55Again, this is the very easy part of the reverse engineering API process that most tools can do, similar to API Parrot and the rest of them. This is not hard to do. The hard part is that inevitably, all these internal APIs will just add aggressive CAPTCHAs, Device Check, fingerprinting, etc to prevent common drive by re'ing. Easy to add these on the defence side, and extremely difficult to bypass on the other side. I…
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.
Re: MitmProxy2Swagger: Automagically reverse-engineer REST APIs
#56perhaps a n00b question, but would this work, or is there something similar for apps, specifically android apps?
I use burp suite combined with Frida (which can remove root check and override ssl pinning).
Re: MitmProxy2Swagger: Automagically reverse-engineer REST APIs
#57Again, this is the very easy part of the reverse engineering API process that most tools can do, similar to API Parrot and the rest of them. This is not hard to do. The hard part is that inevitably, all these internal APIs will just add aggressive CAPTCHAs, Device Check, fingerprinting, etc to prevent common drive by re'ing. Easy to add these on the defence side, and extremely difficult to bypass on the other side. I…
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…
I think you have a misunderstanding here.
The API needs to be "public" because the app uses the internet to communicate back to the home server.
The API is not "public" in the sense that the app developers want anybody to use it; they just want their app to use this API. So they don't write publicly accessible documentation about it because they don't want to encourage its use.
A tool like MitmProxy2Swagger lets you run the app and record all of its API calls so that you can use this unadvertised API.
Re: MitmProxy2Swagger: Automagically reverse-engineer REST APIs
#58did i miss something or why are there TWO (2) "magically reverse engineer REST APIs" projects on the HN front page right now? is there some offline beef going on? (screenshot in case this goes away https://x.com/swyx/status/1874762725383188502 )
[flagged]
Re: MitmProxy2Swagger: Automagically reverse-engineer REST APIs
#59did i miss something or why are there TWO (2) "magically reverse engineer REST APIs" projects on the HN front page right now? is there some offline beef going on? (screenshot in case this goes away https://x.com/swyx/status/1874762725383188502 )
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
Yeah, that's where I got the link from.
Re: MitmProxy2Swagger: Automagically reverse-engineer REST APIs
#60Earlier quoted context omitted.
I find this confusing because the point of an API is to be known, yes? Otherwise who's accessing it?
It's a valid desire, but you have to be really dedicated to the effort to block it, in practice. You might intend your API to be consumed only by your own clients. E.g. your published mobile apps. A well-designed API won't allow a third-party client to do anything that your own client wouldn't allow of course. Permissions are always enforced on the back end. But there are many cases where a user might want a custom/d…
Those sound like bad use cases for a client-server model with public endpoints, then? I mean, you could cert-pin yourself in the client app, I guess.