stream_socket_recvfrom problem

New Member Joined: Jun 09, 2009 Posts: 4

I've been using stream_socket-recvfrom to receive short plain text ascii packets from some internet enabled remote devices. So the letter I for example arrives as a 49 which is the ascii code for same & the socket puts out an I.
However when I set the remotes into AES encrypted mode they not only encrypt but they switch to sending in hex instead of ascii. So after the I has been encrypted it might arrive as a C4.
This is a real problem because the socket listener puts out strange characters (like Ä for C4 or ‰ for 89). If the characters are printable I can use an ascii to hex converter after the socket listener to get the original hex back but many ascii representations of hex values just won't convert back to the original hex.
So to successfully use mycrypt or similar to decode the encrypted packets I need a socket listener that can handle hexadecimal strings.
Seems simple enough but I'm stumped on how to do it. Any ideas from you learned practitioners of the art?

Posted: Sat Jun 13, 2009 4:02 pm

Can't say I've ever had to code to this level. Therefore, I am bumping this thread to see if we can get this noticed again.

Posted: Sat Jun 13, 2009 5:43 pm

much obliged

Posted: Sat Jun 13, 2009 11:58 pm

Are you base64_encodded the data before being sent and then unencoding afterwards?
This is definitely an area I have not played with buy it seems like an encoding/charset problem to me.

Posted: Sun Jun 14, 2009 12:07 am

No the remotes are just sending in hex but the socket insists on putting out an ascii interpretation. So instead of C4, for example, I get Ä

Posted: Sun Jun 14, 2009 12:37 am

Is there any way to check that the remote is sending a single or double byte character bit?
I'm not familiar with the function you are using so I'm taking a stab in the dark here but the behavior seems to be typical of charset problems, specifically that one is dealing with the data as double byte characters and the other isn't.
Depending on the actually data you are using, you may not be able character encode, so using base64_encode in the remote before being sent should force a doublebyte hex encoding of each character which can then be unencoded and give you the same data you started with.

Posted: Sun Jun 14, 2009 12:50 am

In encrypted mode the remotes aren't sending characters as such but raw hexadecimal. The C4 for example arrives as 1100 0100.