ArxBzFhblxphS Posted June 18, 2009 Share Posted June 18, 2009 (edited) Edited August 9, 2009 by Thanubis Link to comment Share on other sites More sharing options...
martin Posted June 18, 2009 Share Posted June 18, 2009 I have a string of Binary data, and I want to find this string "2E646C6C00", inside it. After finding that string, I want to return every character from the search string back to the previous Null (00) character. I don't quite know how to do this. I tried searching between the Null and my search string but it returns too much. This is the code I have. #Include <Array.au3> Opt("MustDeclareVars", 1) Local $sBinary = _ "0x0044656C6574655365727669636500414456415049" & _ "33322E646C6C00004600496E6974436F6D6D6F6E436F" & _ "6E74726F6C7345780000434F4D43544C33322E646C6C0000" Local $aResults = StringRegExp($sBinary, "(?s)(?i)00(.*?)2E646C6C00", 3) _ArrayDisplay($aResults) This is what it returns. I only want the bold part.I think it is a bit more complicated, but perhaps I am not able to see a simple method. This approach would work, but it needs extra logic. #Include <Array.au3> Opt("MustDeclareVars", 1) LOcal $string Local $sBinary = _ "0x0044656C6574655365727669636500414456415049" & _ "33322E646C6C00004600496E6974436F6D6D6F6E436F" & _ "6E74726F6C7345780000434F4D43544C33322E646C6C0000" Local $aResults; $string = stringleft($sBinary,stringinstr($sBinary,"2E646C6C00")) $aResults = stringright($string,stringinstr($string,"00",0,-1)) ConsoleWrite($aResults & @CRLF) It's not correct except by luck because it will find "2E646C6C00" in the string "0x12E646C6C005" but it isn't what you want. In the same way searching for "00" doesn't check that the result is positioned at an odd number of places along the string. So you need to include a check on the position found for each substring, and if it isn't at an odd position look for the next occurrance either forward or backward. Serial port communications UDF Includes functions for binary transmission and reception.printing UDF Useful for graphs, forms, labels, reports etc.Add User Call Tips to SciTE for functions in UDFs not included with AutoIt and for your own scripts.Functions with parameters in OnEvent mode and for Hot Keys One function replaces GuiSetOnEvent, GuiCtrlSetOnEvent and HotKeySet.UDF IsConnected2 for notification of status of connected state of many urls or IPs, without slowing the script. Link to comment Share on other sites More sharing options...
Malkey Posted June 18, 2009 Share Posted June 18, 2009 (edited) Try this. ; #include <Array.au3> Opt("MustDeclareVars", 1) Local $sBinary = _ "0x0044656C6574655365727669636500414456415049" & _ "33322E646C6C00004600496E6974436F6D6D6F6E436F" & _ "6E74726F6C7345780000434F4D43544C33322E646C6C0000" Local $aResults = StringRegExp(StringTrimLeft($sBinary, 2), "00*(.{0,20})2E646C6C00", 3) _ArrayDisplay($aResults) ; Edit replaced "00(.{0,16})2E646C6C00", with "00*(.{0,20})2E646C6C00" It's a bit more flexible. Edited June 18, 2009 by Malkey Link to comment Share on other sites More sharing options...
martin Posted June 18, 2009 Share Posted June 18, 2009 Try this. ; #include <Array.au3> Opt("MustDeclareVars", 1) Local $sBinary = _ "0x0044656C6574655365727669636500414456415049" & _ "33322E646C6C00004600496E6974436F6D6D6F6E436F" & _ "6E74726F6C7345780000434F4D43544C33322E646C6C0000" Local $aResults = StringRegExp(StringTrimLeft($sBinary, 2), "00*(.{0,20})2E646C6C00", 3) _ArrayDisplay($aResults) ; Edit replaced "00(.{0,16})2E646C6C00", with "00*(.{0,20})2E646C6C00" It's a bit more flexible.If you delete the first character after 0x and add an extra character to the end you get the same result even thoiugh the search string is no longer included. I think you need to have a way to check that "00" is a null character and not from something like "800B" which is 2 characters, and the same with the search string. Serial port communications UDF Includes functions for binary transmission and reception.printing UDF Useful for graphs, forms, labels, reports etc.Add User Call Tips to SciTE for functions in UDFs not included with AutoIt and for your own scripts.Functions with parameters in OnEvent mode and for Hot Keys One function replaces GuiSetOnEvent, GuiCtrlSetOnEvent and HotKeySet.UDF IsConnected2 for notification of status of connected state of many urls or IPs, without slowing the script. Link to comment Share on other sites More sharing options...
Malkey Posted June 18, 2009 Share Posted June 18, 2009 If you delete the first character after 0x and add an extra character to the end you get the same result even thoiugh the search string is no longer included. I think you need to have a way to check that "00" is a null character and not from something like "800B" which is 2 characters, and the same with the search string.Here is another try. ; #include <Array.au3> Opt("MustDeclareVars", 1) ; Correct Results ;4144564150493332 ;434F4D43544C3332 Local $sBinary = _ "0x0044656C6574655365727669636500414456415049" & _ "33322E646C6C00004600496E6974436F6D6D6F6E436F" & _ "6E74726F6C7345780000434F4D43544C33322E646C6C0000" Local $aResults = StringRegExp(StringRegExpReplace(StringTrimLeft($sBinary, 2), "(.{2})", "\1 "), "00 (.{0,30}) 2E 64 6C 6C 00 ", 3) If IsArray($aResults) Then For $x = 0 To UBound($aResults) - 1 $aResults[$x] = StringStripWS(StringRegExpReplace($aResults[$x], "(00 )*(.*)", "\2"), 8); Remove WS & leading (00 )'s Next _ArrayDisplay($aResults) EndIf ; Link to comment Share on other sites More sharing options...
trancexx Posted June 18, 2009 Share Posted June 18, 2009 It is completely wrong to use RegExp functions on binary data. This is due to default behaviour of that functions. Every data is stringed before anything (not hexed). Since strings are null-terminated you will lose everything after 0x00.What you are doing is processing strings (of course).On the other hand AutoIt's String functions can process binary date in a losseless kind of way ( ).Thing that martin mentions is caused by, again, AutoIt's behaviour with determining the beginning of string. Is string starting at offset 0 or with the first caracter. Obviously both, but it's considered to be at 1, not 0.In any case... when finding something in binary data, proper thing would be to convert it to string using BinaryToString() - there is no truncation involved. Do the same thing with pattern. Use StringInStr to find offset(s). Use StringReplace() to replace what you want - specify offset in this function, not pattern. Convert back to binary using Binary() for example, and that's it. ♡♡♡ . eMyvnE Link to comment Share on other sites More sharing options...
Authenticity Posted June 18, 2009 Share Posted June 18, 2009 Maybe you'd like to read this. It's not good practice or efficient way to search executable or dll files for dll files names using string approach. Link to comment Share on other sites More sharing options...
Malkey Posted June 19, 2009 Share Posted June 19, 2009 It is completely wrong to use RegExp functions on binary data. This is due to default behaviour of that functions. Every data is stringed before anything (not hexed). Since strings are null-terminated you will lose everything after 0x00. What you are doing is processing strings (of course). On the other hand AutoIt's String functions can process binary date in a losseless kind of way ( ). Thing that martin mentions is caused by, again, AutoIt's behaviour with determining the beginning of string. Is string starting at offset 0 or with the first caracter. Obviously both, but it's considered to be at 1, not 0. In any case... when finding something in binary data, proper thing would be to convert it to string using BinaryToString() - there is no truncation involved. Do the same thing with pattern. Use StringInStr to find offset(s). Use StringReplace() to replace what you want - specify offset in this function, not pattern. Convert back to binary using Binary() for example, and that's it.Thanks for your soap box lecture on binary data. You gave me insight into the mentality of some programmers who apply the limitations of a programming language onto AutoIt scripts. The glimmer of hope for you can be seen in "What you are doing is processing strings (of course)." I totally agree. We may call it binary data, but it's just a string. You are implying not do string functions (which works), and use the proper way - "..proper thing would be to convert it to string using BinaryToString() - there is no truncation involved." - (does not work) The idiotic thing about that statement is when you use BinaryToString() on the string (binary data) that the OP supplied, Post #1, the first null-terminating byte truncates the resultant string at the first character. This is an perfect example of why it is easier to use string functions. Whether a string is called a binary, hex, numeric, text, or ASCII string, they are just a string which is enclosed within quotes, and is a suitable parameter for string functions. Soap box back at you. Thanubis That's impressive,Post #7. Who would have thought you would find all those dll references in Notepad.exe. Further on with the Post #1 null string problem. A slightly different approach. I am certain it can be improved.; #include <Array.au3> Opt("MustDeclareVars", 1) Local $sBinary = _ "0x0044656C6574655365727669636500414456415049" & _ "33322E646C6C00004600496E6974436F6D6D6F6E436F" & _ "6E74726F6C7345780000434F4D43544C33322E646C6C0000" local $sChrString = StringRegExpReplace(StringTrimLeft($sBinary, 2), "(.{2})", "Chr(0x\1) & ") $sChrString = StringReplace($sChrString, "Chr(0x00) & Chr(0x00) & ","Chr(0x00) & "); Remove double nulls local $sNullToCRString = StringReplace(StringTrimRight($sChrString, 3), "Chr(0x00)", "Chr(0x0D)") local $sString = Execute($sNullToCRString) ConsoleWrite($sString & @CRLF) ; Remove leading and tailing @CR if they exist. If StringLeft($sString, 1) = @CR Then $sString = StringTrimLeft($sString, 1) If StringRight($sString, 1) = @CR Then $sString = StringTrimRight($sString, 1) local $aString = StringSplit($sString, @CR) _ArrayDisplay($aString) ; Maybe you'd like to read this. It's not good practice or efficient way to search executable or dll files for dll files names using string approach.If the string approach did not work, I would total agree. But it does work, and it works efficiently well using AutoIt string functions. Link to comment Share on other sites More sharing options...
trancexx Posted June 19, 2009 Share Posted June 19, 2009 Thanks for your soap box lecture on binary data. You gave me insight into the mentality of some programmers who apply the limitations of a programming language onto AutoIt scripts. The glimmer of hope for you can be seen in "What you are doing is processing strings (of course)." I totally agree. We may call it binary data, but it's just a string.You are implying not do string functions (which works), and use the proper way - "..proper thing would be to convert it to string using BinaryToString() - there is no truncation involved." - (does not work)The idiotic thing about that statement is when you use BinaryToString() on the string (binary data) that the OP supplied, Post #1, the first null-terminating byte truncates the resultant string at the first character. This is an perfect example of why it is easier to use string functions.Whether a string is called a binary, hex, numeric, text, or ASCII string, they are just a string which is enclosed within quotes, and is a suitable parameter for string functions. Soap box back at you. ...You read my post, but you didn't actually read it. ♡♡♡ . eMyvnE Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now