-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I think I found a quite important issue:
if I print the size of the config structure in flags.c :
int flag_set(const char *name)
{
register int i;
const char *ptr;
rad_flag_t *flag = NULL;
printf ("config %d\n", sizeof(config));
it gives me :
config 108
while in tsearch.c :
config 92
I've been looking at it and don't really know why... it must be an
include problem...
esteve espuna wrote:
> 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
>
>
>
_______________________________________________
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
iD8DBQFGF6FoHCkwMET/DRYRAuW9AJ4pa3P4ZguHFsYO1T9VndbYD14+UwCdGl0s
SJUPEYB5gXZtOwv8vXfOMzM=
=KijQ
-----END PGP SIGNATURE-----
_______________________________________________
radare mailing list
[email protected]
https://lists.nopcode.org/mailman/listinfo/radare
