A lot of people posting questions about employers in India complain that their work isn't taken very seriously, and that managers have unrealistic expectations. In the US, if you could show some evidence that you had put in the hours, they would have to pay you - they couldn't 'reject' it simply because they're unhappy. This evidence might take the form of packet traffic on the VPN and modification dates on files. Are you using a source control system that has 'check out/check in' timestamps?
There may be some form of discrimination in this situation, either because you're female or because of some other attribute. Is there any internal or external agency that can address that if there is evidence?
As far as the project goes, they may not like the message, but if the appraisal is honest they can at least plan around it. More than likely they're losing money - it might have been a fixed bid and it's run over budget. This is particularly likely if the manager that estimated the cost didn't ask for any input from the developer(s) and simply quoted what 'felt right'. This is nothing you can do anything about, but until they find someone else that could fill in your role you may as well stay on it and do the best you can.
If they're not honoring your hours it might be a good idea to find another employer - you should be insulated from bad choices made by other people but this doesn't seem to be the case. Often the people that do things this way keep these habits for a long time, so you could end up in this situation for your entire career. If no one else would work on this project, you know why you're stuck with it.
I worked on a project in the mid-1990s where I turned into a 'golden boy'. I had been hired as a temp to develop something in VB3, at that time most of the applications were 'green screen' VT100 character based. I was going to demonstrate Rapid Application Development (RAD).
This was related to a US Air Force support contract - most of the people in the group were maintaining an application but not developing any new code. My job was to integrate two applications that had, up to that point, been operated as overlapping projects, one in Oracle and one in Microsoft Access. The complaint had been that people were having to enter the same data twice.
I started designing the VB3 screens, and linking data from the Oracle database, so in short order I had a 'gee-whiz' interface operating that impressed a lot of people. As I was rooting around in this, I was asked to help out on another problem having to do with Microsoft Access - it was running extremely slowly and no one understood why. Turned out they were using Vector type graphics in their command buttons, so the computer was rendering a huge amount of detail on postage stamp sized images. We converted them to .BMPs, which sped it up.
Pretty soon people were lined up to get help, the site manager had another problem in Access which I fixed, the government-side liaison had an old creaky machine with a nearly full disk, which I cleaned up enough that she could get more use out of it, and so forth. In the meantime, it was decided that the 'demo' that I was running should be completed and put in production. Thus my six week 'temp' turned into a roughly 2 year project.
Getting credibility, in this situation, means not only impressing your immediate boss, but everyone you work with. You have to be experienced enough to see solutions to many of the problems your co-workers are having and be in a position to help them get their stuff to work. You need to understand not only your program code, but the business application behind it - in the case I'm describing above I became more or less the base expert on the process, not just the program. The user community in this case were fairly high ranking military officers, but they weren't even remotely system designers, and had been dragged into this from other specializations. I would explain to them how the data flowed through the system, and if they were told that requirements were changed, it was up to me to formally describe the changes. At that point they would sign off on them.
Pretty soon you 'own' the system and can not only write the code but advise high level users on design and business process. At that point your boss would be ill equipped to argue with you.