Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Please feel free to ignore this sub-thread. I'm merely happy that Apple finally shipped an iPad that would last (for me! no claims about anyone else!) more than a few weeks without falling over.

To learn iOS forensics, try Corellium iPhone emulated VMs that are available to security researchers, the open-source QEMU emulation of iPhone 11 [1] where iOS behavior can be observed directly, paid training [2] on iOS forensics, or enter keywords from that course outline into web search/LLM for a crash course.

[1] https://news.ycombinator.com/item?id=44258670

[2] https://ringzer0.training/countermeasure25-apple-ios-forensi...



I worked at Corellium tracking sophisticated threats. Nothing you’ve posted is indicative of a compromise. If you’re convinced I’d be happy to go through your IOCs and try to explain them to you.


Thanks. In this thread, I was trying to share a positive story about the recent iPad Pro _NOT_ exhibiting the many issues I observed over 5 years and multiple generations of iPhones and iPad Pros. If any new issues surface, I'll archive immutable logs for others to review.


I think this just further highlights my credibility point.


With the link I provided, a hacker can use iOS emulated in QEMU for:

  • Restore / Boot
  • Software rendering
  • Kernel and userspace debugging
  • Pairing with the host
  • Serial / SSH access
  • Multitouch
  • Network
  • Install and run any arbitrary IPA
Unlike a locked-down physical Apple device. It's a good starting point.


I'm much more convinced that you're competent in the field of forensics. But I still don't think suspicious network traffic can be categorically defined as a 'device breach.'

For all you know, the traffic you've observed and deem malicious could just as well have been destined for Apple servers.


Apple traffic goes to 17.0.0.0/8 + CDNs aliased to .apple.com, which my egress router blocks except for Apple-documented endpoints for notifications and software update, https://support.apple.com/en-us/101555

appldnld.apple.com configuration.apple.com gdmf.apple.com gg.apple.com gs.apple.com ig.apple.com mesu.apple.com mesu.apple.com ns.itunes.apple.com oscdn.apple.com osrecovery.apple.com skl.apple.com swcdn.apple.com swdist.apple.com swdownload.apple.com swscan.apple.com updates.cdn-apple.com updates-http.cdn-apple.com xp.apple.com

There was no overlap between unexpected traffic and Apple CDN vendors.


'Apple-documented' being operative here.


True, perhaps OVH in Germany (one anomaly example) is an Apple vendor. No way to know.


They said upthread that they had blocked 17.0.0.0/8 ("Apple"), but maybe there are teams inside Apple that are somehow operating services outside of Apple's /8 in the name of Velocity? I kind of doubt it, though, because they don't seem like the kind of company that would allow for that kind of cowboying.


I don't doubt it in the slightest. Every corporate surveillance firm—I mean, third-party CDN in existence ostensibly operates in the name of 'velocity'.


Apple has used AWS and Cloudflare in the past, too, so it’s not like seeing that traffic is a reliable indicator of compromise.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: