Is it possible to do? Maybe. Is it possible to do well? It depends.
First and foremost, you need an oracle, that is, a way to determine what the correct behavior in any given circumstance is. There have been some references to requirement specifications earlier; that would be a good place to start, but is most likely not enough, as such things usually leave out a lot of implicit requirements.
Next, you need a way to prioritize problems, and prioritize testing. Otherwise, you risk spending time on things that don’t matter.
To give an example, right now, it seems like someone has handed you a black box, and told you to test it. So the first thing you do is you drop it on the floor, and it explodes. Is that a bug? It might be, or it might not be. Maybe it’s supposed to be a bomb, so exploding is good. But maybe it’s only supposed to explode when it hits an object with a certain velocity, in which case, you need to validate that requirement. Without an oracle, you have no way of even starting to test. Or, maybe you drop it and it explodes, which it shouldn’t, but it’s only ever going to be used underwater, so you need to focus on its interactions with things underwater first.
At the very least, you need to get as much documentation as possible. Manuals, any prior test cases or test scenarios, design documents, problem databases, and so on. And that may or may not be enough. You need to build very close relationships with the developer(s), because you’re going to be annoying them, either by asking questions, or by opening invalid bugs, or both.
Honestly, though, given what you said earlier, that no only do you have no domain knowledge, you have no time, money, or ability to hire anyone, you have a very, very hard path ahead of you. And I’d make sure the client understands this. And internally, within your company, you need to discuss if it’s worth the risk of taking on something that’s unlikely to go well, and will require a great deal of investment. And if the domain knowledge you build on this project could be transferred elsewhere or not, in case the other company changes their mind.