Im trying to send a long encrypted string with curl to an api and it gives me this
curl http://host.net/crypto.php?api=XXXXXXXX\&name=XXXX\&msg=$key
bash: /usr/bin/curl: Argument list too long```
If i try to send a file
curl http://host.net/crypto.php?api=XXXXXXX\&name=XXXX\&msg="#/tmp/.sendenc"
The server just gets #/tmp/.sendenc
The first way works fine with shorter strings but not with longer...
idk if this helps but its sending an encrypted image about 417025 letters :/
Related
Hi am using php smpp sms sending package to work on socket sms sending.
$transport = new SocketTransport(array(config('app.smppHost')), config('app.smppPort'));
$transport->setRecvTimeout(10000);
$smpp = new SmppClient($transport);
I am sending with $encodedMessage = GsmEncoder::utf8_to_gsm0338($message);
$smpp->sendSMS($from,$to,$encodedMessage,null,null);
UPDATE
But the sms is receiving with broken character.I am sending in myn language and also tried as suggested
$smpp->sendSMS($from,$to,$encodedMessage,null,null);
But now half broken half proper message is sending. I think some encoded needed ???
This is special language encoded issue you need both override the encoded version in smpp package as well as encode the text itself.
First convert the string
mb_convert_encoding($message,'UCS-2',"utf8");
Then send sms in encoded in type 8. it should work properly
$smpp->sendSMS($from,$to,$encodedMessage,null,8);
I have an ESP8266 with Nodemcu and an AM2320 sensor.
I am sending temperature and humidity in JSON format in plain text to my HTTP server for collecting datas with PHP and SQLITE3.
That's working right.
But I wish to encrypt my datas with AES-CBC
I encrypt measures on the ESP8266 with crypto.encrypt() function and 'AES-CBC' method like this example:
https://nodemcu-firmware.readthedocs.io/en/latest/en/modules/crypto/#cryptoencrypt
I do the same encryption on my PC with Python 3 .
The resulting string matches with the result on the ESP8266 and LUA 5.1
Next I do the same encryption on my PC but with PHP 7.1
Alas, the resulting string don't match with the previous results.
I am using the 'AES-128-CBC' method on openssl_encrypt() function.
I put the script in the three languages in a gist on Github.com :
https://gist.github.com/bazooka07/bed368d313e218fcba332cb2127c70b1
That's wrong in PHP ?
Can You help me ?
I've tried your code with aes-256-cbc instead of aes-128-cbc in PHP, and it gives the same output. Changing the PHP encrypt method to aes-256-cbc should fix the problem..
I add some fix to my gist for working when the length of the message to encrypt don't mach with a multiple of 16 chars.
I was trying to apply AT commands on my Huawei modem using gammu. I can use following commands to access USSD from ZTE Modem:
gammu getussd *111#
but in huawei modem, it doesn't work. As per my study, I need to provide PDU instead of text. Then I used this link to encode my code *111# and try following on command line.
gammu getussd AA582C3602
and it works!. Now I need to convert *111# to AA582C3602 using php.
This link describe how to decode PDU Encoded message. but I didn't find any reverse way to convert back the normal text into PDU encoded message.
Badly need your help.
Some Huawei modems don't support USSD... E220 doesn't... I'm using E1550 in Portugal for NOS (old Optimus) operator with no issues, but yes it's PDU encoded.
Tell the modem you will be sending PDU encoded whith AT+CMGF=0.
I use this commands prior to send the USSD
AT+CMGF=0
AT+CSCS="IRA"
I seem to be stuck at sending the compressed messages from PHP to NodeJS over Amazon SQS.
Over on the PHP side I have:
$SQS->sendMessage(Array(
'QueueUrl' => $queueUrl,
'MessageBody' => 'article',
'MessageAttributes' => Array(
'json' => Array(
'BinaryValue' => bzcompress(json_encode(Array('type'=>'article','data'=>$vijest))),
'DataType' => 'Binary'
)
)
));
NOTE 1: I also tried putting compressed data directly in the message, but the library gave me an error with some invalid byte data
On the Node side, I have:
body = decodeBzip(message.MessageAttributes.json.BinaryValue);
Where message is from sqs.receiveMessage() call and that part works since it worked for raw (uncompressed messages)
What I am getting is TypeError: improper format
I also tried using:
PHP - NODE
gzcompress() - zlib.inflateraw()
gzdeflate() - zlib.inflate()
gzencode() - zlib.gunzip()
And each of those pairs gave me their version of the same error (essentially, input data is wrong)
Given all that I started to suspect that an error is somewhere in message transmission
What am I doing wrong?
EDIT 1: It seems that the error is somewhere in transmission, since bin2hex() in php and .toString('hex') in Node return totally different values. It seems that Amazon SQS API in PHP transfers BinaryAttribute using base64 but Node fails to decode it. I managed to partially decode it by turning off automatic conversion in amazon aws config file and then manually decoding base64 in node but it still was not able to decode it.
EDIT 2: I managed to accomplish the same thing by using base64_encode() on the php side, and sending the base64 as a messageBody (not using MessageAttributes). On the node side I used new Buffer(messageBody,'base64') and then decodeBzip on that. It all works but I would still like to know why MessageAttribute is not working as it should. Current base64 adds overhead and I like to use the services as they are intended, not by work arounds.
This is what all the SQS libraries do under the hood. You can get the php source code of the SQS library and see for yourself. Binary data will always be base64 encoded (when using MessageAttributes or not, does not matter) as a way to satisfy the API requirement of having form-url-encoded messages.
I do not know how long the data in your $vijest is, but I am willing to bet that after zipping and then base64 encoding it will be bigger than before.
So my answer to you would be two parts (plus a third if you are really stubborn):
When looking at the underlying raw API it is absolutely clear that not using MessageAttributes does NOT add additional overhead from base64. Instead, using MessageAttributes adds some slight additional overhead because of the structure of the data enforced by the SQS php library. So not using MessageAttributes is clearly NOT a workaround and you should do it if you want to zip the data yourself and you got it to work that way.
Because of the nature of a http POST request it is a very bad idea to compress your data inside your application. Base64 overhead will likely nullify the compression advantage and you are probably better off sending plain text.
If you absolutely do not believe me or the API spec or the HTTP spec and want to proceed, then I would advise to send a simple short string 'teststring' in the BinaryValue parameter and compare what you sent with what you got. That will make it very easy to understand the transformations the SQS library is doing on the BinaryValue parameter.
gzcompress() would be decoded by zlib.Inflate(). gzdeflate() would be decoded by zlib.InflateRaw(). gzencode() would be decoded by zlib.Gunzip(). So out of the three you listed, two are wrong, but one should work.
I have been trying to implement some encryption between an iPhone app and a PHP web service. It's not working however. It seems like the first half of the text is NOT decrypted while the second half is decrypted just fine. What should I do?
The PHP encryption method is as follows:
function decrypt($str, $iv) {
$iv .= "00000000";
$str = base64_decode($str);
return self::decrypt_data($str, $iv, self::secret_key);
}
The iPhone stuff that encrypts the text uses a CryptoHelper class like this:
NSString *encrypted = [[CryptoHelper sharedInstance] encryptString:dataString];
The CryptoHelper class can be seen at http://pastie.org/1267796.
Try a simple example where you send a known Base64 encoded string from the iPhone app to PHP.
Compare the known valid string to what PHP is getting. I know recently, when trying to do an Ajax post from a script to PHP, we were having trouble with some characters (specifically +) being converted to spaces by PHP because it was doing a URL decode automatically. We had to switch all + to their % (URL-encoded %2B) equivalent. This fixed the problem for us.