Is it possible to re-broadcast the appropriate parts of a captured four way handshake and connect to the router? If not why so?
In the past, there were ways to re-broadcast encrypted packets to actively and more quickly crack a WEP key. This was by replaying an ARP request, in order to gather IVs (see the first minute of this). The ARP request, while encrypted, is easily identified due to its distinctly small size. It was also easy to replay because there is no per-session information with WEP as there is with WPA and WPA2. Here is some good info on ARP replaying, starting on slide 15.
So, more to answer the question of whether it's possible to replay any part of the WPA2 handshake in order to gain access, the answer is no. This is because, during the handshake process, per-session information is exchanged called the ANonce (Authenticator Nonce) and SNonce (Supplicant Nonce). You need this information, on a per-session basis, in order to derive the Pairwise Transient Key. What is not shown in most 4-way-handshake diagrams is that the MAC addresses of both sides is also used to derive the per-session PTK (Another reason why MAC filtering is not an effective security control). This means that the MAC addresses of both sides are required to be sent via plain text via the specification.
It is important to note that the ANonce and the SNonce are in no way related. If you send a specific ANonce, you do not receive any sort of respective SNonce. So, if you replayed an ANonce from a previous handshake, you should not get the same SNonce in the response (or vice versa).
Keying works in a rather straightforward way when talking about WPA/WPA2 (see slides 24 and 25), and was built to alleviate some of the primary security concerns of WEP.
What you mean is known as "replaying" but is does not apply here. One of the steps involved in the four step handshake authentication process in WPA2 is a challenge-response and your client needs to know what is the "password" to give the right answer. So, you cannot reuse a previous capture because, basically, the challenge will be different every time.
If you're trying to capture the hash for an offline attack you will need to be capturing wifi traffic at the same time a client is authenticating with the router. If you see clients currently connected to the router you can generate deauth packets to knock one or all of them offline. When the client(s) reconnect you will capture the handshake. Once you have the handshake you can then attempt a dictionary and/or bruteforce attack on it. May favorite suite of tools for doing this is aircrack-ng. Also using Airbase-ng from the aircrack-ng suite you can grab the parts of the handshake you will need directly from nearby clients check out this video.
ALSO with most of the newer routers there is a backdoor so to speak. It's called Wifi Protected Setup. It's a service that makes it easier for users to setup devices on their wireless network. It also makes it easier for an attacker to get in. There is an 8 digit administrator pin that a machine can send to the router and the router will cough up the WPA key. The tool I have used for that is reaver it's very simple to use just type a command and let it run it takes a while but it will usually get the key. See Steel City's comment below. He gives good details on how this attack works and it's pitfalls.
First, some vendors were treating the first half of the WPS key like a MAC OUI, and was static (many vendors have since fixed this)
I don't see a lot of change in this, very recent hardware comes on the market with a generic PIN or using a nown algorithm. Eventhough he builder is aware of the isssue and implemented a AP rate limit, then the Internet provider give a routeur with a firmware designed by them and the security breach is open again. We are in 2014 and the breach was revealed in 2011,,,,
Second, WPS would sometimes identify whether the failure was in the first or second half of the key (many vendors have since fixed this).
It is not like this until now, the flow implement a M message answer-response and this is external to the vendors.
That how works WPS 1.0, maybe with WÑPS 2.0 that will change but for now you will always get a M5 when you get the first half of the PIN and that it...
So you just have to analyse the traffic and when the M5 shows up you have brute forced the first half of the PIN. Nothing to do against that...
be aware with WPS.