Jump to content
Sign in to follow this  
ArxBzFhblxphS

..

Recommended Posts

ArxBzFhblxphS
Posted Image Edited by Thanubis

Share this post


Link to post
Share on other sites
martin

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.

Share this post


Link to post
Share on other sites
Malkey

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 by Malkey

Share this post


Link to post
Share on other sites
martin

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.

Share this post


Link to post
Share on other sites
Malkey

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
;

Share this post


Link to post
Share on other sites
trancexx

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 ( :D ).

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

Share this post


Link to post
Share on other sites
Authenticity

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.

Share this post


Link to post
Share on other sites
Malkey

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 ( :mellow: ).

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.

Share this post


Link to post
Share on other sites
trancexx

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

Share this post


Link to post
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.