Detecção de Malware Android · Dados Sintéticos · PPGES/UNIPAMPA

Reduzir o custo experimental
em três fases.

Gerar e avaliar dados sintéticos para detecção de malware Android é caro, só o conjunto MH100k somaria ~28.583 h (cerca de 3 anos) de execução. Este projeto ataca esse custo por etapas.

Fase 1 otimiza a busca de hiperparâmetros (Tune3). Fase 2 reduz a dimensionalidade e balanceia os dados, dois métodos novos e 33+ datasets preparados. Fase 3 executa os experimentos finais em larga escala.

3
fases encadeadas de redução de custo
2
métodos novos: seleção de características e balanceamento
33+
datasets preparados (11 bases × original/reduzido/balanceado)
11
datasets-base Android, de 10k a 100k amostras
O impacto combinado

De cerca de 3,6 anos de computação para menos de uma semana.

Estimativa do tempo total para otimizar os modelos generativos em todos os 11 datasets. Partindo do custo medido na ferramenta de geração (Malsyngen), cada fase do projeto corta uma fatia do tempo: a redução é progressiva e acumulativa.

Ponto de partidaBusca completa, dados originais
~31.900 h~1.329 dias · ~3,6 anos
linha de base · só o MH100k responde por ~28.583 h (cerca de 3 anos)
+ Fase 2 · seleção de característicasStatistical Ranking (90–99,6% menos atributos)
~360 h~15 dias
redução acumulada de ~98,9% no tempo de computação
+ Fase 2 · balanceamentoUndersampling híbrido (ENN + RandomUnder)
~235 h~10 dias
redução acumulada de ~99,3% · menos amostras por execução
+ Fase 1 · Tune3 (HPO)Busca direcionada em vez de varredura completa
~130 h~5 a 6 dias
redução acumulada de ~99,6% · até 44% menos esforço de busca
~3,6 anos de computação  →  menos de uma semana
~99,6%
// estimativa de ordem de grandeza. Tempos originais medidos na geração/avaliação (Malsyngen, slides da defesa); reduções por fase derivadas dos resultados dos artigos. Largura das barras em escala logarítmica.
A trajetória do projeto

Uma fase resolve um gargalo de custo. A seguinte ataca o próximo.

Cada etapa é uma contribuição independente, e, somadas, tornam viável uma campanha experimental que, na configuração original, levaria anos de processamento.

FASE 01

Tune3, HPO

Otimização de hiperparâmetros

Reduz progressivamente o espaço de busca em vez de varrê-lo. Iguala ou supera o Random Search testando menos.

  • Método multiestágio de filtragem adaptativa
  • até −44% de tempo acumulado de busca
  • aplicado a modelos CGAN (Malsyngen)
● concluída · WRSeg 2025
FASE 02 · 2 métodos novos

Dados: reduzir & balancear

Dimensionalidade + distribuição de classes

Encolhe os atributos e corrige (quando vale a pena) o desbalanceamento, gerando dezenas de versões de dataset prontas para experimentação.

  • Statistical Ranking: seleção por votação (90–99,6% de redução)
  • Diagnóstico de balanceamento: esparsidade & diversidade
  • 33+ datasets preparados como contribuição própria
● em curso · 2× SBSeg 2026
FASE 03

Experimentos intensivos

Execução extensiva e final

Combina HPO (Fase 1) + datasets reduzidos e balanceados (Fase 2) para a avaliação ampla e definitiva da geração de dados sintéticos.

  • varredura sobre todos os 33+ datasets
  • Tune3 escolhe as configurações; dados enxutos reduzem o tempo
  • meta: o que levaria anos em dias/semanas
○ planejada
Fase 1 · Otimização de hiperparâmetros

Tune3: reduzir o espaço por filtragem progressiva.

O espaço de busca explode (1.125 configurações na grade de referência) e varrê-lo é caro. O Tune3 não faz busca exaustiva, afunila as configurações em três estágios encadeados, descartando o que é instável ou inviável e concentrando esforço onde há maior potencial.

ESTÁGIO 1 inicialização informada ESTÁGIO 2 amostragem de borda ESTÁGIO 3 refinamento por risco top-k
configuração promissora (mantida) instável / inviável (descartada) ainda não avaliada
ESTÁGIO 1

Inicialização informada

Parte de valores plausíveis vindos da literatura, de testes empíricos ou definidos pelo usuário, estabelecendo um espaço amplo, porém realista.

// ranges brutos dos hiperparâmetros
ESTÁGIO 2

Amostragem de borda

Explora regiões contrastantes do espaço com variação controlada, testando extremos e filtrando execuções instáveis antes de gastar recursos com elas.

// descarta combinações que não geram resultado
ESTÁGIO 3

Refinamento por risco

Concentra a busca nas combinações mais promissoras segundo Recall e F1‑score, iterando até não haver mais melhoria, então retorna as configurações finais.

// ranking top-k orientado a risco
DREBIN-215 Recall máximo
Tune30,96
0,96
Random Search0,95
0,95
Desempenho equivalente com ~34% menos custo acumulado. Estabiliza após ~30 execuções, enquanto o Random Search oscila entre 0,55 e 0,86.
DefenseDroid API Degree Recall final
Tune30,92
0,92
Random Search0,87
0,87
Ganho simultâneo de qualidade e eficiência: ~44% menos tempo acumulado e convergência entre a 25ª e a 35ª execução.
Fase 2 · Engenharia de dados

Dois métodos novos para tornar os dados tratáveis.

Datasets de malware Android costumam ter milhares de atributos e classes desbalanceadas. A Fase 2 introduz duas contribuições independentes, uma de seleção de características e outra de balanceamento, validadas em 11 datasets via 5-fold estratificado, com a seleção integrada dentro de cada fold para evitar vazamento de dados.

Redução de dimensionalidade no MH100k
24.833 ~1.240
atributos · −95% · sem perda estatística (Wilcoxon p>0,05)
Tempo de execução
−79,6%
1.957s → 400s
Faixa de redução
90–99,6%
nos 11 datasets
filtro de variância filtro de correlação χ² · MI · RF → votação ≥2/3
Método A · seleção de características
novo · Statistical Ranking

Statistical Ranking

Um ensemble de seleção por votação: cada atributo só é mantido se aparecer entre os mais relevantes para pelo menos 2 de 3 rankers independentes, Qui-quadrado (χ²), Informação Mútua e importância de Random Forest. A combinação de critérios estatístico, informacional e baseado em modelo elimina redundância sem o viés de uma única lógica.

  • Consenso multiperspectiva: dependência estatística, não-linear e por importância de modelo.
  • Sem degradação significativa: teste de Wilcoxon p>0,05 em 10 dos 11 datasets.
  • Melhor trade-off redução×Recall frente a RFE, SemiDroid e Lasso.
  • Validado também sob protocolo Treino-Sintético / Teste-Real (TS-TR).
Método B · balanceamento de classes
novo · diagnóstico estrutural

Quando balancear prejudica

Balancear não é um passo de pré-processamento neutro. Comparando estratégias de undersampling, híbridas e oversampling em 11 datasets, o método mostra que o ganho depende da estrutura do conjunto, e propõe esparsidade e diversidade como os primeiros indicadores que preveem quando o balanceamento ajuda ou atrapalha.

  • 7 de 11 datasets melhoram; 4 de 11 degradam, decisão guiada por dados.
  • ENN + RandomUnder (híbrido) é a estratégia mais consistente.
  • Esparsidade alta e diversidade colapsada = risco de degradação.
  • Diagnóstico de overfitting via gap treino-teste e desvio entre folds.
MH100k · Recall da classe maliciosa (após redução)
0,63 0,99
F1-score 0,35 → 0,97 · com ENN + RandomUnder
Tempo (MH100k)
−99%
28.583h → ~130h
Estratégias avaliadas
10
under · híbrido · over
RandomUnder · NearMiss · ENN · Tomek ENN+RU · Tomek+RU SMOTE · ADASYN · b-SMOTE · RandomOver
A contribuição em dados

11 datasets-base, 33+ versões prontas para experimentar.

Cada um dos 11 conjuntos Android foi caracterizado, reduzido pela seleção de características e balanceado, produzindo versões original, reduzida e balanceada de cada base. Esse acervo, por si só, é uma contribuição significativa e o insumo direto da Fase 3.

Acessar o repositório de datasets ↗
11
datasets-base, de 10.476 a 101.934 amostras
33+
versões geradas (original · reduzida · balanceada)
~31,9k h
de execução original somada, quase tudo no MH100k
Dataset Ano Amostras Atributos Reduzido Redução Exec. original
MH100kDataset100k · 2023 2023101.93424.833 ~1.24099,6%28.583,6 h
KronoDroid Real 202178.137286 2989,9%280,6 h
KronoDroid Emulator 202163.991276 2590,9%234,9 h
AndroCrawl 201396.744141 1291,5%182,7 h
Android Permissions 201826.864151 4669,5%73,8 h
DREBIN-215 201815.031215 6470,2%64,4 h
DefenseDroid PRS 202111.9752.877 14495,0%416,4 h
DefenseDroid API Katz 202110.4766.002 30095,0%736,9 h
DefenseDroid API Degree 202110.4766.002 30095,0%736,9 h
DefenseDroid API Closeness 202110.4764.274 21395,0%532,8 h
Adroit 201611.476166 6660,2%49,4 h

// atributos reduzidos pela seleção de características (Fase 2); tempo de execução medido na geração/avaliação de dados sintéticos (Malsyngen).

Posicionamento · Fase 1

Onde o Tune3 se diferencia.

Trabalhos recentes em RNAs geradoras e classificadoras concentram-se em ajuste manual, Grid Search ou Random Search. Nenhum reduz o espaço progressivamente nem prioriza explicitamente o risco.

Abordagem Busca direcionada Redução progressiva Prioriza risco (Recall) Reuso via cache Custo
Ajuste manualXu et al. 2024 · Li et al. 2022 nãonãonãonão alto / tentativa e erro
Grid SearchZhou et al. 2020 · Basri et al. 2023 nãonãonãonão alto
Grid / Random SearchNurhayati et al. 2021 parcialnãonãonão médio
Tune3este trabalho · CGAN simsimsimsim · SQLite baixo
Fase 3 · O que vem a seguir

A execução intensiva, agora viável.

Com as três fases acopladas, a campanha experimental final percorre todos os 33+ datasets: o Tune3 (Fase 1) escolhe as configurações promissoras e os dados reduzidos e balanceados (Fase 2) cortam drasticamente o custo de cada execução. O que antes exigiria anos passa a caber em dias.

ENTRADA

33+ datasets enxutos

Versões reduzidas e balanceadas de 11 bases Android, menos atributos, distribuição tratada, mesma capacidade discriminativa.

MOTOR

HPO direcionado

O Tune3 evita varrer o espaço inteiro de hiperparâmetros, concentrando execuções nas regiões promissoras de cada dataset.

SAÍDA

Avaliação ampla e final

Comparação extensiva da geração de dados sintéticos (Malsyngen/CGAN) entre datasets, métricas e estratégias, em escala antes inviável.

custo_final  =  HPO_Tune3  ×  dimensionalidade↓  ×  distribuição_tratada
              ≈  de ~3 anos (só MH100k) para a ordem de dias

Em resumo: o projeto transforma um experimento proibitivamente caro em um processo factível. A Fase 1 mira a busca, a Fase 2 enxuga e equilibra os dados (com dois métodos novos e 33+ datasets), e a Fase 3 colhe o resultado, uma avaliação intensiva da síntese de dados para detecção de malware Android, onde tempo, estabilidade e sensibilidade a falsos negativos são fatores críticos.

Defesa de Mestrado

A defesa: apresentação e banca.

Defesa pública de mestrado no PPGES/UNIPAMPA, Alegrete, 2026. Abaixo, o primeiro slide da apresentação (com link para o PDF completo) e a banca examinadora reunida na sessão.

Primeiro slide da apresentação de defesa: Redução de Custo Experimental na Geração e Avaliação de Dados Sintéticos para Detecção de Malware Android
Primeiro slide da apresentação de defesa.
Baixar apresentação (PDF) ↗
Banca examinadora e participantes reunidos na sessão de defesa
Banca examinadora e participantes reunidos na sessão de defesa.

Banca examinadora

  • Prof. Dr. Diego KreutzUNIPAMPA · Orientador
  • Prof. Dr. Vinicius de Carvalho RispoliFCTE/UnB
  • Prof. Dr. Celso Nobre da FonsecaUNIPAMPA
  • Prof. Dr. Claudio SchepkeUNIPAMPA
  • Prof. Dr. Rodrigo MansilhaUNIPAMPA
  • Profa. Dra. Aline de Lurdes Zuliani LunkesPUCPR
  • Prof. Dr. Hendrio Luis de Souza BragançaUFAM