HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
mfrister
pushproxy
Python2013–2020
mfrister / pushproxy · Archived

pushproxy

A man-in-the-middle proxy for iOS and OS X device push connections

4Distinct people
4Mentions
1Explicit recommenders
437GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A man-in-the-middle proxy for iOS and OS X device push connections

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

http://ios-rev.tumblr.com/ http://imfreedom.org/wiki/IMessage https://github.com/meeee/pushproxy I was curious, too. I had lunch with the guy who made the proxy (man, I love…

sneak used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year4 dated mentions

Observed mentions: 2013-05-15 23:08:37 UTC to 2020-11-17 01:29:24 UTC.

0122013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20132014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2020

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC202
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC101
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC000
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC000
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC000
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC000
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC101

What Hacker News says

4 sources
Because Apple users allow Apple to manage so many aspects of the computers they sell, remotely, it seems to me getting access to Apple traffic or the data Apple collects and stores about its customers is nearly as informative as getting physical access to the customer's Apple computer. "Privacy" in the case of the traffic relies on two things: (a) trust in Apple to not get hacked or intentionally share the data with anyone and (b) trust in TLS (not all VPNs use TLS). Apple customers have little control over how Apple operates nor the development/maintenance of TLS. Apple customers can control physical access to their computer but Apple gets a free pass to access/monitor these computers remotely. What would be a hypothetical "real-world scenario" where it's a genuine problem that Apple traffic isn't routed through the VPN There is an exi
Read the rest
sting flaw in TLS and Apple does not learn about it immediately, or, some individual/organisation gets access to Apple's private key with or without Apple's consent, a fact which may or may not become public knowledge. There are a variety of "Apple services" that require TLS-encrytped traffic sent to/from Apple that are initiatied by today's Apple computers, with or without user interaction. Some of the content sent to Apple computers as part of these "services" could come from "fourth party" servers that are part of CDNs who Apple has employed to serve content. To the extent any of this Apple traffic is routed based on geolocation, e.g., from the nearest CDN server, that could reveal something about the user's location. https://www.richard-purves.com/2016/09/10/apple-services/ The content of this traffic could vary based on the service. Decrypting iTunes/AppStore traffic might reveal the user's AppStore searches and the apps she has installed that have updates available. A full analysis of all the possible data leaks across all the services would be no small amount of work. One more service that the blog post above seems to omit is Apple's NTP service at time.apple.com (Apple performs DNS-based routing). This NTP traffic could produce vast logs of Apple customer IP addresses over time. Some years ago it was said that Shodan.io was using NTP to gather IPv6 addresses to scan by participating in pool.ntp.org. Decrypting Apple so-called "Push" connections might possibly be viewed with a jailbroken device. Data included in the protocol messages might include connection type, OS version, OS build, device model, etc. https://github.com/mfrister/pushproxy
In Big no on Big Sur: Mullvad disallows Apple apps to bypass firewall
> For example, conversations which take place over iMessage and FaceTime are protected by end-to-end encryption so no one but the sender and receiver can see or read them. Apple cannot decrypt that data. I don’t know, then, why when I do an iCloud restore on a brand new device, all existing messages are recovered. Is this a way to recover all past messages that’s not really addressed, if I can still recover all historical messages after replacing all devices connected to an iCloud account at once? Cursory links: http://security.blogoverflow.com/2012/09/qotw-34-imessage-wh... https://github.com/meeee/pushproxy http://imfreedom.org/wiki/IMessage
In Apple’s Commitment to Customer Privacy
sneak·May 15, 2013Recommendation phrase
http://ios-rev.tumblr.com/ http://imfreedom.org/wiki/IMessage https://github.com/meeee/pushproxy I was curious, too. I had lunch with the guy who made the proxy (man, I love living in Berlin) and discussed his efforts to reverse engineer the iMessage protocol (which runs inside/on top of Apple's push notification system). AFAICT, iMessage activation fetches a key from Apple that is either tied to or based on the hardware serial number. Based on Apple's history of rather excellent crypto implementations on iOS[1] I'm guessing that (on iOS) this key then gets signed by either the hardware key or somesuch to authenticate the device to the APNS. On OSX, the activation request includes the hardware serial number of the mac making the request, and the service rejects arbitrary SNs (though valid SNs are predictable so those can be used to get
Read the rest
iMessage working on OSX inside a VM). If I had the free time, I'd finish reversing the protocol. I don't have proof, but preliminary observations suggest that iMessages are, indeed, end-to-end encrypted. http://www.csoonline.com/article/731446/fbi-highlights-imess... http://www.macobserver.com/tmo/article/apples-imessage-encry... http://news.cnet.com/8301-13578_3-57577887-38/apples-imessag... [1] http://images.apple.com/iphone/business/docs/iOS_Security_Oc...
In FOIA release: Completely Redacted Document About Text Snooping

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.