Solicitações maliciosas e drainers

Fonte mestra EN · P03-L05 · needs_review

Apenas estudo offline/somente leitura. Nunca forneça segredos, senhas ou códigos de autenticação. Sem conexão de carteira, aprovação real, revogação em tempo real, assinatura de transação, transferência, fundos ou operação. Recursos visuais são apenas especificações.

Solicitação do tipo drainer é avaliada pela capacidade que pede, não por legenda tranquilizadora. Evidência de alcance perigoso pode justificar parar enquanto execução e intenção humana permanecem não resolvidas.

Começar pela finalidade declarada do aluno

Ação pretendida nos dados do exercício é ler saldo público, sem necessidade de autorização. R1, mesmo assim, pede permissão de gasto; R2 solicita transferência direta; R3 omite efeitos completamente. Compare capacidades à finalidade declarada. Não é teste de página usar palavras alarmantes: é teste de efeitos solicitados serem justificados e compreendidos.

Ler autoridade efetiva

Permissões ERC-20 nomeiam destinatário de permissão de gasto e quantidade [ERC20]. Mensagens em formato permit podem autorizar permissões sob regras aplicáveis de aprovação assinada [PERMIT]. Instruções de transação podem, em vez disso, solicitar movimento diretamente [ETH_TX]. Nenhuma dessas formas identifica automaticamente pessoa maliciosa. Aplicação legítima pode usar aprovações, e solicitação de aprovação sozinha não prova intenção maliciosa.

Dados do exercício tornam divergência explícita: «ver saldo» versus permissão para 1000 unidades. Isso sustenta divergência de capacidade/finalidade sob seus pressupostos. Não fornece assinatura, mensagem consumida ou resultado de transferência. Relate «solicitação excede finalidade estipulada de somente leitura», não «usuário teve ativos drenados».

Tratar opacidade como não resolvida

Resumo opaco de R3 não pode ser avaliado como inofensivo porque legenda diz verificar. Efeitos UNKNOWN são motivo para parar neste ensaio; não convite para assinar e observar o que acontece. Simulação ou resumo decodificado, se fornecido, teria fonte, método, contexto de estado e cobertura. Dados do exercício não fabricam simulação bem-sucedida de segurança.

Temporizador de R4 cria pressão, mas não fornece necessidade de autorização. Linguagem de contagem regressiva não altera nenhuma evidência ausente. Registre-a como parte da solicitação mantendo identidade e motivo do operador não resolvidos.

Preservar registro seguro

Escreva tabela higienizada de capacidade solicitada. Mantenha IDs exatos dos dados do exercício, finalidade pretendida, autoridade solicitada, divergência e evidência ausente de resultado. OBSERVED é resumo da solicitação, INFERRED é divergência de alcance, UNKNOWN é execução e identidade do operador, e INSUFFICIENT EVIDENCE aplica-se a culpa de humano nomeado ou perda confirmada de ativos. Nenhum malware é gerado, baixado ou executado.

• Capacidade: efeito que autorização poderia permitir.
• Divergência de finalidade: alcance que excede intenção estipulada do usuário.
• Solicitação opaca: efeitos insuficientemente decodificados.
• Padrão do tipo drainer: comportamento descritivo de solicitação, não atribuição verificada de pessoa.

ILLUSTRATIVE cartões offline de solicitações; sem bytes assináveis. Finalidade pretendida: ver saldo público. R1 legenda «verificar carteira», solicitação em formato de permissão TOKEN-S/OWNER-A/SPENDER-B para 1000 unidades inteiras do exercício. R2 legenda «resgatar», solicitação de transferência direta de 7 unidades SIM para SIM-C. R3 legenda «verificar», efeitos UNKNOWN. R4 temporizador «aja agora». Nenhum registro de autorização ou execução.

Cronologia de solicitação de transação com intenção no início e R1/R2/R3 como cartões separados de capacidade. Marcar divergência/efeitos desconhecidos e depois decisão offline STOP. Manter faixa de resultado executado vazia, sem grafo fabricado de perda.

Campos estipulados de solicitação e divergências inferidas de finalidade/capacidade.

Execução real de malware, produção de assinatura, furto, intenção humana maliciosa ou identidade do operador.

• Assinar para descobrir efeitos.
• Chamar toda aprovação de maliciosa.
• Tratar pressão/legenda como justificativa técnica.
• Equiparar solicitação arriscada a perda observada.

Para R1–R4, registre finalidade pretendida, efeito solicitado, divergência, estado de evidência e entrada ausente. Escreva decisão segura offline para R3 e reescreva «atacante furtou sete unidades» usando apenas esses cartões.

Entregue tabela e conclusão delimitada usando apenas material offline fornecido. Distribuição editorial: estudo 12 min, exercício 8 min, correção/questionário 10 min.

• Nomear intenção.
• Ler alcance independentemente da legenda.
• Pausar se efeitos não resolvidos.
• Preservar solicitação higienizada, não segredo/assinatura.
• Separar capacidade arriscada e resultado efetivo.

Avaliação de solicitação compara finalidade pretendida a efeitos solicitados. Alcance sem respaldo ou efeitos desconhecidos podem justificar parar sem inventar execução, perdas ou atribuição humana.

• Identificar solicitação nociva em exemplo higienizado de transação
• Comparar efeitos higienizados com finalidade alegada.
• Identificar alcance inseguro sem afirmar identidade de atacante ou perda executada.

P03-L06 após revisar pré-requisitos e correção.

NONE no catálogo autoritativo. Dados offline fornecidos bastam; não exige compra de produto nem operação de carteira.

• [ERC20] Padrão de token ERC-20 — approve, allowance e transferFrom para interfaces conformes.
• [PERMIT] ERC-2612 aprovações assinadas — Autorização de permissão por permit com owner, spender, value, nonce e deadline.
• [ETH_TX] Transações Ethereum — Instruções assinadas e inclusão distinta de envio.

Documentação explica mecanismos. Registros históricos mantêm classe de fonte declarada. Inspeção de fonte não é aceitação editorial independente.