Building Android versions of RFD #68
Replies: 2 comments 7 replies
-
|
I can't say about the 10-character limit. It probably comes from the length of RFD doesn't rely on hard-coded domain changes to work. Instead, I patch any "trust checks" that Rōblox clients use. Refer here for perhaps some more information. You can articulate these changes to ARM-compiled Rōblox binaries. |
Beta Was this translation helpful? Give feedback.
-
|
I have a lot of experience with APK reverse engineering. I can try to get as many information as i can from libroblox.so. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Ive been looking into whether this can work on Android. just collecting what might block it.
What I’ve been told / noticed
I was told it’s “hard” because the Roblox APK only accepts domains/IPs that are ≤ 10 characters. That means ngrok / no-ip hostnames won’t work. But I wasn’t told why this is hard, is it just baked-in checks, parsing limits, or something else in the native code?
The domains are inside libroblox.so. Id probably need to patch them, but then there’s also signature/public-key/integrity checks that I dont fully get.
I’m testing with an unmodded 2016 APK just to have a starting point.
(Want to get 2018 and 2021 working)
Ideas / questions
Could you bypass the domain length issue with /etc/hosts on Android? That would need root, but it might trick the APK into resolving a short fake domain to the right server. (I cant get root on my devices, so ill stick to modifying the libroblox.so file)
If not, then libroblox.so probably has to be patched. Has anyone found where the 10-char enforcement actually happens?
About the Join string: from the screenshot, it looks like it might be the payload the app expects. Would you inject that into the login flow (like simulating a Join button press), or is it smarter to hook the intent/URL the app normally uses?
The screenshot I attached looks like it might be the Join payload the client expects. My questions: is the Join flow handled purely client-side (so we can inject a payload during login), or does it require an authenticated session and server-side validation first?
Could the Join string be injected into the login flow (simulate pressing Join / overlay the UI), or is it cleaner to hook the intent/URL that launches a game?
My gut: even if we patch domains, the client will still need a proper login handshake (tokens, session setup) before Join will actually work so domain patching might not be the only work required. You don’t get the full game listing UI unless the client successfully talks to the real services.
Login/auth: wouldn’t the APK also expect some kind of login handshake before Join works? I don’t know if that’s handled in the same place as the domain stuff or if it’s a whole extra layer to patch.
Main questions
Why exactly is it “hard” to use >10 char domains on Android?
Has anyone mapped out the domain checks in libroblox.so
How much of the login/auth would break if we only patched the domains, is there more work needed to make Join actually function?
Cuz you dont really have a webserver where you can look at the games and stuff.
Did anyone start working on a android version and could help on this?
Is Android support even realistic right now to be comeing anytime soon?
Beta Was this translation helpful? Give feedback.
All reactions