Hi, thanks for your feedback.
> I'm not a big fan of this because you have no guarantee that your "bits2 > COUNT2" are valid. > > So your bits1 COUNT1 could be perfectly good, and you find a match and > you discard it because your bits2 COUNT2 are invalid. To clarify: there is no need to specify them. If you omit them, Kraken will return the old matches and you can call find_kc on your own as usual. If bits2 are guessed wrong, well, yes there will be a false negative due to that. But i had no such problems yet. Indeed I am guessing the whole L2 frame that is received and that means there are usually either four bursts which match or none that matches. The success rate is quite high. Didn't have any problems in finding the Kc with the O² cell here, i am playing with. But I agree. If you are guessing only parts of L2 messages and thus only have some bits of a burst, you will have to do find_kc on your own. > > When you find a match, you should try find_kc with it and with several > other bursts to be sure it's not the "other burst" that's the problem > > With this command, unless you have a "cache", you would have to crack it > several time ... While cracking, Kraken will always output the same thing as before: original: "Found de6bb5e60617f95c @ 12" changed: "103 278 de6bb5e60617f95c 12 (found a table hit)" I previously added the command 'find_kc' which is exactly the same as calling find_kc from commandline and removed it later again. Maybe I should implement it again? BR, Georg _______________________________________________ A51 mailing list [email protected] http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51
