Launch HN: Integuru (YC W24): Reverse-Engineer Internal APIs Using LLMs

Re:Launch HN: Integuru (YC W24): Reverse-Engineer Internal A... by loktarogar on Tuesday October 29, 2024 @08:59PM (#41990985)

In my experience reverse engineering is often the easy bit, or at least easy compared to what follows: maintenance. Knowing both when and how it fails when it fails (eg in cases like when the API stops returning any results but is still otherwise valid). Knowing when the response has changed in a way that is subtle to detect, like they changed the format of a single field, which may still parse correctly but is now interpreted incorrectly.

How do you keep up with the maintenance?

[ Parent | on HN ]

Re:Launch HN: Integuru (YC W24): Reverse-Engineer Internal A... by alanloo on Tuesday October 29, 2024 @09:37PM (#41991147)

We feel your pain with maintenance. We have plans to handle this by using LLMs to detect response anomalies.

From our experience, reverse engineering is still less prone to breakage compared to traditional browser automation. But we definitely want to make integrations even more reliable with maintenance features.

[ Parent | on HN ]

Re:Launch HN: Integuru (YC W24): Reverse-Engineer Internal A... by cphoover on Tuesday October 29, 2024 @11:33PM (#41991735)

Wouldn't something like snapshot testing from a scheduled probe be more effective and reliable than using an LLM?

Every X hours test the endpoints and validate the types and field names are consistent... If they change then trigger some kind of alerting mechanism to the user.

[ Parent | on HN ]

Re:Launch HN: Integuru (YC W24): Reverse-Engineer Internal A... by alanloo on Tuesday October 29, 2024 @11:47PM (#41991803)

if the types and field names change, our parsing script should be able to detect that so it should be covered. I was talking about handling the subtle changes that are undetectable by checking field types and names

[ Parent | on HN ]

Re:Launch HN: Integuru (YC W24): Reverse-Engineer Internal A... by sureglymop on Wednesday October 30, 2024 @02:17AM (#41992301)

I word say: it depends. I must've wasted days of my life trying to reverse engineer android apps with pinned certificates. It's crazy how hard it has become to just inspect the traffic on my own device that I bought and own.

[ Parent | on HN ]

Re:Launch HN: Integuru (YC W24): Reverse-Engineer Internal A... by loktarogar on Wednesday October 30, 2024 @03:54AM (#41992723)

Yeah I feel you on that. I wonder if this can deal with those difficult cases? This would be killer if so

[ Parent | on HN ]

Re:Launch HN: Integuru (YC W24): Reverse-Engineer Internal A... by sunbum on Wednesday October 30, 2024 @05:20AM (#41993164)

Just setup httptoolkit [0], it just works.

[0] - https://httptoolkit.com/

[ Parent | on HN ]

Re:Launch HN: Integuru (YC W24): Reverse-Engineer Internal A... by franga2000 on Wednesday October 30, 2024 @07:30AM (#41993764)

I'm gussing you haven't done this a lot? You can't easily add a cert to the system store without rooting, but then you need to bypass root detection. If the app uses cert pinning, you either need to hook it (also detectable) or patch it (error-prone and again, detectable). If the app is Flutter, you'll need to do some binary patching too.

[ Parent | on HN ]

Re:Launch HN: Integuru (YC W24): Reverse-Engineer Internal A... by buildfocus on Wednesday October 30, 2024 @08:46AM (#41994234)

If you have root, HTTP Toolkit will handle most of that for you - it can detect root via ADB, install systems certs automatically, and install Frida & intercept individual app targets with most cert pinning disabled (frida scripts it uses are here: https://github.com/httptoolkit/frida-interception-and-unpinn...).

No manual setup or config, just click a button and done.

Avoiding in-depth detection is left as an exercise for the reader, although there are a small set of existing countermeasures in there. In practice, there is definitely a very long tail of further cases of increasing complexity, with diminishing returns on automated solutions, but it turns out in practice you can automate quite a long way down that path and cover most normal cases.

Flutter is the one awkward case here I've found that doesn't fully work. Very interested to see if there are generalizable automated solutions there, or if the recent fork announcements mean the slow death of flutter anyway...

[ Parent | on HN ]