alt.hn

1/22/2026 at 4:45:52 PM

Reverse engineering Lyft Bikes for fun (and profit?)

 https://ilanbigio.com/blog/lyft-bikes.html

by ibigio

1/22/2026 at 5:03:15 PM

Howdy.

Back in 2019 I reverse engineered the lyft bikes api to unlock them from my bed. It's one of my favorite stories, and after telling it dozens of times I finally decided to write it up in its full technical glory.

I used to love learning about security through blog posts/writeups, so I tried to include as much detail as possible. Let me know if you like this style!

by ibigio

1/22/2026 at 8:32:17 PM

Believe it or not, straight to jail! Just kidding, great writeup. I know it's not groundbreaking, but does surprise me how many products don't bother with rate limiting controls.

by spydum

1/22/2026 at 10:51:58 PM

i actually think a quick-fix was setting a rate limit. which sadly thwarted my brute-forcing, but did not actually fix the race condition itself. though it's a very fair "kid, stop it" response until they fixed the race condition.

by ibigio

1/23/2026 at 7:34:47 PM

Rate limiting is a stopgap, not a fix. I would have expected a transaction lock in Postgres (SELECT FOR UPDATE) to serialize the requests. Or a Redis mutex if they are worried about database contention.

by storystarling

1/22/2026 at 8:53:02 PM

You'd generally expect a company like Lyft to pin its certificates, so it's notable that they don't. Any ideas as to why?

by MarleTangible

1/22/2026 at 10:09:30 PM

Pinning certs has generally been discouraged for a while afaik. It's pretty trivial to bypass, at least on Android where you can side load easy, and it's a pain in the ass to manage with a huge potential to just take down your app if you mess it up

by vimda

1/22/2026 at 9:08:32 PM

If it's intentional, the only thing I can think of is access from corporate networks where SSL-intercepting proxies are absolutely common.

by ale42

1/23/2026 at 10:11:18 AM

I see the lack of cert pinning as a sign of having a good security team. Pinning is usually implemented as "we had an external security audit and their report said we should". Security auditors and pentesters tend to add this kind of crap (alongside root detection and obfuscation) to their reports to pad them out and make their work sound more valuable to the paper-pushers. So either Lyft had their audits done by a competent provider, or their staff know enough to filter this bullshit out. Either way, props.

by franga2000

1/22/2026 at 9:47:55 PM

> Geofence bypass: As far as I understand, there's no easy way to enforce a geofence server-side other than timing, consistency, etc. You sort of just have to trust whatever the phone tells you.

There's no fool proof method but you can make it very hard and impractical.

Both Apple and Google offer attestation mechanisms to confirm the integrity of the App and Device Environment that it's running on. This ensures that the API requests are coming from an attested device.

To mitigate the MITM attack you can use TLS Certificate pinning on sensitive API requests.

You could have the server side API provide a session specific signing token that the App uses to sign payloads attached to API calls.

by cptskippy

1/23/2026 at 2:29:30 AM

There are attestation mechanisms, but huge portions of a public user-base (especially android) don't pass that check because their device is too old, or their OEM sucked, or something something mediatek SOC, or <insert esoteric detail within the attested data that fails check in opaque way>

In my experience, all forms of attestation start to become impractical at scale unless you have a fairly homogeneous, well-patched fleet. This is particularly heinous for TPMs, where I've observed TPMs coming off one STM line having invalid EK certs, but other STM TPMs of the same model are fine. Or the platform firmware stamped out onto the motherboard has a bug in how it extends PCR0 and the event log is just borked forever, and so on... Totally unworkable.

by minimaltom

1/23/2026 at 7:02:04 PM

That's a fair and valid point. Those are concessions that would need to be measured, impact analysis done, and decisions discussed on an ARB meeting.

I was simply pointing out that there are mechanisms that exist today one could use to better secure critical functions.

by cptskippy

1/27/2026 at 5:04:41 AM

Fair note! Just highlighting that this niche is uniquely screwed and I wouldnt wish ironing it out under the knife on anyone lol

by minimaltom

1/23/2026 at 10:22:27 AM

1. This was not a mitm attack, it was lawful mitm inspection of a user's own traffic. Mitm attacks are prevented by TLS and the system CA store already.

2. Please don't give people bad ideas. This is how we get bikeshare apps that don't work on rooted/old/GrapheneoOS/... devices and further entrench google's position in the Android ecosystem.

If your security depends on devices faithfully reporting their location, you've already lost. Get a whiteboard, start from scratch.

by franga2000

1/23/2026 at 6:59:28 PM

> This was not a mitm attack

My intent was not to color or frame the activity but to use shared understood knowledge to convey the concept. It's like the terms blacklist and whitelist. Yes they're rooted in racism, and gosh darn it if everyone doesn't still use them because we know immediately what they are and there no better term. On the flip side we successfully switched from master to main.

If you don't want people saying "mitm attack" you gotta come up with something that rolls off the tongue a little better than "it was lawful mitm inspection of a user's own traffic".

by cptskippy

1/23/2026 at 9:06:00 PM

The wording is only secondary to my point, which is that this isn't something to prevent. It's not "a security thing". You said "to mitigate the MiTM attack". It's not an attack and nobody should be trying to "mitigate" it. If an app vendor in trying to evade inspection by the user, they're either being shady or incompetent.

And no, most people at least in the reverse engineering circles I'm in/follow, don't say "MiTM attack" when things are done by the user with consent. I've heard MiTM-ing as a verb, MiTM/SSL/TLS proxying/inspection/interception or even (incorrectly) SSL stripping (and surely some more that I don't remember).

by franga2000

1/23/2026 at 2:26:47 PM

funny thing, that: https://www.gfaker.com/

Apparently you can get dongles for iPhones to do GPS spoofing, because apparently(?) iOS can take an external GPS source(?!?).

by kotaKat

1/23/2026 at 6:15:08 AM

I used Charles to help me get endpoints for controlling my automatic cat toilet. The Chinese based iOS app was horrible to use and who knows what data it collected.

After getting the endpoints, I was able to plug it directly into Home assistant.

by adamgoodapp

1/23/2026 at 1:10:21 PM

> cat toilet..... iOS app....data

I'd like to think this is a satire of the Internet of Shit^H^H^H^H Things. But I doubt it.

by GJim

1/27/2026 at 11:25:22 PM

Most amazing tech blog I’ve read this week. What a great read!

by ykhli

1/22/2026 at 8:35:12 PM

You never know with corporations. Consequences range from "federal pound-in-the-ass prison" or "here is $500".

by sampton

1/23/2026 at 1:14:38 PM

> pound-in-the-ass prison

Care to explain your use of this term?

by GJim

1/22/2026 at 10:29:42 PM

you've unlocked hundreds of bikes under your account. That would mean you've reserved the bike and therefore have to pay for damage/loss of property?

by knowitnone3

1/22/2026 at 10:53:13 PM

if i would have actually unlocked all bikes then yes, they would have been under my account and i could have been in deep trouble. fortunately, (I made sure) that did not happen :)

by ibigio