-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
tsearch line 142:
for(radare_read(0);!config.interrupted;i = radare_read(1)) {
if (!i) break;
binparse_reset_tlist ( t ) ;
for(i=0;i<config.block_size;i++)
update_tlist(t, config.block[i], config.seek+i);
config.seek += config.block_size;
}
config.seek = tmp;
and binparse.h :
void binparse_reset_tlist (tokenizer *t );
binparse.c :
void binparse_reset_tlist (tokenizer *t )
{
int i,j;
for (i=0; i < t->nlists ; i ++ )
{
t->tls[i]->estat = 0;
}
}
in callback I've added the size of the search:
static void radare_tsearch_callback(struct _tokenizer *t, int i,
unsigned long long where, unsigned long long size)
{
char flag_name[128];
char *cmd = getenv("HITCMD");
off_t off = config.seek;
off_t bsize = config.block_size;
if (cmd && cmd[0]!='\0')
radare_command(cmd, 0);
sprintf(flag_name, "hit%d[%d]", i, nhit++);
config.seek = where;
config.block_size = size;
flag_set(flag_name);
config.seek = off;
config.block_size = bsize;
/*D { printf("\e[K"OFF_FMTs" '%s' ", (off_t)where, flag_name);
data_print((off_t)where, config.block+(where-config.seek),
60, FMT_ASC, MD_BLOCK);
} else */
printf("0x"OFF_FMTx" \n", where); // TODO : print data_dump?
fflush(stdout);
}
And there is an issue I can not solve:
example::
[0x00000000000000]> / ECEC
0x40
0x23440
0x23794
the offsets are correct, but when I do flag:
[0x00000000000000]> f
000 0x0000000000000000 4 hit0[0] x fe 03 00 ea
001 0x0000000000023400 4 hit0[1] x 08 00 00 0a
002 0x0000000000023600 4 hit0[2] x 24 10 9f e5
size are correct but the offsets are blocksize rounded... even though in
callback offset.seek is correctly set...
Thanks!!
pancake wrote:
> I had similar problems when implementng the callback signature into
> the tokenizer structure. This is because of the different sizes of
> given arguments. I forced (unsigned long long) instead of using off_t
> to avoid problems, and this fix work on my boxes. I'll try with other
> architectures too. (on linux and freebsd on x86 works for me).
>
> I'll try on ARM and cygwin.
>
> Let me know if you find root of the problem.
>
> --pancake
>
>
> git-clone ...
> ./configure
> make
>
> gdb
> open ro /tmp/SPL.nb
> [0x00000000000000]> / ECEC
> 0xBFC77F1000000040 '(null)'
> Program received signal SIGSEGV, Segmentation fault.
> 0xb7e7b7bc in memcpy () from /lib/libc.so.6
> (gdb)
>
>
> , but real programers don't use debuggers! hehe, just kidding and search
> seems to be broken. I'll have a look at it later and will try the night
> tarball.
>
>
> thanks!
>
> pancake wrote:
>
>>Have you tried with the latest nighly tarball? Maybe you missed to
>>git-checkout and run
>>configure again. show me the registers, back trace and such info from
>>gdb if the problem
>>persists.
>
>>Thanks
>
>>--pancake
>
>>On Sat, 07 Apr 2007 13:05:19 +0200
>>esteve espuna <[EMAIL PROTECTED]> wrote:
>
>
>
>>hi for me it segfaults in the callback :
>
>>here:
>> { printf("\e[K"OFF_FMTs" '%s' ", (off_t)where, flag_name);
>> data_print((off_t)where, config.block+(where-config.seek),
>>60, FMT_ASC, MD_BLOCK);
>> }
>
>>tsearch.c line 58. When a hit is found.
>
>
>>Thanks!
>
>>esteve espuna wrote:
>
>
>>>Hi,
>
>>>great!! will have a look at it as soon as possible. By the benchmarking
>>>difference keep in mind that the cost for N searches shouldn't be much
>>>bigger that the cost for one search. The burden for many searches at
>>>once has a payoff in performance.
>
>>>Anyway if I have some time I'll look at it!
>
>
>>>Great work!
>
>
>>>pancake wrote:
>
>
>>>>>I have finally integrated the new search engine into radare.
>>>>>
>>>>>Thanks to esteve for the great search algorithm!
>>>>>
>>>>>This new algorithm is called "binparser" and it's in his first stage
>>>>>of
>>>>>design. The new engine fixes all the tickets in the bug report page
>>>>>and gives more possibilities with a new regexp-like syntax for binary
>>>>>searchs.
>>>>>
>>>>>[0x00000000000000]> /?
>>>>>/x A0 B0 43 ; hex byte pair binary search.
>>>>>/m FF 0F ; Binary mask for search
>>>>>/ \x7FELF ; plain string search (supports \x).
>>>>>/. [file] ; search using the token file rules
>>>>>/r 0,2-10 ; launch range searches 0-10
>>>>>/l ; list all search tokens (%SEARCH[%d])
>>>>>// ; repeat last search
>>>>>
>>>>>Note that the buggy GNU regexps have been removed in pro to avoid
>>>>>buggy
>>>>>results and buggy portability. The /m command to define a MASK for
>>>>>binary
>>>>>strings is not yet implemented , but the rest is fine.
>>>>>
>>>>>You can throw N token searchs at once, so paralel searchs will be
>>>>>faster
>>>>>than serialized ones with the old engine. Search strings are stored in
>>>>>environment variables named %SEARCH[#] where '#' is a number from 0 to
>>>>>N.
>>>>>
>>>>>This is very useful because you can define multiple search strings and
>>>>>throw them by range:
>>>>>
>>>>>/r 0-3,5
>>>>>
>>>>>This command will throw a search for the tokens 0, 1, 2, 3 and 5
>>>>>Use the % command to define the search strings:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>%SEARCH[3] ELF\x01
>>>>>
>>>>>
>>>>>The regexp support is done with [a-z] [0x00-0xFF] , etc... so,
>>>>>remember
>>>>>to scape the '[' and other critical characters. (read the source, no
>>>>>doc yet)
>>>>>
>>>>>I've done some benchmarking on it and these are the results:
>>>>>
>>>>>Time resuls searching a 3 char string inside a file of 60M:
>>>>>
>>>>>old engine:
>>>>>real 0m3.352s
>>>>>user 0m2.973s
>>>>>sys 0m0.377s
>>>>>
>>>>>new engine:
>>>>>real 0m4.956s
>>>>>user 0m4.610s
>>>>>sys 0m0.347s
>>>>>
>>>>>-------------
>>>>>
>>>>>The new engine is a bit slower, but it's ok for me, actually the code
>>>>>is
>>>>>not clean at all, and both search engines are there. So I could
>>>>>probably
>>>>>think on maintain both search engines or just the best one :)
>>>>>
>>>>>The next goal is to implement the 'binary mask'.
>>>>>
>>>>>Hope to documentate all this stuff in the wiki ASAP.
>>>>>
>>>>>
>>>>>--pancake
>>>>>_______________________________________________
>>>>>radare mailing list
>>>>>[email protected]
>>>>>https://lists.nopcode.org/mailman/listinfo/radare
>>>>>
>
>
>>_______________________________________________
>>radare mailing list
>>[email protected]
>>https://lists.nopcode.org/mailman/listinfo/radare
>
>
> _______________________________________________
> radare mailing list
> [email protected]
> https://lists.nopcode.org/mailman/listinfo/radare
>
>
>> --pancake
>>_______________________________________________
>>radare mailing list
>>[email protected]
>>https://lists.nopcode.org/mailman/listinfo/radare
>
>
_______________________________________________
radare mailing list
[email protected]
https://lists.nopcode.org/mailman/listinfo/radare
> _______________________________________________
> radare mailing list
> [email protected]
> https://lists.nopcode.org/mailman/listinfo/radare
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFGF5zWHCkwMET/DRYRAnTWAJ0ZwYJIlalPZNr8nihNFSUKHcGYBACgmfzz
oKXa1YYKgfeoGeWx6c8uXzE=
=X/Sz
-----END PGP SIGNATURE-----
_______________________________________________
radare mailing list
[email protected]
https://lists.nopcode.org/mailman/listinfo/radare
