Agora também é um aplicativo desktop para técnicos no Windows e Linux. A versão inicial detecta o iPhone por USB, consulta bateria quando o iOS disponibiliza esses dados, executa diagnóstico profundo por SSH autorizado e exporta um relatório sem identificadores pessoais.
Eu transformei o procedimento documentado neste repositório em uma estação de atendimento simples:
- conecto e autorizo o iPhone;
- identifico versão, modelo técnico e condição estimada da bateria;
- se o aparelho tiver jailbreak e OpenSSH, inicio uma leitura profunda somente pelo cabo;
- reviso o achado antes de qualquer alteração;
- quando o caso corresponde exatamente ao cache conhecido, autorizo a limpeza com uma frase explícita;
- exporto um relatório JSON anonimizado.
O aplicativo não oferece terminal remoto nem explorador de arquivos. A rotina de exclusão tem caminho e estrutura esperada codificados no backend, refaz a validação imediatamente antes de alterar e recusa qualquer conteúdo diferente.
Não é necessário baixar o código-fonte. Os instaladores prontos estão na página Releases do projeto.
Baixe o arquivo iOS.Storage.Forensics_0.3.0_amd64.deb. Depois abra um terminal
na pasta em que ele foi salvo e execute:
cd ~/Downloads
sudo apt install ./iOS.Storage.Forensics_0.3.0_amd64.debO apt instalará também as dependências declaradas pelo aplicativo. Concluída
a instalação, procure por iOS Storage Forensics no menu de aplicativos.
Para remover futuramente:
sudo apt remove i-os-storage-forensicsSe a distribuição não aceitar pacotes .deb, baixe
iOS.Storage.Forensics_0.3.0_amd64.AppImage. Na pasta do download, execute:
chmod +x iOS.Storage.Forensics_0.3.0_amd64.AppImage
./iOS.Storage.Forensics_0.3.0_amd64.AppImageA AppImage não é instalada no sistema: ela abre diretamente. Para que o aplicativo consiga conversar com o iPhone, distribuições baseadas em Debian precisam destas ferramentas:
sudo apt update
sudo apt install libimobiledevice-utils libusbmuxd-tools usbmuxdBaixe iOS.Storage.Forensics_0.3.0_x64-setup.exe e abra o arquivo com dois
cliques. Aceite a confirmação do Windows e siga o assistente de instalação. O
arquivo .msi disponível na mesma página é uma alternativa destinada a
instalação administrativa.
Se o iPhone não for reconhecido, instale o aplicativo Dispositivos Apple ou o iTunes para disponibilizar os drivers USB da Apple. Consulte também os detalhes e limites no Windows e as informações técnicas do Linux.
Os pacotes .exe, .msi, .deb e .AppImage são compilados e testados
automaticamente pelo GitHub Actions a cada versão publicada.
O aplicativo reconhece o aparelho mesmo sem jailbreak e cruza modelo, chip e versão do iOS com uma matriz auditável. Consulte a matriz e os limites do acesso avançado.
npm ci
npm run devNo navegador, o aplicativo abre uma demonstração local e não acessa aparelho algum. Para executar o desktop completo:
npm run tauri devO código usa React e TypeScript na interface e Rust com Tauri no backend. Os scripts originais continuam abaixo porque são uma referência pequena e fácil de auditar.
Neste repositório eu documento como investiguei um crescimento anormal de Dados do Sistema no meu iPhone usando Linux, conexão USB e acesso SSH autorizado por mim.
Meu objetivo não é oferecer um “limpador mágico”. Eu quero mostrar como medi o armazenamento, localizei a causa real, validei o alvo e só então removi um cache comprovadamente descartado.
Eu realizei a investigação no meu próprio aparelho com o apoio do Codex, da OpenAI. Mantive o controle físico do iPhone e autorizei cada etapa necessária. O Codex conduziu as medições pelo terminal, ajudou a delimitar o alvo, executou a limpeza autorizada e validou comigo o resultado.
Neste relato eu separo os fatos que observamos das recomendações gerais. Também retirei todas as credenciais e identificações pessoais da sessão original.
| Etapa | Antes | Depois |
|---|---|---|
| Espaço livre | aproximadamente 577 MB | aproximadamente 16 GB |
~/Library/Caches do usuário móvel |
aproximadamente 17 GB | aproximadamente 1,1 GB |
| Cache descartado identificado | aproximadamente 16 GB | 0 |
Eu encontrei 242 cópias órfãs de
com.google.photos.mdd.downloads dentro da área
com.apple.CacheDeleteAppContainerCaches.discardedCaches. Os arquivos estavam
marcados como imutáveis, impedindo que o processo normal de limpeza do iOS os
excluísse.
Eu não removi fotos, conversas nem pastas de dados ativas de aplicativos.
- iPhone XR;
- iOS 18.7;
- jailbreak rootless com Dopamine;
- OpenSSH do Procursus;
- Linux com
libimobiledevice,iproxye OpenSSH Client.
Este repositório registra o meu caso específico. Eu não presumo que a mesma causa exista em outros aparelhos: caminhos, permissões e comportamento podem mudar entre versões do iOS. Por isso, recomendo refazer todo o diagnóstico antes de tentar a limpeza em outro dispositivo.
No meu computador Linux, executei:
iproxy 2222 22Em outro terminal, conectei ao iPhone:
ssh -p 2222 mobile@127.0.0.1Eu usei uma senha temporária forte e diferente da senha do iPhone e da conta Apple. Também mantive o SSH restrito ao encaminhamento local por USB.
No iPhone, pela sessão SSH, executei:
df -h
sudo du -x -h -d 1 /private/var/mobile 2>/dev/null | sort -h
sudo du -x -h -d 1 /private/var/mobile/Library 2>/dev/null | sort -h
sudo du -x -h -d 1 /private/var/mobile/Library/Caches 2>/dev/null | sort -hEsse encadeamento me mostrou:
/private/var/mobile ~35 GB
└── Library ~21 GB
└── Caches ~17 GB
└── com.apple.cache_delete ~16 GB
└── ...discardedCaches ~16 GB
Antes da limpeza, eu contei as pastas descartadas e inspecionei seus nomes internos. Todas apontavam para o mesmo cache do Google Fotos:
target='/private/var/mobile/Library/Caches/com.apple.cache_delete/com.apple.CacheDeleteAppContainerCaches.discardedCaches'
sudo find "$target" -mindepth 1 -maxdepth 1 -type d | wc -l
sudo find "$target" -mindepth 2 -maxdepth 2 -type d -printEu confirmei que o Google Fotos já não estava instalado. Concluí, então, que eram caches órfãos que o próprio iOS havia movido para sua área de descarte, mas não conseguira eliminar.
Eu transformei o procedimento no script cleanup-discarded-google-photos-cache.sh. Ele repete todas as verificações e, sem argumentos, opera em modo de simulação, sem alterar nada:
sudo /var/jb/bin/sh scripts/cleanup-discarded-google-photos-cache.shPara efetivar a limpeza, eu preciso passar --apply e confirmar o texto
solicitado:
sudo /var/jb/bin/sh scripts/cleanup-discarded-google-photos-cache.sh --applyNo meu procedimento, o script:
- confere o caminho absoluto;
- recusa conteúdos que não correspondam ao cache documentado;
- mostra quantidade e tamanho antes da alteração;
- remove as marcas
uchgeschgsomente nessa árvore; - apaga o conteúdo, preservando o diretório de descarte;
- mede novamente o tamanho e o espaço livre.
Eu uso o script inspect-ios-storage.sh para produzir um mapa das principais áreas do armazenamento sem modificar arquivos:
sudo /var/jb/bin/sh scripts/inspect-ios-storage.shEu também encontrei um arquivo esparso com aproximadamente 1,5 GB de uso físico em:
/private/var/root/Library/Caches/com.apple.coresymbolicationd/<build-do-iOS>
Identifiquei esse arquivo como um cache reconstruível de simbolização. Eu não automatizei sua remoção neste repositório porque ele não fazia parte da falha principal e pode voltar a ser criado pelo sistema.
/private/var/MobileAsset;- bancos de dados do sistema;
- Keychain, CloudKit ou índices do Spotlight;
- contêineres ativos de aplicativos;
- o diretório inteiro
/private/var/mobile/Library/Caches; - qualquer caminho que não tenha sido previamente medido e identificado.
Eu não tento zerar “Dados do Sistema”. Essa categoria também inclui vozes da Siri, dicionários, modelos de linguagem, índices, logs e caches legítimos.
Após o diagnóstico, eu:
- alterei a senha do usuário
mobilepara uma senha privada; - removi o OpenSSH Server quando não precisei mais dele;
- encerrei o
iproxy; - reiniciei o espaço de usuário;
- aguardei o iOS recalcular a tela de armazenamento.
Eu publico este material com finalidade educacional porque o aparelho analisado é meu. Não recomendo executar o procedimento em aparelhos de terceiros sem autorização expressa. Uma exclusão incorreta pode causar perda de dados ou tornar o sistema instável; por isso, eu mantenho o modo de simulação como padrão e recomendo fazer backup antes de qualquer alteração.