I have been in this position before. We worked with the client to put together a Specification Document, iterated over it several times, and once everyone agreed what was within scope and what was out of scope, the client signed it.
The main reason I keep documentation laying around is because it serves as a means to resolve disputes and remind all stakeholders of what the project requirements are.
In my situation, the client just plain forgot what he originally asked for. Reviewing the original requirements with him helped him realize his mistake, and we all agreed to go with the original requirements.
Had he insisted on the requirements changing, we would have charged a higher fee for the increased development and extended the original due date.
Project timeline and project features are two values in an equation that balance each other out. If more features are added, then the timeline must be increased or other features must be removed.
While you could make people work overtime or Make the Mistake of Adding More Resources to a Project Late, the chances of success are not great.
The best, real-life approach to getting through this sour patch is to be prepared by documenting requirements early. If it's too late to go back and do this, you can still salvage the project by communicating with the client, explaining that the requirements are vague, and calling a meeting to get updated requirements keeping in mind the balance between functionality and time to market.
Constant communication and being realistic about deadlines is your best asset at this point.