QUOTE(No_Name @ Jun 17 2009, 05:44 PM)
What your trying to do have been looked in to many times and its quickly become clear its not worth it due to the way the packets are encrypted and treated by the system.
I'm quite aware, though they and I were probably doing it for different reasons. Regardless, help would be appreciated.
QUOTE(SoLovely @ Jun 17 2009, 07:36 PM)
I'm quite aware, though they and I were probably doing it for different reasons. Regardless, help would be appreciated.
The reasons do not matter you still hit the same walls, and more.
QUOTE(No_Name @ Jun 18 2009, 04:59 AM)
The reasons do not matter you still hit the same walls, and more.
Honestly, without knowing my motives you can't make any judgment as to the outcome of what I'm trying to do. The kerboros key exchange that sets the encryption key for the entire session and the header checksum on all traffic after the authentication is completed would obviously make it near impossible to 1) find the session's encryption key(which is randomly generated per session) and 2) read(the plaintext version of) or edit any traffic coming through my bridge. If I already know that, why am still pressing forth? Perhaps because my business doesn't involve finding methods to obtain encryption keys or editing packets? Yeah...
Help would still be appreciated, and my question still stands; is there any way to capture, analyze and resend all traffic coming in and leaving from my bridged port? Any if I am doing that(via programming), will the resent packets still be identical to those obtained or will I have to spoof the IP on them so as not to mess up the checksum?(new to programming here, and these questions are just based on logic)
Thanks.