This doesn't make sense, and is very difficult. If this is some academic project you may want to select a different topic.
First off, what kind of "dependencies" are you looking for? Are you trying to find what version of the Simulink function blocks a binary had its source code generated from? What compiler was used? What RTOS is employed? Which middleware vendor provided random blocks in the model generator? ECU binaries are flat, static binaries which are compiled with optimization, so information is fundamentally destroyed and their structure will be altered freely by the compiler (inlining, optimization, etc). There's not some linker table you can use to find library dependencies like in desktop software, and there's not some set of libraries that are "linked against" to produce the final product.
The ECU build process does not look like a traditional software project; code is usually generated from models using a code-generation tool like Simulink, ASCET, etc. This means that instead of finding calls to library functions like you might in a traditional statically linked binary, you will find that the actual source code used to generate the binary is full of repeated blocks provided by a middleware vendor. One way to think about this is that "linking" as you'd think about it traditionally has already happened before the C compiler toolchain is ever invoked - the model generator has "linked" various code blocks (from middleware vendors, the standard libraries, or custom) together in order to generate the C source code in the first place.
The only way I can see that would be practical to attempt this would be to use function hashing. If you had access to the dependencies you were trying to detect, you'd use something like BinDiff or IDA's FLIRT/Lumina. You'd build a fuzzy hashed database of functions in the dependency, then compare them with the binary. But, this isn't likely to work very exactly.
Hello buddy. Thank you so much for the reply! Also sorry for taking ages for replying back I kinda got busy with other stuff.
I also saw your reply on reddit!
I'm not sure if I understand everything you mentioned in your reply but I looked into BinDiff and IDA's FLIRT/Lumina and they're really interesting tools and will be really helpful with stripped files. From what I understood it can match functions and identify them giving back some of the symbols and names that were gone when the file was stripped. But I'm not exactly sure what's next tbh. Giving I have a non-stripped file, I'm not sure how to trace the imported functions whether in assembly or the pseudo-code generated by decompilers. I found out about a new tool in the latest update of ghidra which is ghidra BSim and I think I'm checking this one next.
