Fix lsbom segfault or not listing content #21, #33 and hardcoded path in Makefile #35

[cluck]

I have tested lsbom against payload.pom, pre.pom, post.pom of Apple iOS/tvOS OTA updates and verified them working.

[hogliux]

First of all, thank you so much for committing some time to this years old project. I no longer maintain it so I'm always happy when people jump in and give it some love. Thank you!!

I'm a bit unsure about this PR. First of all, the hard coded path in the makefile is for reproducible builds. If you replace it with $(SRC) the builds will no longer be reproducible but will depend on where you build them. This is a problem for automatic build integration which build in random tmp folders but then check the hashes of built binary.

Also, I don't quite understand the whole issue with the "Paths" line. It used to be just name == "Paths" which seemed fine to me but people complained that the code didn't work with iOS OTAs (see this issue for example). This tool was never intended to be used with iOS OTAs so I never tested it with this.

What value does name have with iOS OTAs? Is there may be another null character inside the C++ string for iOS OTAs? Anyway the code as it currently stands (i.e. strstr == 0) is definitely wrong so it would be good to fix this. I'd just like to understand why name == "Paths" was wrong in the first place.

If rfind does fix it then I'm happy to accept this. But I'd actually prefer to just use find here. Sure rfind is more effecient but I'd prefer readability. After all this is not a performance sensitive tool.