Welcome to the world of legacy projects :-)
In reality, there are an awful lot of projects with spaghetti code, no up-to-date documentation and / or noone around to reliably answer technical questions.
However, software that is still in use always has users, whom you can ask about how they use the program, common use cases, quirky or strange behaviours they experienced etc. etc. This helps you understand the problem domain, and also - indirectly - a fair bit about the implementation as well.
This helps you get a feeling of what the important, central components of the program are. Thus you can focus your efforts and use your limited time better. Another means to identify these is to look at the source control commit history (if the project has one). The components modified most often are either the most actively developed or the most buggy parts of the code (often both).
The gist in all these is to try to separate the important details from the unimportant details, so that you can focus on the former.
Then you may start writing tests - both on the high and low level (i.e. system and unit tests) - simply as a means to record the existing behaviour of the program, and to understand it better. It may not be correct behaviour, but this is where you can start anyway.
Armed with tests, you may also refactor to learn - if you see a piece of difficult code, refactor it little by little to make it cleaner and easier to understand. If the code is covered well with tests, you may keep the results of your refactoring. Otherwise, you better throw it away as a prototype, and keep only the knowledge you gained.
This earlier answer of mine on SO may also help.