I didn’t quite understand the need for an injection attack. Once you had bought the domain and could respond to the devices‘ API calls, weren’t you in the driving seat already?
I actually had written more about the exploit & vulnerability in my original drafts but I cut it out because it was a bit boring to read.
You are correct that with domain control I am able to serve content to any sign but the content will only be loaded once at boot time. Any future updates would have needed to come from their defunct AWS IoT connection (ignoring full restarts).
Using the exploit I remove the connection to AWS IoT and update some of the code to better connect it to the recreated API so users can update their signs in mostly real time.
"At boot time, the Config Server will pull the latest configuration from an HTTP server. In addition, the Config Server will connect to an AWS IoT Core endpoint to receive real time config updates from an MQTT server."
So, perhaps to bootstrap information they didn't have, like the current configuration? It sounds like they sold different types of signs with different resolutions, and also whatever train station setup config there was. Maybe a one-time exploit to upload that info from the sign itself.
You are correct that with domain control I am able to serve content to any sign but the content will only be loaded once at boot time. Any future updates would have needed to come from their defunct AWS IoT connection (ignoring full restarts).
Using the exploit I remove the connection to AWS IoT and update some of the code to better connect it to the recreated API so users can update their signs in mostly real time.