No verão de 2014, eu e meus amigos fomos passear, e um evento histórico aconteceu. Ao gravar o vídeo, de repente, o iPhone 5C caiu das mãos da minha esposa e caiu no chão de concreto.
Naquele momento, pareceu-me uma situação triste. Mas esse foi precisamente o impulso para o lançamento do serviço, que agora atende a mais de 15 milhões de usuários.
O que o iPhone tem a ver com isso? Que tipo de serviço? Como tudo isso está conectado? Respostas sob o corte!
Prefácio
Neste artigo, quero compartilhar com você os eventos que começaram em 2014. Vou contar tudo como estava enquanto minha memória estiver fresca e também compartilhar informações que ainda não foram publicadas em nenhum lugar.
Reparação
Como qualquer pessoa que sentisse a amargura do vidro quebrado em seu dispositivo favorito, eu queria consertar isso o mais rápido possível. A tela em si não foi danificada e o reparo é apenas um substituto para o vidro da tela de toque. Um amigo recomendou o SC em Kiev e enviei um telefone para lá. Eles colaram novamente e enviaram de volta para mim. Mal podia esperar para receber o telefone pelo correio.
Assim que o recebi, outra decepção me esperava. A tela sensível ao toque foi substituída, mas havia manchas amarelas nas bordas da tela. No SC, eles me prometeram consertá-lo ou substituí-lo pelo original junto com a tela. Como ainda encontrei arranhões embaixo do vidro, decidi substituir completamente a tela.
Uma semana depois, recebi o telefone de volta, e o visor não era original. Mesmo na superfície em si, ficou claro que estava em ângulo com o corpo. E as cores eram mais escuras, o que distinguia claramente a tela da original. Acontece que as telas originais do iPhone são difíceis de encontrar. Decidi suportar essa situação e, em algum momento no futuro, mudar o iPhone para um modelo mais novo.
Alguns dias se passaram, eu lentamente me acostumei com a tela chinesa. Eu estava sentado em uma poltrona e o telefone escorregou do meu bolso. Ele caiu no chão de madeira, o copo quebrou novamente. O telefone com o vidro original caiu várias vezes, mas não bateu até o ataque de concreto. Mas os chineses, de vidro colado torto, quebraram na primeira tentativa.
A constatação de que eu não podia comprar o copo original me fez pensar em encontrar um doador. Comecei a procurar um iPhone que vende olx para peças. Descobriu-se que muitos têm problemas com a função iCloud Find My iPhone. Esses telefones não podem ser ativados e permanecem inativos até você inserir o ID da Apple do proprietário ou se o proprietário remover o telefone da conta.
Encontrei um doador, o iPhone 5C está em excelente estado, está trancado sob o operador e no iCloud. A tela se aproximou com sucesso do meu telefone e finalmente tudo se encaixou. Decidi manter o iPhone verde, por precaução, como doador. Finalmente, consegui me acalmar e esquecer esse problema.
O que vem a seguir?
Várias semanas se passaram, o iPhone 5C verde estava deitado em minha mesa sob o monitor. Mas de vez em quando eu me lembrava dele, porque por hábito não gosto de coisas ociosas. O telefone estava, portanto, ligado a um operador desconhecido e, mesmo com cacos de vidro, não havia sentido no iCloud. Mas o pensamento de que o telefone em teoria pode ser desbloqueado, ainda de uma maneira desconhecida, não me deixou.
doulCi
Em geral, comecei a pesquisar no google, ler os fóruns. Encontrei informações sobre o doulCi (o nome não é estranho, mas é quase o contrário do iCloud). Foi uma equipe de entusiastas que lançou um servidor para ignorar a FMI do firmware inicial do iOS 7. Eles lançaram o MITM e trocaram pacotes de um iPhone desbloqueado para um bloqueado. Em geral, naquele momento, a Apple não verificou a conformidade dos pacotes com o Serial / IMEI e o doulCi o usou com sucesso. Eles não funcionaram no servidor por um longo tempo, mas conseguiram desbloquear algo em torno de 70 mil dispositivos. Aqueles que conseguiram se conectar ao servidor receberam um dispositivo em que o cartão SIM não funcionou. Em seguida, um membro da equipe vazou a fonte para a Internet, e a Apple conseguiu consertar esse buraco. Nesse estágio, sua equipe se separou e todos foram de maneiras diferentes. O servidor deles não funcionou mais.
Claro que eu não sabia disso então. Eu fui ao site oficial e vi temporizadores lá, dizendo "Espere até as 16:00 na sexta-feira, então iniciaremos o servidor e o desbloquearemos gratuitamente". E havia em todos os lugares campos para entrar no IMEI e no registro. Então eu decidi esperar esta hora. Assim que chegou a hora, dei um alarme para não perder, mantive o cabo USB pronto. Chegou a hora, eu fui ao site deles e lá
tudo funciona um novo momento para iniciar o servidor. Eu tentei esperar ainda, e tudo acabou sendo uma tentação publicitária. Isso me incomodou bastante, mas eu não ia parar.
Servidor proxy
Mais tarde, começaram a aparecer notícias sobre servidores proxy, dizendo que, ao se conectar a eles, você pode acessar a página da web.
Na página que a Apple distribui
Ao clicar em "Ajuda na ativação", o usuário foi levado a uma página com texto. Mas os desenvolvedores da Apple perderam um pequeno detalhe, o link não levou ao HTTPS, mas a um endereço HTTP.
http://static.ips.apple.com/deviceservices/buddy/barney_activation_help_en_us.buddymlIsso tornou possível interceptar e substituir o tráfego, uma vez que não estava criptografado.
Os servidores estavam caindo constantemente, o melhor que encontrei foi o servidor niltpH. Mas ele trocava constantemente de portas, de modo que os usuários frequentemente visitavam seu site ou o servidor não suportava, e então ele removia a carga.
Eu sempre me perguntava por que fazer um proxy se você pode encaminhar consultas DNS?
Não haverá carga pesada e o servidor estará sempre online. Mas havia apenas servidores proxy.
Então uma onda de golpistas começou, eles começaram a proxy massivamente do servidor.
Mostrando uma página com pagamento por um rastreamento completo inexistente, muitas pessoas sofreram com esses serviços falsos. Servidores proxy permitiram que você tivesse controle total sobre o tráfego. Assim, bandidos roubaram senhas e cartões de crédito, e os usuários acreditavam que isso funcionaria, pois qualquer alteração no dispositivo era credível.
A Apple não fez nada para fazer a diferença, mas eu fiz. Como resultado de minhas ações adicionais, ninguém mais conseguiu encontrar os fraudadores do servidor proxy no mecanismo de pesquisa.
Primeiro servidor de desvio de DNS do iCloud
Resolvido, vou iniciar meu servidor. Numa noite de inverno em dezembro, comecei o desenvolvimento. Para implementar minha ideia, eu precisava de um servidor HTTP e um servidor DNS. Decidi escrever os dois serviços em C ++ usando o Visual Studio 2010. Trabalhando com soquetes diretamente byte a byte sem bibliotecas de terceiros.
O protocolo DNS não é complicado, para uma solicitação UDP, uma resposta, com a mesma estrutura de cada vez. Por algumas horas, escrevi um servidor DNS simples, que respondeu com um endereço IP estático em static.ips.apple.com e o restante que eu usei com o DNS do Google.
Então eu comecei a escrever um servidor HTTP. O primeiro passo foi simplesmente produzir uma página HTML. Ele foi carregado na memória quando o programa foi iniciado e, em seguida, foi emitido em pacotes prontos para todos que enviaram uma solicitação para a porta 80. Portanto, meu programa retornou uma página para todos que enviaram a solicitação, independentemente do host especificado. Tudo funcionou no navegador, mas ao registrar o DNS nas configurações do Wi-Fi iOS, clicando em "Ajuda na ativação", recebi um erro no telefone.
Após analisar o tráfego, verificou-se que a Apple usa arquivos XML, gerando uma interface remota para eles.
O código de exemplo pode ser visto no link de ajuda da ativação:
static.ips.apple.com/deviceservices/buddy/barney_activation_help_en_us.buddymlE aqui está a resposta do servidor solicitando a senha no 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>
Tendo estudado a fonte, você pode entender que o código possui JavaScript e funciona dentro das tags <! [CDATA [..]]>
E naquela época, os proxies existentes usavam uma única página com 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>
No telefone, você pode ver um site simples em vez do texto de ativação. Cookies funcionaram. Mas, ao clicar em qualquer link externo, todos os estilos se perderam e as transições subsequentes foram impossíveis. É assim que os servidores proxy funcionavam naquele momento.
Depois de algumas horas, eu tinha um servidor DNS e HTTP ativo, que retornava 1 página para qualquer solicitação. O XMLUI acabou sendo uma marcação com parâmetros desconhecidos que não foram encontrados em nenhum lugar. E agora não há documentação em nenhum lugar. A Apple o usa apenas dentro de seus produtos.
De fato, os elementos padrão do iOS são gerados pelo XMLUI, mesmo aqueles que funcionam offline. Listas, botões, ícones, escolha de data e hora, submenus, tudo isso é apenas o resultado da conversão do XML de um script semelhante em uma interface em tempo real.
A constatação de que muitas das interfaces no iOS foram feitas de uma maneira tão desajeitada me decepcionou um pouco. É quando você espera que tudo já tenha sido feito da melhor maneira possível, e acontece que há uma camada na camada.
Então percebi que, em teoria, se você conhece o layout da interface, pode gerar uma interface iOS nativa muito confortável com uma lista de ícones e links. Como configurações no iOS. E substitua-o pela caixa de diálogo de ativação completamente.
Tudo o que entendi a partir do código já salvo é que existe uma determinada tabela com a capacidade de adicionar muitos rodapés de <seção, que podem se referir a outros arquivos XMLUI. É bem possível criar seu servidor XMLUI com algumas informações. Mas eu queria obter exatamente a lista dos sites e poder acessar o Google, por exemplo.
Como criar uma interface de marcação sem conhecer os comandos?
A primeira coisa que me ocorreu foi que, como o iOS gera comandos, ele compara as sequências de parâmetros XML, portanto, elas devem ser armazenadas em algum lugar do firmware. Idealmente, você encontraria um arquivo com uma lista de comandos que você pode tentar adicionar ao código XMLUI, mas não, isso não aconteceu.
Naquela época, o iPhone 4 já estava completamente hackeado. Lá, no gerenciador de inicialização, você pode inicializar e obter acesso total ao sistema de arquivos, não importa se há uma senha do iOS ou não.
Encontrei o firmware do iOS 7 baixado do iPhone 4 e comecei a selecioná-lo. Compilei uma lista de palavras famosas desses arquivos XMLUI que coletei e comecei a procurar palavra por palavra por todos os arquivos de firmware. À primeira vista, um exercício inútil, é comparável a encontrar uma agulha no palheiro, mas por alguma razão eu tinha certeza de que encontraria algo. Mais de uma hora se passou, não encontrei nada, mas o arquivo dyld_shared_cache_armv7 chamou minha atenção. Ele pesava até 300 MB, enquanto o firmware inteiro pesava cerca de 1 GB.
Acabou sendo um "pacote" de bibliotecas dinâmicas. Para não sobrecarregar o sistema de arquivos, a Apple empacota todas as bibliotecas dinâmicas de todos os programas do sistema em um arquivo. Usando as ferramentas de desenvolvedor da Apple, descompactei este arquivo e recebi um grande número de arquivos. Comecei a procurar novamente em seus dados por palavras da minha lista, tentei combiná-las e selecioná-las. Comecei a procurar grafias semelhantes em estilo - algumas palavras, a primeira com uma letra minúscula, a outra com maiúscula, sem espaços ou sublinhado.
Após inúmeras tentativas, consegui encontrar a palavra htmlButtonRow. Se você inseri-lo no código, obtém um erro, de alguma forma influenciado e reconhecido. O próximo passo foi a seleção de um lugar, onde colocá-lo?
Finalmente, o código funcionou e eu recebi a barra de menu cobiçada:
<tableView> <section> <htmlButtonRow name=" "> </htmlButtonRow> </section> </tableView>
Apenas uma linha foi exibida e o texto, quando pressionado, nada aconteceu. Mas o nome da seção htmlButtonRow estava falando sobre HTML, o que significa que você provavelmente pode adicionar o código da página.
Inserir código HTML em um botão usando <! [CDATA funcionou. A Even ganhou a transição do botão para o site.
Consegui o que queria, uma maneira de exibir uma lista de sites diferentes e acessá-los. Então comecei a desenvolver um mecanismo de geração de código XMLUI. Eu escrevi uma lista dos parâmetros necessários para um botão, coloque um link para a imagem, texto e um link para o site lá.
O resultado foi um arquivo de configuração de texto desse tipo:
[Section] Name=Facebook Url=menu://https://m.facebook.com/ Img=https://iclouddnsbypass.com/Icons/B5w8iLX.png
Nele, criei uma lista de sites populares.
Em seguida, criei modelos de página nos quais botões foram adicionados, tudo foi armazenado estaticamente na memória e emitido sob demanda sem acessar o disco.
Depois de alguns dias, corrigi todos os erros e o servidor estava pronto para um lançamento constante. A primeira versão do iCloud DNS Bypass foi lançada em 25 de dezembro de 2014. Eu escrevi o endereço do servidor DNS em w3bsit3-dns.com no tópico sobre o desvio do iCloud, no mesmo dia em que os moderadores do site me escreveram e sugeri a criação de uma ramificação separada. Quem se
importa , aqui está um
link para o tópico do fórum w3bsit3-dns.com .
Como resultado, tudo ficou assim:
Porém, devido às limitações da própria interface, só foi possível seguir o link, e a transição subsequente para sites de terceiros foi impossível. Como resultado, todos poderiam usar apenas a lista de sites que eu adicionei ao servidor.
Solucionar problemas de desvio de DNS do iCloud
Alguns dias após o lançamento, meu amigo
Dybik lançou um site com informações do servidor. Criei um grupo no VK e conversei com os usuários do servidor. No novo firmware do iOS, os links de clique em HTML não funcionam mais.
Naquela época, cerca de 500 usuários únicos já haviam se conectado e todas as análises me ajudaram a acreditar que eu estava fazendo algo útil. E sempre sonhei em lançar um grande projeto. Esses pensamentos me deram força para não desistir. Comecei a procurar novamente nomes de valor XMLUI, tinha certeza de que havia muitos outros comandos úteis.
Depois de passar mais 3-4 horas de pesquisas e rebotes diligentes, finalmente encontrei uma tag útil
<linkRow e seu parâmetro acessório = "divulgação", transformando o botão em uma subpasta. Era exatamente isso que você precisava, a lista funcionava em todos os iOS e assumia uma aparência mais nativa, já que não havia mais HTML.
O código do botão final era assim:
<linkRow accessory="disclosure" label=" " image="https://" shouldScaleHTMLPageToFit="true" url="http:// .buddyml" httpMethod="GET"/>
Eles começaram a me enviar links úteis, que eu adicionei ao menu, e formaram uma grande lista. Eles também enviaram falhas, que adicionei ao menu, e todos puderam experimentá-las.
Também fiz um mecanismo de linguagem, com a substituição de textos, dependendo do idioma do usuário. Ele convidou todos a traduzir e, com o tempo, eles me enviaram traduções de diferentes países. Agora, a interface do servidor já foi traduzida para 50 idiomas, graças a voluntários. Também fiz restrições na lista de sites para o idioma, por exemplo, o russo é exibido para sites russos, chinês para chinês. Adicionado um bate-papo baseado no tlk.io, mas mais tarde ele criou seu próprio mecanismo devido a spammers.
Além disso, também encontrei o parâmetro shouldScaleHTMLPageToFit = "true", que trouxe a visualização do navegador para o celular, onde é necessário. E ao longo do caminho, encontrei outro parâmetro mais importante éModalHTMLView = "true". Com isso, eu fui capaz de expandir a página da web para tela cheia, a rotação da tela e todos os cliques nos links sem bugs e restrições trabalhadas lá. Os cookies também funcionaram após a reinicialização, então eu os usei para contar o número de usuários. Pela primeira vez no mundo, foi possível usar um navegador completo sem guias em um dispositivo iOS bloqueado.
Além disso, através do botão de upload de fotos em HTML, todos podem usar a câmera e acender a lanterna da mesma maneira. Adicionei uma lista de favoritos e você pode adicioná-la na interface. Havia estações de rádio no menu, era possível abrir músicas e abrir outra guia com um botão especial, enquanto a anterior funcionava e a multitarefa era executada.
Acontece que alguns usuários não podem se conectar ao servidor. O motivo disso foi roteadores ou provedores que substituíram todas as consultas DNS por suas próprias. E não foi possível substituir o domínio pelo meu servidor. Em seguida, desenvolvi um pequeno programa para Windows que inicia o servidor DNS interno, o que ajuda a conectar-se à rede local.
Aqui está um vídeo do YouTube no canal EverythingApplePro sobre o iCloud DNS Bypass, onde você pode assistir como era a interface naquele momento.
Dois meses depois, mais de 200 mil dispositivos já estavam conectados ao servidor.
Aqui está um vídeo, em tempo real, você pode ver as solicitações no servidor que estavam naquele momento
Mas, para a Apple perceber que eles têm uma marcação na marcação, foi necessário conectar outros 300 mil dispositivos.
Outra onda de golpistas
Dois meses após o lançamento na Internet, era impossível encontrar mais alguma solução alternativa além do meu servidor. Isso acabou com o proxy fraudulento que extorquia dinheiro. Mas uma onda de anúncios no eBay começou e eles começaram a vender o "iCloud bypass" por 30 a 50 dólares. Os proprietários ingênuos e desesperados dos dispositivos bloqueados são fáceis de manipular e os golpistas o usavam.
Depois de pagar pelo "serviço de desbloqueio", os golpistas deram instruções aos compradores sobre como se conectar ao meu servidor gratuito. Muitos nem suspeitaram que foram roubados. Eu estava com raiva e queria fazer algo para detê-los.
Escrevi uma página de mensagem em todos os idiomas, para que, quando todos se conectem, entendam que o servidor é gratuito. Essa inscrição ainda permanece na interface do servidor. Ele também reclamou de fraude no eBay, mas essa guerra foi interminável.
Recebi muitas cartas e joguei fora tudo o que encontraram sobre hacks, publiquei no servidor e tentei de tudo. Às vezes, acabava indo para a área de trabalho e, às vezes, tudo era desbloqueado (funcionava apenas com dispositivos limpos pelo site, a interface o deixava em condições de funcionamento até a reinicialização).
Usando as informações que me foram enviadas, descobriu-se que existem muitas fontes que oferecem desbloquear dispositivos por dinheiro que realmente funcionou. Tentei descobrir como compartilhar com toda a comunidade para dissipar os equívocos sobre serviços pagos.
Os usuários recebem um dispositivo bloqueado pelos seguintes motivos:
- Esqueceu sua senha de ID Apple e perdeu seu cheque
- Comprou um dispositivo sem saber que ele está bloqueado
- Eles se tornaram vítimas de ransomware e perderam o acesso ao seu ID Apple
- Encontrou o dispositivo no modo de perda
Agora posso dizer com confiança que existem apenas duas maneiras de desamarrar completamente:
- Phishing, roubo de senhas do proprietário e remoção de um dispositivo da conta
- Após receber o cheque original, uma chamada de suporte da Apple desata um dispositivo que não está no modo de perda
- Soldando um método de modem ou resistor para iPad a partir de Pasha4ur
No ano passado, os serviços de phishing foram massivamente distribuídos, e a Apple, em resposta, até removeu a mensagem do proprietário na tela do dispositivo bloqueado. Mas esse não foi o motivo da ocorrência generalizada de ataques de phishing. Existem fontes que vendem informações da conta Apple ID pelo dinheiro que foi usado para ataques. Eles pararam de trabalhar apenas nos feriados do calendário chinês. Provavelmente, esses são funcionários da Apple na China que estão copiando informações da área administrativa da Apple Care. Decidi verificar as informações recebidas e tudo acabou sendo verdade. Havia informações de endereço, números de telefone, perguntas de segurança, nenhuma senha e nenhuma resposta. Depois tentei entrar em contato com a Apple para descobrir o que estava acontecendo e minhas cartas foram ignoradas com sucesso. Portanto, cuide do seu IMEI / UDID longe de olhares indiscretos, e no Apple ID é melhor não escrever informações reais.
Plano de emergência
Eu suspeitava que a Apple algum dia notaria uma falha no link HTTPS, e o servidor iCloud DNS Bypass de uma só vez deixaria de funcionar para todos os dispositivos. Explorar alternativas me levou a criar o Portal Cativo. Esse mecanismo é usado em muitos hotéis, aeroportos, quando você precisa inserir seu número no site, antes de conectar-se à Internet.
Informações sobre o Portal Cativo também foram difíceis de encontrar. Ninguém nunca tentou iniciar um portal de autorização por meio de um servidor DNS. Após vários dias de pesquisa, consegui lançar meu próprio Portal Cativo. Tudo funcionava como em um navegador normal, clicando em todos os links funcionavam sem restrições. Em geral, eu estava pronto para a Apple corrigir o defeito, mas o fato de os Cookies terem sido apagados quando o portal foi fechado me confundiu.
Naquela época, o método XMLUI funcionava perfeitamente, eu respondia e-mails, estava interessado em me comunicar com as pessoas. No YouTube, muitos gravaram um vídeo sobre o meu servidor e todos compartilharam informações sobre pesquisas para um rastreamento completo.
Modo offline, um gerenciador de arquivos completo sem a Internet
Quase meio ano se passou desde que o servidor foi iniciado e a Apple não pensou em corrigir a página de marcação. Não me lembro exatamente quando, mas estava entediado e comecei a tentar ler o sistema de arquivos do iOS por meio do XMLUI. Consegui e consegui abrir arquivos do sistema de arquivos, conhecendo o caminho deles com antecedência.
Tive uma ideia: se você soltar todos os arquivos do programa do computador para as pastas graváveis do dispositivo, poderá criar um gerenciador de arquivos. Ainda era possível acessar arquivos sem confirmação em um dispositivo bloqueado, agora no iOS 10 isso não funcionará mais.
Criei um campo de entrada de código para desbloquear os botões de teste onde estava o gerenciador de arquivos e convidei vários voluntários para testar.
Foi possível fazer upload de arquivos de qualquer formato e abrir no dispositivo. Também mesclei todos os menus e submenus em um arquivo, o que tornou possível baixá-los para o dispositivo uma vez e depois usá-los sem a Internet. Eu queria compartilhar novos recursos com os usuários do servidor o mais rápido possível. Primeiro, era necessário criar um programa que sincronizasse a estrutura do sistema de arquivos com o servidor e identificasse o usuário, fornecendo a ele uma lista de arquivos de seu dispositivo.
Eu estava muito envolvido e comecei a me desenvolver. Muitas horas se passaram e um reprodutor de áudio com uma lista de reprodução e a capacidade de selecionar uma faixa estavam prontos. Na manhã seguinte, choveram e-mails sobre mim com mensagens de que o servidor estava inoperante. Eu verifiquei tudo, o servidor estava funcionando, várias centenas de usuários estavam online. Mas foram apenas os sortudos que não deixaram o servidor.
Em 13 de maio de 2015, os desenvolvedores da Apple notaram uma falha e corrigiram o texto do link de HTTP para HTTPS.
Durante a noite, todos os dispositivos pararam de se conectar ao servidor e se transformaram em pedaços de ferro inúteis com o logotipo da apple. E, a certa altura, todo o desenvolvimento do gerenciador de arquivos se tornou inútil. Ninguém nunca descobriu que eu estava indo para iniciar este modo. Agora, para retornar esse método, você precisa instalar um certificado autoassinado no dispositivo para o domínio albert.apple.com, até agora isso não foi possível. No momento da correção do bug, devido ao qual o método antigo não funciona mais, meio milhão de dispositivos únicos estavam conectados.
Comecei imediatamente a iniciar o Portal Cativo e a mover o menu inteiro para a opção da web. A interface é baseada no Framework7, eu a adaptei ao antigo arquivo de configuração de menu. No mesmo dia, o servidor foi lançado em uma nova aparência, na qual ainda está localizado.No Facebook, eu tinha uma página de desvio de DNS do iCloud, onde publiquei apenas notícias e atualizações de servidor. Mais de um ano se passou. Por alguma razão, a Apple não gostou e um dia (ótimo) vi a seguinte mensagem sem aviso:
Mais tarde, o CloudFlare enviou um e-mail com uma mensagem informando que alguém da unidade da Apple solicitou o endereço IP real do meu site, pois isso viola os direitos autorais. certo. Embora eu não entendesse qual foi a violação, fiquei feliz por tudo isso ser limitado. Durante todo o tempo, a Apple nunca tentou entrar em contato diretamente e pedir para excluir o que não gosta.Uma ironia do destino, se minha esposa não tivesse desligado o telefone, se eu não tivesse me distraído do projeto principal para relaxar e realizar minha ideia, o servidor de desvio de DNS do iCloud não existiria hoje.Agora, o número de usuários únicos ultrapassou a fronteira de 15 milhões, 50 a 60 mil dispositivos únicos são conectados por dia.A versão atual do servidor funciona em todos os iOS existentes no momento. E ainda não há alternativas para o desvio de DNS do iCloud com base no Captive Portal. O servidor trabalha ininterruptamente desde o lançamento e as doações são suficientes para alugar equipamentos. Até agora, todas as conexões HTTP são atendidas por um único programa escrito em C ++.Aqui estão estatísticas de países com os dispositivos Apple mais bloqueados que se conectaram ao iCloud DNS Bypass. Total atualmente de 15,3 milhões.
E sim, você pode tentar o Portal Cativo no seu dispositivo não bloqueado, fazendo tudo conforme as instruções no vídeo deste artigo. E você também pode simplesmente acessar qualquer navegador da página ui.iclouddnsbypass.comPosfácio
Espero não ter aborrecido você com a minha história, e foi interessante para você. Não há regras em nosso universo, e um projeto no qual você trabalha há alguns anos pode ser coberto com uma bacia de cobre, e um hobby pelo qual você passa duas semanas pode se transformar em um serviço que atende muitos milhões de pessoas. Desejo que você não fique entediado com o seu trabalho e muitas vezes se distraia com o que realmente gosta.