Re: [Wireshark-dev] epan_base64_decode(): failure when string contains a NUL character
Am 21.04.13 22:29, schrieb Evan Huus: There is only one issue left: How can I split up this string. The g_strsplit() function seems to don't accept NULL as a delimiter. It depends what you need the results for. If you just need them separated by a NULL then they're already in that state, you can just use strlen and pointer arithmetic. Yeah, your right. This way it was easy to split up the data. Thanks a lot for this tip. I added the patch to bug 8600. If you need discrete copies of each substring in their own memory space you can just do the above and then strdup them. A word of warning though: be sure to sanity check everything, as you can't assume that the string coming out of the packet will be sane, or will contain the correct number of NULLs (it may not contain any NULLs at all, in which case just calling strlen will run past the end of the buffer). Also be sure to use managed memory (see doc/README.wmem) unless you have a specific reason not to. Thanks for the warning. I hope I added the right checks to my code. Cheers Uli ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] epan_base64_decode(): failure when string contains a NUL character
Hi, Thanks for both replies! I did a complete clean-up of my code and now the decoded string is 14 bytes long. So the epan_base64_decode() function is working correct. Sorry for the work and the confusion. There is only one issue left: How can I split up this string. The g_strsplit() function seems to don't accept NULL as a delimiter. Thanks! Uli Am 20.04.13 11:55, schrieb Jakub Zawadzki: Hi, On Wed, Apr 17, 2013 at 10:27:42PM +0200, Uli Heilmeier wrote: With the PLAIN mechanism the packet has a base64 encoded string containing: [authorization user](\x00)[authentication user](\x00)[password] For example: dGVzdAB0ZXN0ADEyMzQ= contains test(NUL)test(NUL)1234 I tried to decode the base64 string with the epan_base64_decode() function (from epan/base64.h). Unfortunately this fails. I only get a wrong three bytes long string. I guess the problem is the NUL character as a delimiter. Do you have an idea if this is bug in the epan_base64_decode() function or do I have to do the decoding another way? From C interactive shell (gdb): (gdb) call $x = (char *) strdup(dGVzdAB0ZXN0ADEyMzQ=) $1 = 0x65b0e0 dGVzdAB0ZXN0ADEyMzQ= (gdb) call epan_base64_decode($x) $2 = 14 (gdb) x/14c $x 0x65b0e0: 116 't' 101 'e' 115 's' 116 't' 0 '\000'116 't' 101 'e' 115 's' 0x65b0e8: 116 't' 0 '\000'49 '1' 50 '2' 51 '3' 52 '4' (gdb) call $x $3 = 0x65b0e0 test (gdb) call $x + 5 $4 = 0x65b0e5 test (gdb) call $x + 5 + 5 $5 = 0x65b0ea 1234 Seems to be working ok, can you attach your code? Regards, Jakub Zawadzki ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] epan_base64_decode(): failure when string contains a NUL character
On Sun, Apr 21, 2013 at 4:22 PM, Uli Heilmeier ze...@heilmeier.eu wrote: Hi, Thanks for both replies! I did a complete clean-up of my code and now the decoded string is 14 bytes long. So the epan_base64_decode() function is working correct. Sorry for the work and the confusion. There is only one issue left: How can I split up this string. The g_strsplit() function seems to don't accept NULL as a delimiter. It depends what you need the results for. If you just need them separated by a NULL then they're already in that state, you can just use strlen and pointer arithmetic. If you need discrete copies of each substring in their own memory space you can just do the above and then strdup them. A word of warning though: be sure to sanity check everything, as you can't assume that the string coming out of the packet will be sane, or will contain the correct number of NULLs (it may not contain any NULLs at all, in which case just calling strlen will run past the end of the buffer). Also be sure to use managed memory (see doc/README.wmem) unless you have a specific reason not to. Cheers, Evan Thanks! Uli Am 20.04.13 11:55, schrieb Jakub Zawadzki: Hi, On Wed, Apr 17, 2013 at 10:27:42PM +0200, Uli Heilmeier wrote: With the PLAIN mechanism the packet has a base64 encoded string containing: [authorization user](\x00)[authentication user](\x00)[password] For example: dGVzdAB0ZXN0ADEyMzQ= contains test(NUL)test(NUL)1234 I tried to decode the base64 string with the epan_base64_decode() function (from epan/base64.h). Unfortunately this fails. I only get a wrong three bytes long string. I guess the problem is the NUL character as a delimiter. Do you have an idea if this is bug in the epan_base64_decode() function or do I have to do the decoding another way? From C interactive shell (gdb): (gdb) call $x = (char *) strdup(dGVzdAB0ZXN0ADEyMzQ=) $1 = 0x65b0e0 dGVzdAB0ZXN0ADEyMzQ= (gdb) call epan_base64_decode($x) $2 = 14 (gdb) x/14c $x 0x65b0e0: 116 't' 101 'e' 115 's' 116 't' 0 '\000'116 't' 101 'e' 115 's' 0x65b0e8: 116 't' 0 '\000'49 '1' 50 '2' 51 '3' 52 '4' (gdb) call $x $3 = 0x65b0e0 test (gdb) call $x + 5 $4 = 0x65b0e5 test (gdb) call $x + 5 + 5 $5 = 0x65b0ea 1234 Seems to be working ok, can you attach your code? Regards, Jakub Zawadzki ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] epan_base64_decode(): failure when string contains a NUL character
Hi, On Wed, Apr 17, 2013 at 10:27:42PM +0200, Uli Heilmeier wrote: With the PLAIN mechanism the packet has a base64 encoded string containing: [authorization user](\x00)[authentication user](\x00)[password] For example: dGVzdAB0ZXN0ADEyMzQ= contains test(NUL)test(NUL)1234 I tried to decode the base64 string with the epan_base64_decode() function (from epan/base64.h). Unfortunately this fails. I only get a wrong three bytes long string. I guess the problem is the NUL character as a delimiter. Do you have an idea if this is bug in the epan_base64_decode() function or do I have to do the decoding another way? From C interactive shell (gdb): (gdb) call $x = (char *) strdup(dGVzdAB0ZXN0ADEyMzQ=) $1 = 0x65b0e0 dGVzdAB0ZXN0ADEyMzQ= (gdb) call epan_base64_decode($x) $2 = 14 (gdb) x/14c $x 0x65b0e0: 116 't' 101 'e' 115 's' 116 't' 0 '\000'116 't' 101 'e' 115 's' 0x65b0e8: 116 't' 0 '\000'49 '1' 50 '2' 51 '3' 52 '4' (gdb) call $x $3 = 0x65b0e0 test (gdb) call $x + 5 $4 = 0x65b0e5 test (gdb) call $x + 5 + 5 $5 = 0x65b0ea 1234 Seems to be working ok, can you attach your code? Regards, Jakub Zawadzki ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] epan_base64_decode(): failure when string contains a NUL character
Hello list, I'm currently trying to improve the SMTP dissector regarding the AUTH command. Up to now I finished the 'AUTH LOGIN' mechanism (s. Bug 8591). Next I would like to decode the 'AUTH PLAIN' mechanism (RFC 4616). With the PLAIN mechanism the packet has a base64 encoded string containing: [authorization user](\x00)[authentication user](\x00)[password] For example: dGVzdAB0ZXN0ADEyMzQ= contains test(NUL)test(NUL)1234 I tried to decode the base64 string with the epan_base64_decode() function (from epan/base64.h). Unfortunately this fails. I only get a wrong three bytes long string. I guess the problem is the NUL character as a delimiter. Do you have an idea if this is bug in the epan_base64_decode() function or do I have to do the decoding another way? Thanks a lot! Sincerely Uli ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] epan_base64_decode(): failure when string contains a NUL character
Glib has g_base64_decode_inplace as of 2.20 so you could try using that. We support way back to 2.14 at the moment so we keep epan_base64_decode() available, but if the glib function works it's probably a bug in our code. Evan On Wed, Apr 17, 2013 at 4:27 PM, Uli Heilmeier ze...@heilmeier.eu wrote: Hello list, I'm currently trying to improve the SMTP dissector regarding the AUTH command. Up to now I finished the 'AUTH LOGIN' mechanism (s. Bug 8591). Next I would like to decode the 'AUTH PLAIN' mechanism (RFC 4616). With the PLAIN mechanism the packet has a base64 encoded string containing: [authorization user](\x00)[authentication user](\x00)[password] For example: dGVzdAB0ZXN0ADEyMzQ= contains test(NUL)test(NUL)1234 I tried to decode the base64 string with the epan_base64_decode() function (from epan/base64.h). Unfortunately this fails. I only get a wrong three bytes long string. I guess the problem is the NUL character as a delimiter. Do you have an idea if this is bug in the epan_base64_decode() function or do I have to do the decoding another way? Thanks a lot! Sincerely Uli ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
