Generally speaking finding vulnerabilities is not only about static reverse engineering, there are also dynamic techniques such as fuzzing.
There are some fuzzing frameworks/products that can be used for this,
part of them are using dynamic instrumentation and such as AFL, some part gives you an ability to configure generation of the data such as Peach.
If you can not or don't want to use fuzzers, you can reverse engineer the program. The fact of stripping doesn't mean that you lost all the useful information about the binary, in most cases you still have a lot of other possibilities to locate specific functionality in it such as:
- Logs, strings and constants. For example if you have some kind of logging system inside or if application generates some readable information it will give you a lot (for example strings like "calling function X with parameters Y and Z" are not that rare) - from this you can conclude the function name and parameter types. Specific constants can show you where and which encryption is used, etc.
- Dynamically loadable modules, such as .so and .dll. Most of system calls are used via library functions, and if these functions are linked dynamically (i.e. loaded dynamically when program runs) you still can locate calls to such functions, and it will give you more information then system call tracing because the information needed for such dynamic linking is not stripped.
BTW, if you still want to run the application in order to locate system calls,
you can expand this methodology to using ltrace which is not limited by system calls, but gives you all dynamic library calls.