Sure they do, they're familiar with the design. Unless it is completely open source or has been totally reverse engineer (which I doubt) then that is an advantage.

It’s not an advantage, in practice. Writing exploits against iOS is a very scarce skill, and the people who can do this might be slightly more productive if aided by the source, but the reverse isn’t true. Having the source doesn’t teach you anything about finding and exploiting these bugs.

It might seem logical to those unfamiliar with how these hacks work, but consider that such hacks do not depend on the secrecy of the design. Also consider that Apple hires regular software and hardware engineers, who do their best to design a system, and Apple then hires hackers (both internally, as well as external consultants) to find weaknesses in their designs. These weaknesses are then fixed before the product ships, meaning even those who were paid to break it no longer know how. This alone should tell you that people who know the system intimately are not the ones who understand how to break it.

Put another way, if I need to make this product, and there are two candidates I can hire, one person who wrote the software and one who knows nothing about the software but is demonstrably skilled at finding exploits in similar systems, I’ll take the latter in a heartbeat.

I don't know if that's true, but if I had the same power as a government agency, which would allow way higher salaries than Apple's or any other hi tech corporation, that's the first thing I'd attempt to do: find ex/unhappy/disgruntled engineers and offer them 5x pay plus a luxury home and lab in some tropical island.

Also don't forget the hardware. Like with most/all other phone vendors, iPhone chips aren't made in the US; most of the design maybe is, but the chips themselves are not, and finding a Chinese hardware engineer happy to help would be even easier because all he should implement is a covert channel to tunnel sensitive data (passwords?) to a known place. If you have access to the hardware that should be trivial to do: just implement a small undocumented flash memory space anywhere, then when the user taps a password an also undocumented firmware routine (that's hundreds of bytes, very easy to conceal) would add the password in that small memory that can be read only in certain conditions (say connecting power+tapping a bossa rhythm while with the phone screen is facing down+disconnecting power - that seems crazy but you get the idea: every sensor is a switch and any switch can be used to enter a code). A few spare kilobytes of memory here and there would allow this and other spying mechanisms, so I would't be surprised at all if some big agency would attack the hardware/firmware rather than the software.

> If you have access to the hardware that should be trivial to do: just implement a small undocumented flash memory space anywhere, then when the user taps a password an also undocumented firmware routine (that's hundreds of bytes, very easy to conceal)

I sincerely apologize for being this blunt, but you clearly have no clue what you’re talking about. Ask anyone who’s shipped any piece of hardware they helped design, let alone a processor, and they won’t be able to answer because they’ll be laughing so hard. Adding persistent hardware based spying like you describe into a design is anything but trivial.

By spying I didn't mean moving multi megabytes of data or reprogramming a processor. On a PC stealing passwords can be done by inserting a small uController that acts as a HID device on one side and talks with a USB keyboard on the opposite side. If you hide it into a keyboard and instruct it to record the first two lines one writes just after power on, which are almost always the system username and password, then add them to a flash into the microcontroller, then it's just a matter of social networking to get the data ("hey, here's a new keyboard, I'll trash the old one for you"). On phones one has to intercept screen taps, which is harder, but if you have access to the hardware and develop its drivers, you very likely can do that before passwords get encrypted. All it needs is a daemon reading taps and comparing them with the virtual keyboard key positions (assuming you haven't access to the virtual key output, which would make it even easier) once you have that daemon, tell it to read the system load and intercept what the user taps after a long sleep, which will very likely be the device pin. Want the bank password?, just read what the user taps when there's a bank app in foreground. I'm sorry for those laughing, but it can be done.

> find ex/unhappy/disgruntled engineers and offer them 5x pay

5x pay sounds quite regruntling, as in P.G. Wodehouse's "I could see that, if not actually disgruntled, he was far from being gruntled."

[ https://www.goodreads.com/quotes/26678-i-could-see-that-if-n... , https://en.wiktionary.org/wiki/regruntle ]