well, there is always a service listening on some port to a server answer. so it’s usually about identifying the service waiting for a server response and reroute the services listening to this process to ignore it. kinda like shitpiping specialist Robert Deniro in Terry Gilliams “Brazil”
Well, the way it usually works is that there is a port open on the server and the client connects to that port, sends something, and then receives a response. If there’s no longer a server running, connecting to the port will fail, so even if you can open the same port and get the client to connect to it, you’ll get the data the client sends but you won’t know what to send back. If it’s a standardized protocol, then yes, you can do that, but the likelihood of that being the case is very low.
the way i know companies is that they usually steal open source code rightaway or they modify standard stuff slightly to throw sand into peoples eyes rather than waterproofing everything. either way, you should be able to find the services listening to the service listening to the port, server answer or no server answer, if you know the name of the service, you can find the services listening to it or waiting for some response from it (changing a 0 into a 1 in some otherwise empty textfile in the extremely stupid case)
You can figure out what the client is doing, but this wouldn’t be a one-way conversation. Client sends a request, server sends a response. The issue is that even if they’re using a standard general-purpose protocol such as HTTP or WebSocket, they still send data over it. You wouldn’t know what that data is. The only possible way to find out would be either to capture packets going between them, which doesn’t work if there’s no server or it’s encrpyted, or by examining the source code, which is not available. Either way, without both halves of the connection or the source code present, you cannot do anything.
i mean it’s all hypothetical in the end since i ve never had the thing before me, but i m saying: due to the size of the device, hard encryption and continuous server connection is not probable and spoofing and reverse engineering of the device probably doable for a person of advanced IT security or reverse engineering knowledge…
It’s not impossible, but not the easiest thing to do. It would take years to do for full compatibility because you’d be completely blind and have to basically try things until it works.
well, i wasn’t suggesting the person blinded by the vendors neglect should be tasked to solve this… but from the article it seems that is exactly what they intend to happen…
well, there is always a service listening on some port to a server answer. so it’s usually about identifying the service waiting for a server response and reroute the services listening to this process to ignore it. kinda like shitpiping specialist Robert Deniro in Terry Gilliams “Brazil”
Well, the way it usually works is that there is a port open on the server and the client connects to that port, sends something, and then receives a response. If there’s no longer a server running, connecting to the port will fail, so even if you can open the same port and get the client to connect to it, you’ll get the data the client sends but you won’t know what to send back. If it’s a standardized protocol, then yes, you can do that, but the likelihood of that being the case is very low.
the way i know companies is that they usually steal open source code rightaway or they modify standard stuff slightly to throw sand into peoples eyes rather than waterproofing everything. either way, you should be able to find the services listening to the service listening to the port, server answer or no server answer, if you know the name of the service, you can find the services listening to it or waiting for some response from it (changing a 0 into a 1 in some otherwise empty textfile in the extremely stupid case)
You can figure out what the client is doing, but this wouldn’t be a one-way conversation. Client sends a request, server sends a response. The issue is that even if they’re using a standard general-purpose protocol such as HTTP or WebSocket, they still send data over it. You wouldn’t know what that data is. The only possible way to find out would be either to capture packets going between them, which doesn’t work if there’s no server or it’s encrpyted, or by examining the source code, which is not available. Either way, without both halves of the connection or the source code present, you cannot do anything.
i mean it’s all hypothetical in the end since i ve never had the thing before me, but i m saying: due to the size of the device, hard encryption and continuous server connection is not probable and spoofing and reverse engineering of the device probably doable for a person of advanced IT security or reverse engineering knowledge…
It’s not impossible, but not the easiest thing to do. It would take years to do for full compatibility because you’d be completely blind and have to basically try things until it works.
well, i wasn’t suggesting the person blinded by the vendors neglect should be tasked to solve this… but from the article it seems that is exactly what they intend to happen…
I meant blind to the way the protocol works, not literally blind