En el verano de 2014, mis amigos y yo salimos a caminar y sucedió un hecho histórico. Mientras filmaba el video, de repente, el iPhone 5C cayó de las manos de mi esposa y se estrelló contra el piso de concreto.
En ese momento, me pareció una situación triste. Pero este fue precisamente el impulso para lanzar el servicio, que ahora atiende a más de 15 millones de usuarios.
¿Qué tiene que ver el iPhone con él? Que tipo de servicio ¿Cómo está todo esto conectado? Respuestas debajo del corte!
Prólogo
En este artículo quiero compartir con ustedes los eventos que comenzaron en 2014. Te contaré todo como estaba mientras mi memoria está fresca, y también compartiré información que aún no se ha publicado en ningún lado.
Reparación
Como cualquiera que sintiera la amargura de los vidrios rotos en su dispositivo favorito, quería arreglar esto lo más rápido posible. La pantalla en sí no sufrió daños y la reparación es solo un reemplazo para el cristal de la pantalla táctil. Un amigo me recomendó SC en Kiev, y envié un teléfono allí. Lo volvieron a pegar y me lo devolvieron. No podía esperar para recibir el teléfono por correo.
Tan pronto como lo recibí, otra decepción me esperaba. Se reemplazó la pantalla táctil, pero había manchas amarillas en los bordes de la pantalla. En el SC, me prometieron arreglarlo o reemplazarlo con el original junto con la pantalla. Como todavía encontré rasguños debajo del cristal, decidí reemplazar completamente la pantalla.
Una semana después, recuperé el teléfono, resultó que la pantalla no era original. Incluso en la superficie misma, estaba claro que estaba en ángulo con el cuerpo. Y los colores eran más tenues, lo que distinguía claramente la pantalla del original. Resultó que las pantallas originales para el iPhone son difíciles de encontrar. Decidí soportar esta situación y, en algún momento en el futuro, cambiar el iPhone a un modelo más nuevo.
Pasaron unos días, me acostumbré lentamente a la exhibición china. Estaba sentado en un sillón y el teléfono se me escapó del bolsillo. Cayó al suelo de madera, el cristal volvió a romperse. El teléfono con el cristal original se cayó muchas veces, pero no se estrelló hasta el combate de hormigón. Pero los chinos, vidrios encolados, se rompieron en el primer intento.
La constatación de que no podía comprar el vidrio original me hizo pensar en encontrar un donante. Empecé a buscar un iPhone que se vendiera en olx por partes. Resultó que hay muchos que tienen un problema con la función iCloud Find My iPhone. Estos teléfonos no se pueden activar y permanecen inactivos hasta que ingrese la ID de Apple del propietario, o si el propietario retira el teléfono de su cuenta.
Encontré un donante, el iPhone 5C está en excelentes condiciones, está bloqueado bajo el operador y bajo iCloud. La pantalla se acercó con éxito a mi teléfono y finalmente todo encajó. Decidí mantener el iPhone verde, por si acaso, como donante. Finalmente, pude calmarme y olvidarme de este problema.
Que sigue
Pasaron varias semanas, el iPhone 5C verde yacía en mi escritorio debajo del monitor. Pero de vez en cuando lo recordaba, porque por costumbre no me gustan las cosas que están inactivas. Por lo tanto, el teléfono estaba atado a un operador desconocido, e incluso con vidrios rotos, el iCloud no tenía sentido. Pero la idea de que el teléfono en teoría se puede desbloquear, aún de una manera desconocida, no me dejó.
doulCi
En general, comencé a buscar en Google, leer los foros. Encontré información sobre doulCi (el nombre no es extraño, pero es casi al revés iCloud). Fue un equipo de entusiastas quienes lanzaron un servidor para evitar FMI para el firmware iOS temprano. Lanzaron MITM e intercambiaron paquetes de un iPhone desbloqueado a uno bloqueado. En general, en ese momento Apple no verificó el cumplimiento de los paquetes con Serial / IMEI y doulCi lo usó con éxito. No trabajaron para su servidor durante mucho tiempo, pero lograron desbloquear alrededor de 70 mil dispositivos. Aquellos que lograron conectarse a su servidor recibieron un dispositivo en funcionamiento en el que la tarjeta SIM no funcionaba. Luego, uno de su equipo filtró la fuente a Internet, y Apple parchó con éxito ese agujero. En esta etapa, su equipo se separó, y todos fueron de diferentes maneras. Su servidor ya no funcionaba.
Por supuesto que no lo sabía entonces. Fui a su sitio web oficial y vi temporizadores allí, diciendo "Espere hasta las 16:00 del viernes, luego iniciaremos el servidor y lo desbloquearemos gratis". Y había campos en todas partes para ingresar al IMEI y el registro. Entonces decidí esperar esta hora. Tan pronto como llegó el momento, puse una alarma para no perder, mantuve el cable USB listo. Llegó el momento, fui a su sitio, y allí
todo funciona un nuevo momento para iniciar el servidor. Traté de esperar todavía, y todo resultó ser una tentación publicitaria. Me molestó bastante, pero no iba a parar.
Servidor proxy
Más tarde, comenzaron a aparecer noticias sobre los servidores proxy, que decían que al conectarse a ellos, puede ir a la página web.
En la página que da Apple
Al hacer clic en "Ayuda en la activación", el usuario fue llevado a una página con texto. Pero los desarrolladores de Apple han perdido un pequeño detalle, el enlace no condujo a HTTPS, sino a una dirección HTTP.
http://static.ips.apple.com/deviceservices/buddy/barney_activation_help_en_us.buddymlEsto hizo posible interceptar y reemplazar el tráfico, ya que no estaba encriptado.
Los servidores estaban cayendo constantemente, lo mejor que encontré fue el servidor niltpH. Pero él cambiaba constantemente los puertos, ya sea para que los usuarios visitaran su sitio con frecuencia, o el servidor no podía soportarlo y por eso eliminaba la carga.
Constantemente me preguntaba por qué hacer un proxy si puedes reenviar consultas DNS.
No habrá carga pesada, y el servidor siempre estará en línea. Pero solo había servidores proxy.
Luego comenzó una ola de estafadores, comenzaron a proxy masivo del servidor.
Al mostrar una página con el pago de un rastreo completo inexistente, muchas personas sufrieron estos servicios falsos. Los servidores proxy le permitieron obtener un control total sobre el tráfico. Por lo tanto, los malos robaron contraseñas y tarjetas de crédito, y los usuarios creían que esto funcionaría ya que cualquier cambio en su dispositivo era creíble.
Apple no hizo nada para marcar la diferencia, pero lo hice. Como resultado de mis acciones adicionales, nadie más podría encontrar a los estafadores del servidor proxy en el motor de búsqueda.
Primer servidor de omisión de DNS de iCloud
Resuelto, iniciaré mi servidor. Una noche de invierno en diciembre, comencé el desarrollo. Para implementar mi idea, necesitaba un servidor HTTP y un servidor DNS. Decidí escribir ambos servicios en C ++ usando Visual Studio 2010. Trabajando con sockets directamente byte por byte sin bibliotecas de terceros.
El protocolo DNS no es complicado, para una solicitud UDP, una respuesta, con la misma estructura cada vez. Durante un par de horas escribí un servidor DNS simple, respondió con una dirección IP estática en static.ips.apple.com y el resto lo tomé con DNS de Google.
Entonces comencé a escribir un servidor HTTP. El primer paso fue simplemente producir una página HTML. Se cargó en la memoria cuando se inició el programa, y luego se emitió en paquetes preparados para todos los que enviaron una solicitud al puerto 80. Entonces, mi programa devolvió una página a todos los que enviaron la solicitud, independientemente del host especificado. Todo funcionaba en el navegador, pero al registrar DNS en la configuración de Wi-Fi iOS, al hacer clic en "Ayuda en la activación" recibí un error en el teléfono.
Después de analizar el tráfico, resultó que Apple usa archivos XML, generando una interfaz remota para ellos.
El código de muestra se puede ver en el enlace de ayuda de activación:
static.ips.apple.com/deviceservices/buddy/barney_activation_help_en_us.buddymlY aquí está la respuesta del servidor que solicita la contraseña en el dispositivo bloqueado:
<xmlui> <script><![CDATA[function enableNextButton(){ var fieldPassword = xmlui.getFieldValue('password'); if (fieldPassword && fieldPassword.length >= 3) return true; return false; } function validateForm() { var fieldLogin = xmlui.getFieldValue('login'); var fieldPassword = xmlui.getFieldValue('password'); if (fieldLogin == 'test') { xmlui.setFieldInvalid('login', false); xmlui.alert("Test!"); } else { xmlui.setFieldInvalid('login', true); xmlui.alert("Value entered is not 'test'."); } }]]></script> <page> <navigationBar title="Activation Lock" loadingTitle="Activating..." hidesBackButton="false"> <linkBarItem position="right" label="Next" httpMethod="POST" url="/deviceservices/deviceActivation" style="blue" enabledFunction="enableNextButton"/> </navigationBar> <tableView> <section footer="This iPhone is linked to an Apple ID. Enter the Apple ID and password that were used to set up this iPhone."/> <section footer=" : This iPhone has been lost. Please call me. (123) 456-1234"/> <section footer=" " footerLinkURL="http://static.ips.apple.com/deviceservices/buddy/barney_activation_help_ru_ru.buddyml"> <editableTextRow id="login" label="Apple ID" placeholder="example@icloud.com" disableAutocapitalization="true" disableAutocorrection="true" keyboardType="email"/> <editableTextRow secure="true" id="password" label="" placeholder=""/> </section> </tableView> </page> <serverInfo isAuthRequired="true" activation-info-base64=" "/> </xmlui>
Después de estudiar la fuente, puede comprender que el código tiene JavaScript y funciona dentro de las etiquetas <! [CDATA [..]]>
Y en ese momento, los servidores proxy existentes usaban una sola página con código HTML.
<xmlui> <page> <navigationBar title="Games" loadingTitle="Loading..." hidesBackButton="false"> <linkBarItem position="right" label="Next" httpMethod="POST" url="/deviceservices/deviceActivation" style="blue" enabledFunction="enableNextButton"/> </navigationBar> <htmlLabelRow> <![CDATA[<html> HTML </html>]]></htmlLabelRow> </page> </xmlui>
En el teléfono, puede ver un sitio simple en lugar del texto de activación. Las cookies funcionaron. Pero al hacer clic en cualquier enlace externo, todos los estilos se extraviaron y las transiciones posteriores fueron imposibles. Así funcionaban los servidores proxy en ese momento.
Después de un par de horas, tenía un servidor DNS y HTTP en funcionamiento, que devolvió 1 página para cualquier solicitud. XMLUI resultó ser marcado con parámetros desconocidos que no se podían encontrar en ningún lado. Y ahora no hay documentación en ningún lado. Apple lo usa solo dentro de sus productos.
De hecho, los elementos estándar de iOS son generados por XMLUI, incluso aquellos que funcionan sin conexión. Listas, botones, iconos, la elección de fecha y hora, submenús, todo esto es solo el resultado de convertir el XML de un script similar en una interfaz sobre la marcha.
La comprensión de que muchas de las interfaces en iOS se hicieron de una manera tan torpe me decepcionó un poco. Esto es cuando espera que todo se haya hecho de la manera más óptima posible, y resulta que hay una capa en la capa.
Luego me di cuenta de que, en teoría, si conoce el diseño de la interfaz, puede generar una interfaz iOS nativa muy cómoda con una lista de iconos y enlaces. Como la configuración en iOS. Y reemplácelo por completo con el diálogo de activación.
Todo lo que entendí del código ya guardado es que hay una cierta tabla con la capacidad de agregar una gran cantidad de <pie de página de sección, que puede referirse a otros archivos XMLUI. Es muy posible hacer que su servidor XMLUI tenga alguna información. Pero quería obtener exactamente la lista de sitios y poder ir a Google, por ejemplo.
¿Cómo hacer una interfaz de marcado sin conocer los comandos?
Lo primero que se me ocurrió fue que, dado que iOS genera comandos, compara las cadenas de parámetros XML, por lo que deben almacenarse en algún lugar del firmware. Idealmente, encontrará un archivo con una lista de comandos que puede intentar agregar al código XMLUI, pero no, esto no sucedió.
En ese momento, el iPhone 4 ya estaba pirateado por completo. Allí, desde debajo del cargador de arranque, puede arrancar y obtener acceso completo al sistema de archivos, no importa si hay una contraseña de iOS o no.
Encontré el firmware de iOS 7 descargado del iPhone 4 y comencé a elegirlo. Recopilé una lista de palabras famosas de esos archivos XMLUI que recopilé y comencé a buscar palabra por palabra todos los archivos de firmware. A primera vista, un ejercicio inútil, es comparable a encontrar una aguja en un pajar, pero por alguna razón estaba seguro de que encontraría algo. Pasó más de una hora, no pude encontrar nada, pero el archivo dyld_shared_cache_armv7 me llamó la atención. Pesaba tanto como 300 MB, mientras que todo el firmware pesaba aproximadamente 1 GB.
Resultó ser un "paquete" de bibliotecas dinámicas. Para no sobrecargar el sistema de archivos, Apple empaqueta todas las bibliotecas dinámicas para todos los programas del sistema en 1 archivo. Utilizando las herramientas de desarrollador de Apple, descomprimí este archivo y recibí una gran cantidad de archivos. Comencé a buscar nuevamente en sus datos palabras de mi lista, intenté combinarlas y seleccionarlas. Comencé a buscar ortografía de estilo similar: unas pocas palabras, la primera con una letra minúscula, el resto con mayúscula, sin espacios ni subrayado.
Después de innumerables intentos, pude encontrar la palabra htmlButtonRow. Si lo pegas en el código, obtienes un error, por lo que de alguna manera influyó y se reconoció. El siguiente paso fue la selección de un lugar, ¿dónde pegarlo?
Finalmente, el código funcionó y obtuve la codiciada barra de menú:
<tableView> <section> <htmlButtonRow name=" "> </htmlButtonRow> </section> </tableView>
Solo se mostró una línea y el texto, cuando se presionó, no pasó nada. Pero el nombre de la sección htmlButtonRow estaba hablando de HTML, lo que significa que probablemente pueda agregar el código de la página allí.
Insertar código HTML en un botón usando <! [CDATA funcionó. Incluso se ganó la transición del botón al sitio.
Obtuve lo que quería, una forma de mostrar una lista de diferentes sitios e ir a ellos. Luego comencé a desarrollar un motor de generación de código XMLUI. Escribí una lista de los parámetros necesarios para un botón, puse un enlace a la imagen, el texto y un enlace al sitio allí.
El resultado fue un archivo de configuración de texto de este tipo:
[Section] Name=Facebook Url=menu://https://m.facebook.com/ Img=https://iclouddnsbypass.com/Icons/B5w8iLX.png
En él, creé una lista de sitios populares.
Luego, hice plantillas de página en las que se agregaron botones, todo se almacenó en la memoria de forma estática y se emitió a pedido sin acceder al disco.
Después de un par de días, corrigí todos los errores y el servidor estaba listo para un lanzamiento constante. La primera versión de iCloud DNS Bypass se lanzó el 25 de diciembre de 2014. Escribí la dirección del servidor DNS en w3bsit3-dns.com en el hilo sobre el desvío de iCloud, el mismo día que los moderadores del sitio me escribieron y sugirieron crear una rama separada.
A quién
le importa , aquí hay un
enlace al hilo del foro w3bsit3-dns.com .
Como resultado, todo se veía así:
Pero debido a las limitaciones de la interfaz en sí, solo fue posible seguir el enlace, y la posterior transición a sitios de terceros fue imposible. Como resultado, todos podrían usar solo la lista de sitios que agregué al servidor.
Solucionar problemas de omisión de DNS de iCloud
Unos días después del lanzamiento, mi amigo
Dybik lanzó un sitio con información del servidor. Creé un grupo en VK y hablé con los usuarios del servidor. Resultó que en el nuevo firmware de iOS, los enlaces de clic HTML ya no funcionan.
En ese momento, unos 500 usuarios únicos ya se habían conectado, y todas las revisiones me ayudaron a creer que estaba haciendo algo útil. Y siempre soñé con lanzar un gran proyecto. Estos pensamientos me dieron la fuerza para no rendirme. Comencé a buscar nuevamente los nombres de valores XMLUI, estaba seguro de que había muchos más comandos útiles.
Después de pasar otras 3-4 horas de búsquedas diligentes y rebotes, finalmente encontré una etiqueta útil
<linkRow y su parámetro accesorio = "revelación", haciendo que el botón sea una subcarpeta. Esto era justo lo que necesitaba, la lista funcionó en todos los iOS y adquirió un aspecto más nativo, ya que ya no había HTML.
El código del botón final fue así:
<linkRow accessory="disclosure" label=" " image="https://" shouldScaleHTMLPageToFit="true" url="http:// .buddyml" httpMethod="GET"/>
Comenzaron a enviarme enlaces útiles, que agregué al menú, y formaron una lista grande. También enviaron bloqueos, que agregué al menú, y todos podían probarlos.
También hice un motor de idiomas, con el reemplazo de textos, dependiendo del idioma del usuario. Invitó a todos a traducir y, con el tiempo, me enviaron traducciones de diferentes países. Ahora la interfaz del servidor ya se ha traducido a 50 idiomas, gracias a los voluntarios. También hice restricciones en la lista de sitios para el idioma, por ejemplo, el ruso se muestra para los sitios rusos, chino a chino. Se agregó un chat basado en tlk.io, pero luego creó su propio motor debido a los spammers.
Además, también encontré el parámetro shouldScaleHTMLPageToFit = "true" que trajo la vista del navegador al móvil donde se necesita. Y en el camino, encontré otro parámetro más importante esModalHTMLView = "true". Con él, pude expandir la página web a pantalla completa, la rotación de la pantalla y todos los clics en enlaces sin errores y restricciones funcionaron allí. Las cookies también funcionaron después de reiniciar, así que las usé para contar la cantidad de usuarios. Por primera vez en el mundo, se hizo posible usar un navegador completo sin pestañas en un dispositivo iOS bloqueado.
Además, a través del botón de carga de fotos HTML, todos pueden usar la cámara y encender la linterna de la misma manera. Agregué una lista de favoritos y podría agregarla en la interfaz. Había estaciones de radio en el menú, era posible abrir música, luego abrir otra pestaña con un botón especial, mientras que la anterior funcionaba, y resultó la multitarea.
Luego resultó que algunos usuarios no pueden conectarse al servidor. La razón de esto fue enrutadores o proveedores que reemplazaron todas las consultas DNS por las suyas. Y no fue posible reemplazar el dominio con mi servidor. Luego desarrollé un pequeño programa para Windows que lanza el servidor DNS incorporado, que ayuda a conectarse a la red local.
Aquí hay un video de YouTube del canal EverythingApplePro sobre el desvío de DNS de iCloud, donde puede ver cómo era la interfaz en ese momento.
Dos meses después, más de 200 mil dispositivos ya estaban conectados al servidor.
Aquí hay un video, en tiempo real puede ver las solicitudes en el servidor que estaban en ese momento
Pero para que Apple note que tienen un marcado en el marcado, fue necesario conectar otros 300 mil dispositivos.
Otra ola de estafadores
Dos meses después del lanzamiento en Internet, era imposible encontrar otra cosa sobre una solución alternativa que no fuera mi servidor. Esto puso fin al poder fraudulento que extorsionaba el dinero. Pero comenzó una ola de anuncios en eBay, comenzaron a vender "bypass de iCloud" por 30-50 USD. Los propietarios ingenuos y desesperados de los dispositivos bloqueados son fáciles de manipular, y los estafadores lo usaron.
Habiendo pagado por el "servicio de desbloqueo", los estafadores dieron instrucciones a los compradores sobre cómo conectarse a mi servidor gratuito. Muchos ni siquiera sospecharon que fueron robados. Estaba enojado y quería hacer algo para detenerlos.
Escribí una página de mensaje en todos los idiomas, para que cuando todos se conectan entiendan que el servidor es gratuito. Tal inscripción aún permanece en la interfaz del servidor. También se quejó de fraude en eBay, pero esta guerra fue interminable.
Recibí muchas cartas, deseché todo lo que encontraron sobre los hacks, publiqué en el servidor y probé todo. A veces resultó que iba al escritorio, y a veces todo estaba desbloqueado (funcionaba solo con dispositivos borrados a través del sitio, la interfaz se bloquea y funciona hasta que se reinicia).
Usando la información que me enviaron, resultó que hay muchas fuentes que ofrecen desbloquear dispositivos por dinero que realmente funcionó. Traté de descubrir cómo compartir con toda la comunidad para disipar los conceptos erróneos sobre los servicios pagos.
Los usuarios reciben un dispositivo bloqueado por los siguientes motivos:
- Olvidó su contraseña de ID de Apple y perdió su cheque
- Compró un dispositivo sin saber que está bloqueado
- Se convirtieron en víctimas de ransomware y perdieron el acceso a su ID de Apple
- Encontró el dispositivo en modo de pérdida
Ahora puedo decir con confianza que solo hay dos formas de desatarlo por completo:
- Suplantación de identidad, robo de contraseñas del propietario y eliminación de un dispositivo de su cuenta
- Después de recibir el cheque original, una llamada de soporte de Apple desata un dispositivo que no está en modo de pérdida
- Soldar un método de módem o resistencia para iPad desde Pasha4ur
El año pasado, los servicios de phishing se distribuyeron masivamente, y Apple en respuesta incluso eliminó el mensaje del propietario en la pantalla del dispositivo bloqueado. Pero esta no fue la razón de la ocurrencia generalizada de ataques de phishing. Hay fuentes que venden información de la cuenta de ID de Apple por el dinero que se utilizó para los ataques. Dejaron de trabajar solo en días festivos en el calendario chino. Lo más probable es que estos sean empleados de Apple en China que estén copiando información del área de administración de Apple Care. Decidí verificar la información recibida y todo resultó ser cierto. Había información de dirección, números de teléfono, preguntas de seguridad, sin contraseñas y sin respuestas. Luego traté de contactar a Apple para averiguar qué estaba pasando, y mis cartas fueron ignoradas con éxito. Así que cuide su IMEI / UDID lejos de miradas indiscretas, y en Apple ID es mejor no escribir información real.
Plan de emergencia
Sospeché que Apple alguna vez notaría una falla en el enlace HTTPS, y el servidor de omisión de DNS de iCloud de una vez dejaría de funcionar para todos los dispositivos. Explorar alternativas me ha llevado a crear el Portal Cautivo. Este mecanismo se usa en muchos hoteles, aeropuertos, cuando tiene que ingresar su número en el sitio, antes de conectarse a Internet.
La información sobre el portal cautivo también fue difícil de encontrar. Nadie ha intentado lanzar un portal de autorización a través de un servidor DNS. Después de varios días de investigación, logré lanzar con éxito mi propio portal cautivo. Todo funcionó como en un navegador normal, al hacer clic en todos los enlaces funcionó sin restricciones. En general, estaba listo para que Apple corrigiera el defecto, pero el hecho de que las cookies se borraran cuando se cerró el portal me confundió.
En ese momento, el método XMLUI funcionaba perfectamente, respondía correos electrónicos, estaba interesado en comunicarme con la gente. En YouTube, muchos grabaron un video sobre mi servidor, y todos compartieron información sobre las búsquedas de un rastreo completo.
Modo sin conexión, un administrador de archivos completo sin Internet
Ha pasado casi medio año desde que se inició el servidor y Apple no pensó en corregir la página de marcado. No recuerdo exactamente cuándo, pero estaba aburrido y comencé a tratar de leer el sistema de archivos iOS a través de XMLUI. Tuve éxito y pude abrir archivos del sistema de archivos, conociendo su ruta de antemano.
Tenía una idea, si suelta todos los archivos a través del programa desde la computadora en las carpetas de escritura en el dispositivo, puede crear un administrador de archivos. Entonces todavía era posible acceder a los archivos sin confirmación en un dispositivo bloqueado, ahora en iOS 10 esto ya no funcionará.
Hice un campo de entrada de código para desbloquear los botones de prueba donde estaba el administrador de archivos e invité a varios voluntarios a probar.
Fue posible cargar archivos de cualquier formato y abrirlos en el dispositivo. También fusioné todos los menús y submenús en un solo archivo, lo que permitió descargarlos al dispositivo 1 vez, y luego usarlos sin Internet. Quería compartir nuevas funciones con los usuarios del servidor lo más rápido posible. Primero, era necesario crear un programa que sincronizara la estructura del sistema de archivos con el servidor e identificara al usuario proporcionándole una lista de archivos desde su dispositivo.
Estaba muy involucrado y comencé a desarrollarme. Han pasado muchas horas y un reproductor de audio con una lista de reproducción y la capacidad de seleccionar una pista estaba lista. A la mañana siguiente, me llovieron correos electrónicos con mensajes de que el servidor estaba caído. Revisé todo, el servidor estaba funcionando, varios cientos de usuarios estaban en línea. Pero solo fueron los afortunados los que no abandonaron el servidor.
El 13 de mayo de 2015, los desarrolladores de Apple notaron una falla y arreglaron el texto del enlace de HTTP a HTTPS.
Durante la noche, todos los dispositivos dejaron de conectarse al servidor y se convirtieron en piezas de hierro inútiles con el logotipo de Apple. Y en un momento, todo el desarrollo del administrador de archivos se volvió inútil. Nadie se enteró de que iba a iniciar este modo. Ahora, para devolver este método, debe instalar un certificado autofirmado en el dispositivo para el dominio albert.apple.com, hasta ahora esto no ha sido posible. En el momento de corregir el error, debido a que el método anterior ya no funciona, se conectaron medio millón de dispositivos únicos.
Inmediatamente comencé a lanzar el Portal cautivo y a mover todo el menú a la opción web. La interfaz está basada en Framework7, la adapté al antiguo archivo de configuración del menú. El mismo día, el servidor se lanzó con un nuevo aspecto, en el que todavía se encuentra.En Facebook, tenía una página de omisión de DNS de iCloud donde publicaba solo noticias y actualizaciones del servidor. Ha pasado más de un año. Por alguna razón, a Apple no le gustó y un día (bien) vi el siguiente mensaje sin ninguna advertencia: más
tarde CloudFlare envió un correo electrónico con el mensaje de que alguien de la unidad de Apple solicitó la dirección IP real de mi sitio, ya que infringe sus derechos de autor derecho Aunque no entendí cuál fue la violación, me alegré de que todo esto fuera limitado. Durante todo el tiempo, Apple nunca ha tratado de contactar directamente y pedir eliminar lo que no les gusta.Tal ironía del destino, si mi esposa no hubiera dejado caer el teléfono, si no me hubiera distraído del proyecto principal para relajarme y hacer realidad mi idea, entonces el servidor iCloud DNS Bypass no existiría hoy.Ahora el número de usuarios únicos ha cruzado la frontera de 15 millones. 50-60 mil dispositivos únicos están conectados por día.La versión actual del servidor funciona en todos los iOS existentes actualmente. Y todavía no hay alternativas a la omisión de DNS de iCloud basada en el portal cautivo. El servidor ha estado trabajando las 24 horas desde su lanzamiento y las donaciones son suficientes para alquilar equipos. Hasta ahora, todas las conexiones HTTP son atendidas por un solo programa escrito en C ++.Aquí hay estadísticas de los países con los dispositivos Apple más bloqueados que se han conectado a iCloud DNS Bypass. Total actualmente 15,3 millones.
Y sí, puede probar el Portal cautivo en su dispositivo no bloqueado haciendo todo de acuerdo con las instrucciones del video de este artículo. Y también puede simplemente pasar por cualquier navegador a la página ui.iclouddnsbypass.comEpílogo
Espero no haberte aburrido con mi historia, y fue interesante para ti. No hay reglas en nuestro universo, y un proyecto en el que has estado trabajando durante un par de años puede cubrirse con una cuenca de cobre, y un pasatiempo en el que pasas dos semanas puede convertirse en un servicio que sirve a millones de personas. Deseo que no te aburras en tu trabajo y que a menudo te distraigas con lo que realmente te gusta.