A triagem de malware com LLM da Databricks elimina um ponto cego em binários, mas o contexto ainda determina o veredito

A Databricks divulgou um estudo sobre triagem de malware com LLM que reduziu as falhas de detecção de 50% para 4% em 70 testes com modelos econômicos. A melhoria não veio do retreinamento desses modelos nem de sua substituição por alternativas mais caras. Veio da injeção de conhecimento estruturado sobre segurança de binários antes de cada modelo tomar sua decisão.

O resultado desafia uma premissa comum por trás da varredura de pacotes assistida por IA. Mais inteligência do modelo nem sempre é a resposta mais direta para avaliações de segurança fracas. Um modelo menor pode reduzir grande parte dessa lacuna quando a análise estática fornece as evidências e a estrutura de interpretação adequadas.

A constatação é importante porque pacotes npm maliciosos nem sempre expõem seu comportamento por meio de JavaScript legível. Alguns empacotam executáveis compilados por trás de arquivos-fonte limpos, metadados confiáveis e scripts de instalação familiares. Esse contexto ao redor pode levar um modelo sem assistência a emitir um veredito confiante, mas inseguro.

O experimento completo, publicado em 16 de outubro de 2026, testou diretamente essa falha. A Databricks avaliou nove modelos de sete provedores usando payloads nativos elaborados para Node.js. Em seguida, comparou seus julgamentos com e sem perfis de capacidade, playbooks estruturados criados a partir de evidências estáticas.

A principal disputa, portanto, não é entre um modelo e outro. É entre o raciocínio de LLM sem assistência e o raciocínio de LLM fundamentado em evidências específicas do domínio. A Databricks constatou que essa distinção pode determinar se um ladrão de credenciais oculto será bloqueado ou recomendado para uma lista de permissões.

A triagem de malware com LLM da Databricks muda o contexto da decisão

A Databricks não ensinou seus modelos a fazer engenharia reversa de binários; ela mudou o que eles sabiam antes de avaliá-los.

O pipeline da empresa começa com ferramentas determinísticas de segurança. O YARA examina o arquivo do pacote em busca de padrões conhecidos. O Semgrep analisa o código-fonte JavaScript, enquanto os metadados npm fornecem informações sobre o pacote e sua finalidade declarada.

Um módulo separado de análise binária extrai evidências de artefatos compilados. O sistema combina essas descobertas em um prompt estruturado. Em seguida, o LLM retorna um veredito e o raciocínio de suporte, com até três oportunidades para solicitar mais arquivos.

A Databricks inseriu perfis de capacidade entre a extração de evidências e o julgamento do modelo. Cada perfil representa uma técnica maliciosa, como coleta de credenciais, persistência, disfarce de binário ou exfiltração de rede. Ele pontua condições observáveis em relação a limites suspeitos, maliciosos e críticos.

Quando um perfil atinge seu limite, o sistema adiciona ao contexto do modelo um resumo estruturado de cerca de 1.800 tokens. O modelo ainda controla o veredito final e pode rejeitar a interpretação do perfil. O material injetado atua como uma orientação especializada, não como uma classificação fixa.

Essa arquitetura separa dois trabalhos que os produtos de segurança com LLM frequentemente confundem. Ferramentas estáticas identificam imports, propriedades de arquivos, metadados e padrões de código. O modelo de linguagem pondera esses sinais dentro do contexto mais amplo do pacote.

O experimento usou cinco tipos de payloads maliciosos empacotados como addons nativos de Node.js. Eles representavam um ladrão de credenciais, downloader, shell reverso, stub de criptominerador e mecanismo de persistência. O ladrão de credenciais também apareceu em seis níveis de ofuscação.

Cada pacote incluía metadados com aparência profissional, um README plausível, bindings JavaScript e uma configuração de compilação padrão. Esses elementos criavam a aparência de um módulo nativo normal. O comportamento malicioso permanecia dentro de um arquivo .node compilado.

Os pesquisadores executaram dez payloads contra cada modelo duas vezes. Uma execução incluiu perfis de capacidade, enquanto a outra não. Os prompts, as evidências binárias, as configurações de inferência e os bytes dos payloads permaneceram inalterados.

Sete modelos formaram a categoria econômica: Claude Haiku 4.5, Gemini 3.5 Flash, Gemma 3 12B, GPT-5.4-nano, Qwen3-Next 80B, GLM 5.3 Flash e Llama 3.1 8B. Claude Sonnet 4.6 e Kimi K3 forneceram referências comportamentais de maior capacidade.

Sem perfis de capacidade, o grupo econômico não atingiu o limite de detecção do estudo em 35 de 70 testes. Vinte desses resultados classificaram payloads comprovadamente maliciosos como benignos. No limite mais rigoroso de classificação maliciosa, 51 dos 70 testes ficaram abaixo do esperado.

Após a injeção dos perfis, 32 dessas 35 falhas se transformaram em detecções. Nenhum modelo testado retornou um veredito benigno para qualquer payload elaborado. Apenas três resultados do GPT-5.4-nano permaneceram abaixo do limite de escalonamento, todos classificados como suspeitos.

Essa é a mudança central por trás da triagem de malware com LLM da Databricks. Os modelos não receberam novos pesos, treinamento mais amplo nem uma palestra geral sobre segurança. Eles receberam interpretações concisas vinculadas às evidências já extraídas do pacote.

Por que pacotes npm aparentemente limpos podem ocultar binários perigosos

O ponto cego em binários surge quando o contexto aparentemente inofensivo do pacote supera evidências que o modelo não consegue interpretar com confiança.

A Databricks começou a coletar amostras de malware npm em novembro de 2025. Seu corpus de pesquisa incluiu 11.413 versões de pacotes corroboradas por alertas de malware npm do OSV. A maioria continha código-fonte malicioso ou buscava um payload em um servidor externo.

Apenas 432 versões corroboradas de pacotes, ou 3,8%, incluíam um binário. Essa pequena parcela criou um problema desproporcional de triagem. Pacotes que continham binários deixaram de receber vereditos decisivos de maliciosos mais de duas vezes mais frequentemente que pacotes apenas com código-fonte.

As taxas relatadas foram de 14,4% para pacotes com binários e 6,2% para pacotes apenas com código-fonte. A diferença importa porque arquivos compilados removem muitos sinais disponíveis em código legível. Binários sem símbolos também omitem nomes de símbolos que ajudam analistas a interpretar funções e dados.

Um pacote npm pode incluir código nativo de forma legítima. Bibliotecas de desempenho, bindings de banco de dados, ferramentas de imagem, terminais e utilitários de sistema usam regularmente componentes compilados. Um script de instalação que chama node-gyp-build, portanto, não é automaticamente suspeito.

Atacantes podem explorar essa normalidade. Eles podem colocar comportamento nativo malicioso atrás de bindings JavaScript limpos e uma descrição de pacote crível. Um modelo que se concentra na coerência do pacote pode tratar esses sinais benignos como evidência mais forte do que imports binários ambíguos.

A Databricks observou esse comportamento em cada uma das 35 falhas iniciais de detecção. Cada falha se apoiava em pelo menos dois sinais contextuais benignos. Vinte e quatro citavam quatro desses sinais em conjunto.

Todas as 35 trataram o script de instalação como padrão. Todas as 35 também consideraram comum o empacotamento de addons nativos. Trinta e duas consideraram os metadados coerentes com a finalidade declarada, enquanto 21 se apoiaram em JavaScript limpo.

Em 14 casos, os modelos reinterpretaram os imports do binário como chamadas normais de sistema. Funções como fopen, connect e gethostname podem dar suporte a software legítimo. Sua combinação e o comportamento ao redor determinam se indicam roubo de credenciais ou conectividade rotineira.

A ofuscação piorou essa avaliação. A Databricks constatou que alguns modelos atribuíram menor gravidade à medida que o payload de roubo de credenciais se tornava mais difícil de inspecionar. O invólucro limpo permaneceu legível, enquanto as evidências binárias incriminadoras se tornaram menos acessíveis.

Esse padrão corresponde a um estudo mais amplo sobre ofuscação envolvendo ChatGPT-4o, Gemini Flash 2.5 e Claude Sonnet 4. Transformações de compilador causaram falhas repetidas de classificação, embora o comportamento subjacente do programa permanecesse inalterado.

Pesquisas sobre o contexto de binários sem símbolos descrevem um desafio relacionado. A remoção de símbolos elimina sinais contextuais usados para localizar e validar comportamentos inseguros. Um raciocínio mais fluente não consegue reconstruir evidências que o pipeline de análise nunca expôs.

Registros de pacotes amplificam as consequências porque dependências de software seguem diretamente para ambientes de desenvolvimento e produção. O MITRE define comprometimento da cadeia de suprimentos como a manipulação de software, produtos ou mecanismos de entrega antes de o destinatário recebê-los.

Um pacote malicioso pode, portanto, herdar confiança do registro, do grafo de dependências ou de uma conta de mantenedor comprometida. Uma vez instalado, seu binário pode ser executado com as permissões da aplicação. Uma apresentação limpa torna-se parte da superfície de ataque.

Perfis de capacidade transformam pistas estáticas em contexto de segurança

Os perfis de capacidade funcionam porque convertem pistas técnicas dispersas em uma alegação explícita que um modelo pode avaliar.

Uma lista bruta de imports não explica a intenção. connect indica conectividade de rede, enquanto fopen indica acesso a arquivos. Nenhuma dessas funções, isoladamente, informa a um modelo que um addon nativo lê credenciais e as envia para outro lugar.

Um perfil de capacidade combina essas observações em um padrão específico de técnica. Ele pode considerar o tipo de pacote, o formato binário, imports, entropia, strings, metadados e comportamento do código-fonte. Limites ponderados expressam, então, o quanto as evidências combinadas sustentam uma hipótese de segurança.

O processo se assemelha ao raciocínio com recuperação aumentada, mas o material recuperado é gerado a partir do pacote sob revisão. Não se trata de um excerto genérico de um relatório de ameaças. Cada resumo conecta uma definição de técnica às evidências encontradas naquela varredura.

Para o payload de roubo de credenciais, os perfis abrangiam disfarce de binário, coleta de credenciais, exfiltração de rede e reconhecimento de ambiente. O shell reverso acionou perfis de disfarce de binário e comportamento de shell reverso. O downloader ativou quatro perfis críticos.

Essa especificidade muda a tarefa do modelo. Sem perfis, o modelo precisa inferir tanto o significado de cada artefato binário quanto o veredito sobre o pacote. Com perfis, a lógica estática lida com a primeira etapa de interpretação.

O modelo então pergunta se as evidências reunidas sustentam a conclusão do perfil. Ele pode considerar contraevidências, avaliar o invólucro do pacote e selecionar uma ação. Essa divisão limita a quantidade de conhecimento especializado esperada dos pesos do modelo.

O resultado do Qwen3-Next para o ladrão de credenciais ilustra o efeito. Sem perfis, o modelo classificou uma amostra ofuscada como benigna, com 0,98 de confiança. Ele também recomendou incluir o pacote em uma lista de permissões.

Com quatro perfis injetados, o mesmo modelo classificou a amostra com bytes idênticos como maliciosa, com 0,98 de confiança. Ele recomendou bloquear o pacote. Nada mudou além do contexto estruturado do domínio.

Essa reversão é mais importante do que uma melhoria média em benchmark. Uma recomendação de lista de permissões com alta confiança pode impedir uma revisão posterior. Ela transforma um detector incerto em uma fonte operacional de confiança mal direcionada.

O experimento também identificou quatro modos recorrentes de falha: racionalização, descarte, hesitação e confabulação. Essas categorias explicam por que simplesmente coletar mais opiniões de modelos não resolve o problema de forma confiável.

A racionalização ocorreu em cerca de 37% das 90 varreduras dos nove modelos principais. Os modelos usaram detalhes comuns de empacotamento para explicar evidências suspeitas. O descarte apareceu em 22% dos casos e frequentemente ignorou os imports binários por completo.

A hesitação afetou 16% das análises. Esses modelos perceberam o perigo, mas pararam em um veredito de suspeita, potencialmente abaixo de um limite de bloqueio automatizado. A confabulação apareceu em cerca de 23% dos casos, incluindo respostas de modelos mais capazes.

A confabulação produziu um risco operacional diferente. Um modelo poderia chegar ao veredito correto enquanto inventava endereços, funções ou rotinas de criptografia. Esses detalhes falsos poderiam contaminar registros de auditoria e desviar investigadores humanos.

Gemini 3.5 Flash detectou todas as dez cargas sem perfis de capacidade. No entanto, a Databricks relatou detalhes técnicos fabricados em várias explicações. A classificação correta não garantiu um raciocínio forense confiável.

Esse resultado sustenta um design centrado em evidências. Um pipeline de segurança deve preservar a origem de cada afirmação e distinguir observações extraídas da interpretação do modelo. Os analistas precisam rastrear um veredito até importações, seções, strings ou comportamentos do código-fonte reais.

Uma base de conhecimento técnica bem mantida também pode apoiar o lado humano desse processo. As equipes precisam de registros acessíveis sobre a lógica dos perfis, exceções, decisões de revisão e técnicas de atacantes em evolução.

Modelos Mais Baratos Reduzem a Diferença, Mas as Métricas Têm Limites

A narrativa de custo é crível dentro do experimento, mas os resultados de produção não estabelecem uma detecção binária perfeita.

Claude Sonnet 4.6 e Kimi K3 detectaram todas as cargas criadas sem perfis. A Databricks estimou que esses modelos de base custavam cerca de três vezes mais por análise do que o grupo econômico. A injeção de perfis permitiu que a maioria dos modelos mais baratos igualasse sua taxa de detecção.

A evidência adicional não foi gratuita. Os modelos econômicos receberam de 9% a 34% mais tokens de entrada após a injeção de perfis. O uso de tokens de saída também aumentou na maioria dos casos.

Modelos mais capazes às vezes usaram menos recursos porque os perfis reduziram a exploração. Claude Opus 4.6 teve uma média de cerca de 10.551 tokens de entrada sem perfis e 7.214 com eles. Kimi K3 produziu 13% menos tokens de saída após receber as evidências do perfil.

Esses números sugerem que um contexto melhor pode substituir solicitações repetidas de arquivos ou raciocínio prolongado. Esse benefício depende da qualidade da etapa estática. Evidências fracas convertidas em prosa refinada apenas tornariam uma conclusão incorreta mais fácil de aceitar.

O benchmark controlado também continua pequeno. Ele usou dez cargas criadas, extraídas de cinco tipos de comportamento. Cada modelo passou por uma execução controlada sob cada condição, com temperatura zero e prompts consistentes.

O comportamento de modelos hospedados pode mudar à medida que os provedores atualizam seus endpoints. A Databricks reconheceu que os vereditos absolutos representam um único período de serviço. A evidência mais forte é a diferença, dentro do período, entre entradas idênticas.

A validação em produção oferece uma visão mais ampla e mais confusa. A Databricks identificou 470 versões maliciosas de pacotes npm confirmadas pelo OSV, contendo 604 binários nativos. O conjunto incluía 273 arquivos PE, 215 arquivos ELF, 113 arquivos Mach-O e três formatos não identificados.

Todos os binários ELF estavam sem símbolos. Quarenta por cento dos binários foram compilados com Go ou Rust, enquanto 50 arquivos ELF eram empacotados com UPX. Esses detalhes mostram por que uma única regra universal para código nativo geraria resultados fracos.

A avaliação em produção cobriu 425 versões maliciosas de pacotes com vereditos do scanner. Também utilizou 2.449 versões de pacotes de 287 pacotes aparentemente benignos. Os candidatos benignos ultrapassavam um milhão de downloads mensais e nunca haviam aparecido no OSV.

No limite de escalonamento, o scanner relatou precisão de 0,77, recall de 0,81 e pontuação F1 de 0,79. Ele recuperou 345 das 425 versões maliciosas de pacotes. Oitenta ficaram abaixo do limite.

O conjunto benigno produziu 104 escalonamentos, representando 4,25% de suas versões de pacotes. Esses alertas concentraram-se em seis pacotes, ou cerca de 2% do conjunto distinto de pacotes benignos.

Uma taxa de revisão de 4,25% pode ser administrável em uma fila de triagem filtrada. Ela se tornaria cara se aplicada indiscriminadamente a todas as versões de pacotes em um grande ecossistema de dependências. O volume operacional importa tanto quanto a precisão do benchmark.

Os rótulos também introduzem incerteza. Os avisos do OSV marcam uma versão de pacote como maliciosa sem sempre identificar qual artefato carrega a carga. Alguns pacotes podem conter um binário inocente de terceiros enquanto JavaScript malicioso executa o ataque real.

A Databricks descobriu que cerca de metade dos 20 pacotes de produção liberados como benignos continha ferramentas reconhecíveis de terceiros. Os exemplos incluíam ripgrep, node-pty e plugins de instalador NSIS. O aviso ainda poderia estar correto no nível do pacote.

Portanto, o recall relatado não é uma medida limpa da classificação de binários. Ele mede decisões contra rótulos do OSV no nível de pacote. A Databricks declara explicitamente que o desempenho real em binários pode ser maior ou menor.

O banco de dados de pacotes maliciosos da OpenSSF continua valioso porque fornece relatórios abertos no formato OSV. No entanto, rótulos em escala de registro não podem substituir a verificação no nível do artefato ao avaliar um detector de binários.

O Raciocínio de Modelo Sem Assistência Agora É a Estratégia Sob Pressão

A pesquisa pressiona produtos de segurança que tratam um LLM como o principal analista, em vez de como a camada final de raciocínio.

Designs centrados no modelo são atraentes porque reduzem o trabalho de integração. Uma equipe pode colocar o conteúdo do pacote em um prompt, solicitar um veredito e exibir uma explicação em linguagem natural. Essa simplicidade oculta a dependência do modelo de evidências visíveis.

Cargas compiladas expõem a fraqueza. Um modelo de linguagem pode interpretar desmontagem ou recursos extraídos quando eles estão disponíveis. Ele não consegue inferir de forma confiável comportamentos ocultos a partir apenas de JavaScript limpo e metadados profissionais.

Comprar um modelo maior pode melhorar a detecção de base. A Databricks observou que Sonnet e Kimi detectaram todas as cargas criadas sem perfis. No entanto, ambas as linhas de base de maior capacidade ainda produziram raciocínio confabulado em algumas análises.

Isso cria dois requisitos separados. Um detector deve alcançar a decisão correta de escalonamento. Ele também deve fornecer evidências que um analista possa verificar.

Perfis de capacidade atendem ao primeiro requisito ao orientar a atenção para combinações significativas. Achados estáticos estruturados apoiam o segundo ao ancorar explicações em artefatos observáveis. O LLM continua útil para síntese, resolução de conflitos e priorização.

A votação por maioria não oferece a mesma proteção. Em uma amostra ofuscada de ladrão de credenciais, os nove modelos se dividiram entre benigno, suspeito, altamente suspeito e malicioso. A maioria permaneceu abaixo do limite de detecção.

Esses erros foram correlacionados porque vários modelos confiaram no mesmo contexto benigno. Adicionar mais juízes igualmente confusos não introduziu evidência independente. O voto apenas repetiu o ponto cego.

A implicação estratégica vai além do npm. As equipes de segurança pedem cada vez mais que LLMs interpretem alertas, código-fonte, logs, configurações de nuvem e eventos de identidade. Cada tarefa contém pressupostos de domínio que um modelo geral pode não aplicar de forma consistente.

A arquitetura mais defensável separa extração, interpretação e decisão. Ferramentas determinísticas extraem fatos. Perfis versionados interpretam combinações relevantes. O modelo resolve o contexto e produz uma avaliação voltada ao analista.

Isso não torna os perfis neutros. Seus autores escolhem limites, pesos, definições e exceções. Atacantes também podem estudar regras comuns e adaptar seus binários para evitar acioná-las.

Os perfis podem ficar desatualizados à medida que sistemas de build e técnicas de malware mudam. Uma combinação suspeita de importações hoje pode aparecer amanhã em um framework legítimo popular. Por outro lado, um novo método de exfiltração pode escapar de perfis escritos em torno de chamadas de sistema mais antigas.

A abordagem, portanto, transfere parte do risco da seleção do modelo para a manutenção do conhecimento. As equipes de segurança precisam de responsáveis pela qualidade dos perfis, testes de regressão e revisão de falsos positivos. Também precisam de evidências versionadas que expliquem por que cada regra existe.

As defesas de registro permanecem uma camada separada. A orientação sobre proveniência do npm explica como os usuários podem verificar onde e como pacotes compatíveis foram publicados. A proveniência pode conectar um artefato ao seu commit de origem e fluxo de trabalho de build.

Essa verificação ajuda a identificar lançamentos não autorizados ou adulterados. Ela não prova que a origem autorizada ou o comportamento compilado seja seguro. Triagem de malware, proveniência, segurança dos mantenedores e controles de runtime abordam partes diferentes do mesmo problema de cadeia de suprimentos.

Para compradores, a principal questão não é mais qual modelo lidera um benchmark genérico de segurança. Eles devem perguntar quais evidências chegam ao modelo, como as afirmações permanecem rastreáveis e como o sistema trata binários incertos.

Também devem inspecionar a política de escalonamento. Um veredito suspeito tem pouco valor protetivo se fluxos automatizados bloquearem apenas classificações maliciosas. A Databricks mostrou que vários modelos reconheceram o risco, mas não conseguiram cruzar o limite operacional.

Três Sinais Testarão se a Abordagem se Generaliza

O próximo teste é saber se a injeção de conhecimento de domínio resiste a malware desconhecido, escala de registro e adaptação adversarial.

O primeiro sinal é uma reprodução independente com malware real e rotulado no nível de artefato. Pesquisadores precisam de conjuntos de dados que identifiquem se o componente malicioso é JavaScript, metadados, um script de instalação ou um binário incluído.

Esses rótulos refinariam as estimativas de precisão e recall. Também revelariam se os perfis detectam a carga real ou apenas se correlacionam com um rótulo de pacote malicioso. Resultados mais fortes no nível de artefato reforçariam a afirmação central da Databricks.

O segundo sinal é o desempenho diante de comportamentos e toolchains não vistos. A Databricks testou cinco padrões de ataque criados e validou seu scanner completo em um conjunto mais amplo derivado do OSV. Testes futuros devem reter famílias inteiras de comportamento durante o desenvolvimento dos perfis.

O sucesso em famílias retidas mostraria que o método captura conceitos de segurança transferíveis. Uma queda acentuada sugeriria que os perfis funcionam principalmente como regras selecionadas para padrões conhecidos.

A diversidade de compiladores e plataformas será importante. Arquivos PE, ELF e Mach-O expõem diferentes metadados e convenções. Binários Go e Rust também diferem de artefatos C ou C++ de formas que afetam a análise estática.

Atacantes responderão se sistemas de perfis de capacidade se tornarem comuns. Eles podem substituir importações óbvias, atrasar a execução, carregar funcionalidades dinamicamente ou mover o comportamento malicioso para outra camada do pacote. Cada adaptação pode enfraquecer um resumo de evidências estáticas.

O terceiro sinal é o custo da revisão operacional. A Databricks relatou 104 escalonamentos entre 2.449 versões de pacotes benignos, concentrados em seis pacotes. Os dados de implantação devem mostrar quantas horas de analista esses grupos consomem.

Um sistema sustentável precisa agrupar alertas relacionados, preservar evidências e aprender com exceções revisadas. Caso contrário, uma taxa modesta de falsos positivos no nível de pacote pode criar trabalho repetitivo entre versões e ambientes.

As equipes também devem monitorar falhas graves, não apenas o recall agregado. O scanner de produção da Databricks liberou como benignas 20 versões de pacotes maliciosos rotulados pelo OSV. Algumas provavelmente carregavam sua carga fora do binário incluído, mas a incerteza permanece importante.

A qualidade das evidências deve se tornar uma métrica relatada. Um detector que classifica corretamente enquanto inventa detalhes forenses não é totalmente confiável. Avaliações futuras devem pontuar o embasamento factual separadamente da precisão do veredito.

A triagem de malware com LLM da Databricks oferece um forte argumento em favor de expertise estruturada no momento da inferência. Ela mostra que modelos mais baratos podem tomar decisões muito melhores quando o pipeline de segurança interpreta evidências opacas antes de solicitar um julgamento.

Isso não estabelece que o conhecimento no momento do prompt elimine o problema do binário. Os perfis dependem de visibilidade estática, regras mantidas e limites que invasores podem testar. Os rótulos de produção também deixam em aberto quais questões sobre qual artefato era malicioso.

As equipes de segurança devem agora testar uma proposta prática: seus modelos existentes conseguem melhorar quando recebem evidências melhores, antes de pagarem por um modelo maior? Crie um conjunto de avaliação a partir de pacotes revisados, preserve rótulos no nível do artefato e compare varreduras idênticas com e sem contexto de domínio. O resultado útil não é uma explicação persuasiva. É um veredito rastreável que se sustenta quando o pacote parece limpo e o binário não.