I'm working on ONVIF of send "GetDeviceInformation". That's required wsse:UsernameToken.
After searching data for authority, there are two faormula:
(1) by "ONVIF-Core-Specification-v241.pdf", "5.12.2.1 Password derivation"
PE_UA = base64(HMAC_SHA-1(UA+P_UA,NEP+”ONVIF password”))
(2) by soap of WEB protocol
Digest = B64ENCODE( SHA1( B64DECODE( Nonce ) + Date + Password ) )
I am confused!!which one is correct?
Moreover, when i test ONVIF test tool by wireshark
the XML i got as:
<wsse:UsernameToken>
<wsse:Username>admin</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">lu9ywjDwSt8oW7M4tMjCb50/xRg=</wsse:Password>
<wsse:Nonce>TgBYFHxSc3Oo8yPzwnQn8A==</wsse:Nonce>
<wsu:Created>2014-06-20T04:41:45Z</wsu:Created>
</wsse:UsernameToken>
ok, then I've try to figure out the formula by those data.
a> username: "admin"
b> password: "pass" ( un-entropy)
c> Nonce: "TgBYFHxSc3Oo8yPzwnQn8A=="
d> created: "2014-06-20T04:41:45Z"
somehow to get the final password: "lu9ywjDwSt8oW7M4tMjCb50/xRg="
the "nonce" may converted by Base64 so the original should be"4E0058147C527373A8F323F3C27427F0"
I've try use
base64(SHA1("TgBYFHxSc3Oo8yPzwnQn8A==2014-06-12T04:03:45Zpass"))
or
base64(SHA1("4E0058147C527373A8F323F3C27427F0==2014-06-12T04:03:45Zpass"))
but I still can't get the password send by Test tool as "lu9ywjDwSt8oW7M4tMjCb50/xRg="
any one could help me to figure out what the exact formula used by ONVIF test tool?
Do need your help!!! thanks!!
finally, the device send OK to me!
After reference to gSoap
At the first, the formula is:
Digest = B64ENCODE( SHA1( B64DECODE( Nonce ) + Date + Password ) )
for the Nonce, it should be 20 bytes random "numeric" value as:
char caNonceTest[20]={0x9E,0xBD,0xBB,0x53,0x7C,0x96,0xB4,0xC1,0xCE,0xEB,
0xFB,0x06,0x17,0x31,0x41,0x4E,0x5B,0x68,0x86,0x93};
it could be generated by any method (event could be make it)
after getting, caNonceTest, like above, the string should be looked like "艋|蹉鋿1AN[h?昍昍昍昍"
and for XML send to device, the base64 should be like "nr27U3yWtMHO6/gGFzFBTltohpPMzMzMzMzMzBQ="
this is the key point of correct foramte! (not ASCII string!)
Moreover, just feed to sha-1 function as the exactly as the caNonceTest (no need to convert to Base64)
for the created and password, just feed to sha-1 as string format (ex. "2014-07-08T09:26:13Z" and "pass")
then, world peace!
Related
Using actix-web's web::Bytes, I can get the payload from a form submission. It is a simple form with one input named username and another input named text. The raw bytes stream looks like this
b"username=User&text=%22Hello%2C+World%21%22"
The content in the text submitted is simply "Hello, World!".
Without using serde, what methods can I use to convert the above %22Hello%2C+World%21%22 into the intended string "Hello, World!"?
Your data is encoded as application/x-www-form-urlencoded. you can use a crate like form-urlencoded to parse it.
Example:
let x = form_urlencoded::parse("%23first=%25try%25");
println!("{:?}", x); // [("#first", "%try%")]
I'm trying unit testing for the first time with Jest on a personal project, and some of my tests failed even though the data received was the exact same as expected, here's an example:
test("decrypt method works correctly", () =>{
const myAES = new rijndael("", "0bdfa595235c307a105d593fb78fbb13", { key: "SOME 128 BIT KEY", bits: 128, rounds: 9 })
expect(myAES.decrypt()).toStrictEqual({
"c": "0bdfa595235c307a105d593fb78fbb13",
"p": "ATTACK AT DAWN!",
"errors": []
})
}
So then I tried to check if it's a problem with Jest or my code:
const r = myAES.decrypt()
console.log(typeof r.p) // string
console.log(r.p === "ATTACK AT DAWN!") // false
Which just made me even more confused as the strings look the same. The code that I'm testing is an AES encryption function (Don't worry it's just a personal project for fun won't be used in production) that processes text as nodeJS Buffers, and in the end uses the toString() method to convert it back to a string. I'm thinking that may be why I'm having issues, but can't seem to find exactly why. Would love it if someone could point me in the right direction so I can get rid of this error. Thank you in advance.
P.S. I'll save everyone the pain of reading my AES implementation for now as I don't think it's a problem with the encryption but let me know if that's necessary
Ok, so turns out it was a stupid mistake where I overlooked the series of null bytes that tend to end up in the end of the buffer after decryption. While toString() will turn the buffer into the string I want the computer will not recognise it as the same string. So all I had to do was strip the null bytes that follow. Assuming that the null bytes should only appear at the end of the string as they normally do:
const i = buffer.indexOf(0x00)
const result = buffer.slice(0, i).toString() //solves the problem
My PayPal IPNs are validating fine, except for those with a txn_type of recurring_payment. When I pass the message to the validation endpoint, I'm converting the body into a query string using
var verificationString = '?cmd=_notify-validate';
Object.keys(body).map((key) => {
verificationString = verificationString + '&' + key + '=' + body[key];
return key;
});
My best guess is that this is messing with the order of the properties. PayPal's documentation states:
Your listener HTTPS POSTs the complete, unaltered message back to PayPal; the message must contain the same fields (in the same order) as the original message and be encoded in the same way as the original message.
But I didn't think Object.keys(body).map would rearrange anything in Nodejs. Any suggestions?
Found the solution. Turns out that PayPal allows user fields to contain things like backslash, newline characters, etc. This specific IPN had an address field with a \r\n newline between the street and apartment number. Using my original code, this was somehow being encoded different.
Instead of assembling the query string like in my original question, I now assemble it like this, since it preserves all characters and encoding:
var verificationString = '?cmd=_notify-validate&' + request.rawBody.toString();
And that solved the problem!
Well, this is an unusual question and I am not sure where should I put in which site of stackoverflow, so if anybody can tell me I will gladly ask in that site.
Question
So, I am developing an ExpressJS backend and was testing that in postman.
The following code is of my interest.
response.status(200);
result.message = "Please Fill Registration Details";
result.data = {
code: 010101
};
result.status = "Successful";
This is a simple code, no issue here, but when I checked in postman, the output is:
{
"message": "Please Fill Registration Details",
"data": {
"code": 4161
},
"status": "Successful"
}
How did the code 010101 change to 4161 ?
I first thought that postman was considering 010101 to be binary and converting it to decimal, but the decimal value is 21 and hexadecimal number is 15.
So, how is this happening ? Has anyone experienced this before ?
I still need to check this API in production and in actual devices.
I will update my findings.
It consider 010101 as an octal number, that is how JavaScript works. The reason it consider that as an octal number is because it is not surrounded by the quotes.
Here is an example of JavaScript:
console.log(010101); //4161
So, to fix your code, surround your value in quotes:
result.data = {
code: "010101"
};
Javascript understands numbers starting with 0 to be octal (base 8). 10101 in Octal has a decimal value of 4161. If you want to pass the code with a leading zero, pass it as a string "010101".
You selected JSON formatting in postman...
Besides that JS does not follow type rules,
let var1 = 010101;
let var2 = Number(010101);
How can I reliably get the 64bit data from an XML file to a byte[] and then compare that with a string? The following code fails as it seems the whitespace is causing the assert to fail. The goal is for the assert to pass.
Note that it is important that we have it in the form of byte[] at somepoint, but not that the comparison be via strings
<Contents>VGVzdGluZyBURSBzZXNzaW9uIGNvbnRhaW5pbmcgQ29tcGxldGUgUGVyc29uIEEgYW5kIENvbXBs
ZXRlIEVxdWlwbWVudCBCLg0KDQpUZXN0IFRlc3QNCg0KUmVmZXJlbmNlcyBDb21wbGV0ZSBQbGFj
ZSBB
</Contents>
byte[] byteData = document.Contents.text()
assert 'VGVzdGluZyBURSBzZXNzaW9uIGNvbnRhaW5pbmcgQ29tcGxldGUgUGVyc29uIEEgYW5kIENvbXBs'+
'ZXRlIEVxdWlwbWVudCBCLg0KDQpUZXN0IFRlc3QNCg0KUmVmZXJlbmNlcyBDb21wbGV0ZSBQbGFj'+
'ZSBB' == new String(byteData)
Base 64 data is a special encoding of text to ASCII to be URL friendly (historically)
EDIT thanks to comment below, actually base64 was to encode data to send via for email
to extract text from your data, do this:
new String(
'VGVzdGluZyBURSBzZXNzaW9uIGNvbnRhaW5pbmcgQ29tcGxldGUgUGVyc29uIEEgYW5kIENvbXBsZXRlIEVxdWlwbWVudCBCLg0KDQpUZXN0IFRlc3QNCg0KUmVmZXJlbmNlcyBDb21wbGV0ZSBQbGFjZSBB')
.decodeBase64()
)
result starts with 'ession containing Complete Person A and Complete Equipment B.'
from http://mrhaki.blogspot.fr/2009/11/groovy-goodness-base64-encoding.html