If you take a look to the attachment http://bugs.wireshark.org/bugzilla/attachment.cgi?id=605 of bug http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1342
You'll have a perfect example of an "evil" packet (not malicious but certainly evil) that causes 4(3?) bugs to be triggered. This malformed packet causes a recursion loop in AccessResult via dissect_ber_choice() because the choice's data is a sequence of 00s. Other than the bug in the code that generated the packet (which is not our business). We got one or two bugs here: - dissect_ber_choice() must stop looping without advancing. - and MMS's AccessResult/success1 might be IMPLICIT (I tried to make it implicit and it stopped the loop marking these packets as malformed). That causes a stack overflow which hides more bugs: One of the bugs I just fixed it, where a windows exception thrown up in the stack will skip all the ENDTRY groups causing a crash later in except_pop() when called by the ENDTRY of dissect_packet() Once fixed the file is read ok with tshark (even with -V but there you can see the effect of the loop). On WS (on Windows), on the other hand, the packet list is made OK but if you click on the "evil" packet (21) WS just shuts down (no dump to the debugger, no signs of why!). I believe this to be a out of memory error when generating the tree after dissection but honestly I do not know how to deal with this. I'll investigate the last issue (the shut down) but someone that knows how dissect_ber_choice() works should take a look at it. Luis -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev