I'm going to assume at some point you can get the code to at least compile. If you can't even get that far you are on a fool's errand.
Lacking proper requirements, specifications, screenshots or an actual functioning systemscreenshots is not a blocker for writing tests. As long as you can read source code, you can write tests.
If you are given permission to refactor the code base to isolate things like database connections behind their own interface, it becomes possible to write some black box unit tests — basically write tests to throw some input at a method and assert its behavior or output. Get tests covering each line of code in one method and then have one of the senior members of the team review your tests.
If you are not given permission to refactor the code base in order to write unit tests then full integration tests or UI automation tests are your only option. Even then, black box testing is your best strategy — throw some input at the UI and see how it reacts. Make your asserts. Have a senior member of the team review your tests.
At some point you will have enough automated tests that you can begin refactoring the code base with confidence to introduce unit tests. The UI tests ensure the main business use cases work, and then you can retrofit an architecture conducive to unit or component level testing.
Another benefit of UI tests is that you can build a reputation with your team that you understand the code base, which in turn makes them more open to you introducing change, because the proof is in the pudding. And you will have made pudding by way of writing passing tests.
In short:
- Write Black Box tests as unit or automated UI tests
- Have senior members review your tests
You would be surprised how quickly you can learn the big picture view of a 700,000 line application