some guy doing an FCC hack permanent for RC pro Controller

pyrolator · Jan 20, 2023

FlowDrone said:
Those are generated in the .android folder automatically when ADB server starts on your machine for the first time.
From what I can gather, his script Authorizes your Key with the Controller... but I can't figure out how it does it (this is what I'm looking at now)
If I can figure out how to get Debug-level access to invoke ADB commands (specifically adb reboot bootloader and adb push) then I can push the modified ELF and .SO files to the filesystem and replace the existing... which (in theory) should be all that's needed to force FCC mode.

Great work, i hope you will found a way to get the FCCmod working again and we dont loose the Money we pay for the FCCMOD !

FlowDrone · Jan 20, 2023

While I'm working on this, can people here periodically check if the Server comes back online?
Use Online Port Scanner Powered by Nmap | HackerTarget.com and paste in the server's IP which is 47.100.49.90, then tick I'm not a robot and hit the "Quick NMAP Scan" button.
If port 443/tcp (https) shows "open" instead of "closed", it's likely the service is back up.

DAFlys · Jan 20, 2023

FlowDrone said:
Those are generated in the .android folder automatically when ADB server starts on your machine for the first time.
From what I can gather, his script Authorizes your Key with the Controller... but I can't figure out how it does it (this is what I'm looking at now)
If I can figure out how to get Debug-level access to invoke ADB commands (specifically adb reboot bootloader and adb push) then I can push the modified ELF and .SO files to the filesystem and replace the existing... which (in theory) should be all that's needed to force FCC mode.

If you figure that out we should also be able to patch the original smart controller which would be nice too

Bashy · Jan 20, 2023

I think the person will be back once their national holiday is over, the guy I've spoken to thinks early Feb

d-rive · Jan 20, 2023

pyrolator said:
Looks like "Our Money is just blowing in the Wind"

Paypal gave me back those 40usd. So, no money loss.
Tho, the fcc is still on my remote until the next update.
If he will resolve the problem with the server I will give him the money, if not, I just can feel sorry for him.

FlowDrone · Jan 20, 2023

I'd be interested to see if he gave us all exactly the same key... because, if he did, we might as well all file a PayPal claim and post the key in here!

FlowDrone · Jan 20, 2023

Another update: something is happening with the hack's server!
It would appear the service has been brought online on port 8443 instead of 443 (which doesn't help us much since we can't change the port number) and I can see that, occasionally, port 443 is coming online before vanishing.
I've got a monitoring tool running constantly to verify when the hack comes back online. I'll let everyone know if that happens before I manage to figure out how it works and basically make my own.

cah · Jan 20, 2023

You could try proxying 443>8443 locally to see if it's responding properly on the alternate port?

FlowDrone · Jan 20, 2023

cah said:
You could try proxying 443>8443 locally to see if it's responding properly on the alternate port?

I'm attempting this as we speak! Problem is you can't include Port numbers in host file changes, so it's difficult to say the least.
Another potential issue is CORS (Cross Origin Requests) which (given that this is an HTTPS request, albeit with a self-signed SSL cert) may be rejected if you cross origins.

cah · Jan 20, 2023

FlowDrone said:
I'd be interested to see if he gave us all exactly the same key... because, if he did, we might as well all file a PayPal claim and post the key in here!

PMd you mine

FlowDrone · Jan 20, 2023

Okay... Once the Chinese IP service resolves (which I can get it to do by making the request to the 8443 port instead of 443) it throws another request to 13.107.21.200 (a Microsoft Azure Cloud Load Balancer) which responds with the message: <h2>Our services aren't available right now</h2><p>We're working to restore all services as soon as possible. Please check back soon.</p>

FlowDrone · Jan 20, 2023

cah said:
PMd you mine

Saw it... they're different, so at least we know we aren't dealing with someone just sending us all the same key they paid for once and made a profit on

cah · Jan 20, 2023

FlowDrone said:
Okay... Once the Chinese IP service resolves (which I can get it to do by making the request to the 8443 port instead of 443) it throws another request to 13.107.21.200 (a Microsoft Azure Cloud Load Balancer) which responds with the message: <h2>Our services aren't available right now</h2><p>We're working to restore all services as soon as possible. Please check back soon.</p>

That's bing.com

C:>ping bing.com -4

Pinging bing.com [13.107.21.200] with 32 bytes of data:
Reply from 13.107.21.200: bytes=32 time=9ms TTL=119

FlowDrone · Jan 20, 2023

cah said:
That's bing.com

C:>ping bing.com -4

Pinging bing.com [13.107.21.200] with 32 bytes of data:
Reply from 13.107.21.200: bytes=32 time=9ms TTL=119

Yep, you're right... I'm using Wireshark, and the traffic was co-incidental (a separate Windows request occuring at the exact moment I get a response from the IP the hack is using).

FlowDrone · Jan 20, 2023

It's possible to trick the hack into achieving its initial connection on its default port and IP by going into your browser and navigating to https://47.100.49.90:8443/ (electing to continue to the site without valid security) If you do this then run the djifcc.exe program, it'll say "connect success !!" followed by "Tcp Thread exited" at which point it simply stops.

This suggests there's something genuinely broken with the service on their end, rather than any malicious intent to take our money and take away the patch we all need.
i'll keep trying periodically to see if it comes back up. If it does, I'll let everyone know immediately.
Meanwhile, continuing my quest to figure out how it this program manages to push the patch files (that we now actually have) onto the RC.

FlowDrone · Jan 20, 2023

Yup... this makes sense now!
The Web Service responding on port 8443 is intended to be Sincoder's "Remote Admin" interface. A request (without a URI) to that service will automatically start the main hack service on port 443 if it isn't running (a clever way for him to be able to restart things from his phone).
This is why the subsequent attempt to request from port 443 will succeed... however, that request actually returns nothing more than a failure response because the main service crashes on any request.
When the djifcc.exe program receives the failure response on port 443, it immediately terminates (since it cannot hope to continue)
That means we have to wait for Sincoder to return and fix the underlying cause of failure in the service... and of course we have no way of knowing when that may be, since we have no idea where Sincoder is, nor any way to contact him.

jbma · Jan 20, 2023

Well done guys. This is good info.

cah · Jan 20, 2023

Sounds all very plausible.

If it ever comes back we need a way to log the adb commands. If the payload isn't custom per-device, then that would allow you to load it

FlowDrone · Jan 20, 2023

cah said:
Sounds all very plausible.

If it ever comes back we need a way to log the adb commands. If the payload isn't custom per-device, then that would allow you to load it

Absolutely agreed and already on it...
Program that takes the place of adb.exe, and acts as a "passthrough". It keeps a log of every command passed to it, and passes each command along to ACTUAL adb... then logs the responses before returning them exactly as adb would.

cah · Jan 20, 2023

Tricky as they download adb.exe rather than use one already on your system. Might get away with creating a proxy adb.exe and making it read-only so it can't be overwritten. Would depend how the app handled error cases.