Ethereal-dev: Re: [Ethereal-dev] ethereal dump core when trying to decode mapi encrypted data
What is purpose of pinfo->fd->flags.visited?
The core dump happened because pinfo->fd->flags.visited is 1 in packet-dcerpc-mapi.c, but
mmd=g_hash_table_lookup(mapi_decrypted_table, &mmd_key) return NULL.
#0 0x4020a7fb in mapi_decrypt_pdu (tvb=0xbc90568, offset=32, pinfo=0xc608f68,
tree=0x84050e8, drep=0x0)
at ../packet-dcerpc-mapi.c:188
188 add_new_data_source(pinfo, mmd->tvb, "Decrypted MAPI");
(gdb) p mmd
$1 = (mapi_decrypted_data_t *) 0x0
(gdb) p pinfo->fd->flags.visited
$2 = 1
It happened when user open "Encrypted data" subtree for a MAPI packet before doing Decry
MAPI PDUs. The following logic seems wrong. Can someone take a look?
if(!pinfo->fd->flags.visited){
ptr=(const unsigned char *)tvb_get_ptr(tvb, offset, len);
mmd=g_mem_chunk_alloc(mapi_decrypted_data_chunk);
mmd->callid=di->call_id;
mmd->frame=pinfo->fd->num;
mmd->data=g_malloc(len);
for(i=0;i<len;i++){
mmd->data[i]=ptr[i]^0xa5;
}
mmd->tvb=tvb_new_real_data(mmd->data, len, len);
g_hash_table_insert(mapi_decrypted_table, mmd, mmd);
}
if(!mmd){
mapi_decrypted_data_t mmd_key;
mmd_key.callid=di->call_id;
mmd_key.frame=pinfo->fd->num;
mmd=g_hash_table_lookup(mapi_decrypted_table, &mmd_key);
}
add_new_data_source(pinfo, mmd->tvb, "Decrypted MAPI");
TJ
--- Guy Harris <gharris@xxxxxxxxx> wrote:
> On Tue, Aug 10, 2004 at 09:35:23PM -0700, TJ Li wrote:
> > Codes are from latest ethereal branch.
>
> I.e., the current Subversion main line?
>
> > I made it by myself. I attached back trace here.
> >
> > To reproduce it, select Preference-> Protocol -> Mapi Decrypt MAPI PDUs,
> > ethereal crashes sometimes, not always, seems crash once the other
> > time.
> >
> > I also attachmented a mapi traffic here too.
>
> I can't make it crash with that capture on my FreeBSD 4.6 machine
> (current Subversion code). There could be some OS difference that keeps
> it from crashing.
>
> > What should I do when I make ethereal so that it would show real function
> > names instead of ?? when I backtrace core in gdb?
>
> Try running
>
> ./libtool gdb ethereal core.3920
>
> When you build a binary that requires libtool (as Ethereal does), you
> need to use "libtool gdb" rather than just "gdb" to debug the version of
> the binary built in that tree (but not to debug the installed version) -
> the "ethereal" file isn't the executable image for Ethereal, it's a
> shell script wrapper, generated by libtool, to run that executable image
> with the appropriate environment variable settings so that it'll find
> shared libraries (such as libethereal.so).
>
> Note the
>
> "/usr/home/nfs/tli/work/riverbed/ethereal-latest/ethereal/ethereal": not in executable
> format: File format not recognized
>
> error, and the
>
> Core was generated by `lt-ethereal'.
>
> "lt-ethereal" is the actual Ethereal binary; it's in a subdirectory
> (".libs", I think) - but you can't necessarily do
>
> gdb .libs/lt-ethereal core.3920
>
> You should, instead, do "./libtool gdb ethereal core.3920".
>
> > Also, the latest ethereal windows version seems have problem with
> > "follow tcp stream" .
>
> What kind of problem?
>
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
