A tela de ajuda já mostra que o cliente CLI usa diferentes comandos para interagir com os vários subsistemas do P4wnP1 A.L.O.A. A maioria desses comandos possui seus próprios subcomandos, novamente. A ajuda para cada comando ou subcomando pode ser acessada anexando `-h` ao comando CLI:```
root@kali:~# P4wnP1_cli hid run -h
Run script provided from standard input, commandline parameter or by path to script file on P4wnP1

Usage:
  P4wnP1_cli hid run [flags]

Flags:
  -c, --commands string      HIDScript commands to run, given as string
  -h, --help                 help for run
  -r, --server-path string   Load HIDScript from given path on P4wnP1 server
  -t, --timeout uint32       Interrupt HIDScript after this timeout (seconds)

Global Flags:
      --host string   The host with the listening P4wnP1 RPC server (default "localhost")
      --port string   The port on which the P4wnP1 RPC server is listening (default "50051")

No host USB "Hello World" deve ter sido digitado para a aplicação com foco no teclado.

*Se o seu cliente SSH executa no próprio host USB, o "Hello world" digitado acaba em algum lugar entre a saída resultante do comando CLI (não pertence à saída, mas foi digitado no meio).*

**Objetivo alcançado. Injetamos pressionamentos de teclas no alvo.**
 
Muita leitura para uma tarefa simples como injeção de teclas, mas mais uma vez, esta seção tem o objetivo de explicar conceitos básicos.

### 2.2 Avançando para recursos de linguagem mais sofisticados do HIDScript

Se você conseguiu executar a injeção de teclas "Hello world", este é um bom momento para explorar alguns recursos adicionais do HIDScript. 

Nós já conhecemos o comando `type`, mas vamos tentar discutir alguns comandos HIDScript mais sofisticados: 

#### Pressionando teclas especiais e combinações

O comando `type` suporta pressionar Enter, codificando um caractere de "nova linha" na string de entrada, assim:```
P4wnP1_cli hid run -c 'type("line 1\nline 2\nline 3 followed by pressing RETURN three times\n\n\n")'

*Nota: Duas das teclas foram modificadores (CTRL e ALT) e apenas uma foi uma tecla real (DELETE)*

Vamos pressionar a tecla 'A' sem nenhuma tecla modificadora:```
P4wnP1_cli hid run -c 'press("A")'

Isto deveria ter produzido uma saída com um A maiúsculo.

É importante entender que `press` interpreta os seus argumentos de tecla como teclas, enquanto `type` tenta encontrar as
combinações de teclas apropriadas para produzir os caracteres de saída pretendidos.   

Num último exemplo, vamos combinar `press` e `type`.```
P4wnP1_cli hid run -c 'type("before caps\n"); press("CAPS"); type("after caps\n"); press("CAPS");'

O resultado da saída do comando fornecido acima depende do layout alvo usado pelo host USB. 

Em um host com layout de teclado alemão, o resultado se parece com isto:```
Tzping with EN?US lazout
Typing with German layout supporting special chars üäö

Observe que o resultado pretendido só é alcançado se o layout do teclado do P4wnP1 estiver alinhado com o layout do teclado realmente usado pelo host USB.

O comando `layout` permite alinhar o layout interno do P4wwP1 ao do host USB alvo.

Ser capaz de alterar o layout no meio de um HIDScript em execução pode ser útil: Quem sabe, talvez você queira forçar o layout do teclado do host alvo emitindo comandos com layouts variados até que um dos comandos digitados atinja o efeito desejado.

**Importante:** O layout tem efeito global. Isso significa que se vários HIDScripts estiverem em execução simultaneamente e um dos scripts definir um novo layout, todos os outros scripts também serão afetados imediatamente.

#### Velocidade de digitação

Por padrão, o P4wnP1 injeta pressionamentos de teclas o mais rápido possível. Dependendo do seu objetivo, isso pode ser um pouco demais (pense em contramedidas que evitam a injeção de teclas com base na análise de comportamento da velocidade de digitação). O HIDScript suporta um comando para alterar esse comportamento.

`typingSpeed(delayMillis, jitterMillis)`

O primeiro argumento do comando `typingSpeed` representa um atraso constante em milissegundos, que é aplicado entre dois pressionamentos de teclas. O segundo argumento é um "jitter" adicional em milissegundos. Ele adiciona um atraso aleatório adicional, que varia entre 0 e o "jitter" fornecido em milissegundos, ao atraso estático fornecido com o primeiro argumento.

Vamos tentar usar `typingSpeed` para desacelerar a digitação:```
P4wnP1_cli hid run -c 'typingSpeed(100,0); type("Hello world")'

Finalmente, ao combinar e ajustar ambos os valores, poderíamos simular a velocidade natural de digitação:```
P4wnP1_cli hid run -c 'typingSpeed(100,150); type("Writing with more natural speed")'

Se testou o comando acima, a digitação só deve começar se NUM LOCK estiver pressionado no teclado físico do host USB, 
mas pode encontrar casos em que as teclas são emitidas imediatamente, mesmo que NUM LOCK não tenha sido pressionado (e o 
LED do teclado não tenha mudado).

Este é um comportamento intencional e a razão para isso é outro caso de uso para o comando `waitLED`:

Talvez você tenha usado outras linguagens de script de teclado e outros dispositivos USB capazes de injetar teclas, antes. 
A maioria desses dispositivos compartilha um problema comum: Você não sabe quando começar a digitar! 

Se você começar a digitar imediatamente após o dispositivo USB ser ligado, é provável que o host USB não tenha terminado 
a enumeração do dispositivo e, portanto, não tenha conseguido ativar os drivers do teclado. No final, suas teclas são perdidas.

Para superar isso, você pode adicionar um atraso antes do início da injeção de teclas. Mas quanto tempo esse atraso deve ter? Cinco 
segundos, 10 segundos, 30 segundos ? 

A resposta é: depende! Depende de quão rápido o host é capaz de enumerar o dispositivo e ativar o driver do 
teclado. Na verdade, você não poderia saber quanto tempo isso leva sem testar no alvo real.

Mas como já aprendemos, sistemas operacionais como Windows compartilham o estado do LED entre vários teclados.
Isso significa que, se o LED NUMLOCK do teclado host estiver configurado como ON antes de conectar um segundo teclado, o LED NUMLOCK 
deste novo teclado também deve ser configurado como ON, uma vez conectado. Se o LED NUM LOCK tivesse sido configurado como OFF, de qualquer forma, 
o teclado recém-conectado recebe o estado do LED (todos os LEDs desligados neste caso). O interessante sobre isso é
que essa "atualização de LED" só pode ser enviada do host USB para o teclado conectado se o driver do teclado tiver 
terminado de carregar (enviar o estado do LED não seria possível de outra forma).

Não é lindo? O host USB nos diz: "Estou pronto para receber teclas". Não há necessidade de brincar com 
atrasos iniciais. 

Mas aqui está outro problema: Suponha que conectamos o P4wnP1 a um host USB. Executamos um HIDScript começando com `waitLED` em vez
de um atraso personalizado. A digitação começa após o `waitLED`, mas nada acontece - nossas teclas são perdidas, mesmo assim! Por quê? 
Porque é provável que tenhamos perdido a atualização do estado do LED, pois ela chegou antes mesmo de iniciarmos nosso HIDScript. 

Exatamente essa "condição de corrida" é a razão pela qual o P4wnP1 preserva todas as mudanças de estado de LED reconhecidas, a menos que pelo menos um 
HIDScript as consuma chamando `waitLED` (ou `waitLEDRepeat`). Isso pode resultar no comportamento descrito anteriormente,
onde um `waitLED` retorna imediatamente, mesmo que nenhuma mudança de LED tenha ocorrido. Sabemos agora: A mudança de LED de fato ocorreu, 
mas pode ter acontecido muito antes (antes mesmo de iniciarmos o HIDScript), porque a mudança de estado foi preservada.
Também sabemos que esse comportamento é necessário para evitar perder mudanças de estado de LED, caso `waitLED` seja usado para testar a 
"prontidão do driver de teclado do host USB".

*Nota: Vale a pena mencionar que `waitLED` retorna SOMENTE se o estado do LED recebido diferir do estado interno do P4wnP1. 
Isso significa que, mesmo se escutarmos uma mudança em qualquer LED com `waitLED(ANY)`, ainda pode acontecer que recebamos 
um estado inicial de LED de um host USB que não difere do estado interno do P4wnP1. Nesse caso `waitLED(ANY)` 
bloquearia para sempre (ou até que uma mudança real de LED aconteça).
Este caso especial pode ser tratado chamando `waitLED(ANY_OR_NONE)`, que retorna assim que um novo estado de LED chegar,
mesmo que não resulte em uma mudança.*

**Chega de explicação, vamos à prática... antes disso, precisamos mudar um pouco a configuração do hardware:**

Conecte uma fonte de alimentação externa à segunda porta USB do Raspberry Pi Zero (a externa). Isso garante que
o P4wnP1 não perca energia quando desconectado do host USB, pois não depende mais da energia do barramento. A porta USB que
deve ser usada para conectar o P4wnP1 ao host USB alvo é a mais interna das duas portas.

Agora inicie o seguinte HIDScript``` 
P4wnP1_cli hid run -c 'while (true) {waitLED(ANY);type("Attached\n");}'

Após pressionar o botão de execução, o lado direito da janela deve mostrar uma nova tarefa HID em execução. Se você pressionar o pequeno botão "info" à direita da tarefa HIDScript, poderá ver detalhes, como seu estado (deve estar em execução), o ID da tarefa e o ID da VM (este é o número da VM JavaScript que está executando esta tarefa. Existem 8 dessas VMs, portanto, 8 HIDScripts podem ser executados em paralelo).

Agora, se qualquer mudança de LED for emitida pelo host USB (alternando NUM, CAPS ou SCROLL), a tarefa HIDScript deve terminar. Ela ainda pode ser encontrada em tarefas "Succeeded".

Se você pressionar o pequeno botão "info" novamente, deve haver informações sobre o valor do resultado (codificado como JSON), que se parecem com isto:```
{"ERROR":false,"ERRORTEXT":"","TIMEOUT":false,"NUM":true,"CAPS":false,"SCROLL":false,"COMPOSE":false,"KANA":false}

No meu caso, `NUM` tornou-se verdadeiro. No seu caso, talvez tenha sido `CAPS`. Não importa qual LED foi. "hat importa é 
o fato de que o valor de retorno oferece a oportunidade de examinar a mudança do LED que faz o comando retornar e, assim,
poderia ser usado para tomar decisões de ramificação no seu HIDScript (com base nas mudanças de estado do LED emitidas pelo teclado real do host USB).

Vamos tentar um exemplo:```
while (true) {
 result = waitLED(ANY);
 if (result.NUM) {
   type("NUM has been toggled\n");
 }
 if (result.SCROLL) {
   type("SCROLL has been toggled\n");
 }
 if (result.CAPS) {
   break; //exit loop
 }
}

Embora `waitLED` seja um comando muito poderoso se usado corretamente, ele não ajudou a lidar com nossa tarefa simples de 
pausar robustamente um HIDScript até que uma tecla modificadora de estado seja pressionada no host USB alvo (lembre-se: Queríamos pausar
a execução para garantir que o indesejado "alguém" saísse antes de começar a digitar, mas `waitLED` ocasionalmente retornava cedo, 
devido a mudanças preservadas no estado do LED).

É aqui que `waitLEDRepeat` entra em jogo e vem para o resgate.

Cole o seguinte script no editor e tente fazer o comando retornar. Inspecione os resultados do HIDScript depois.```
return waitLEDRepeat(ANY)

Então é assim que se interage com relatórios de LED de um host USB em HIDScript.

*Nota: `waitLEDRepeat` não difere de `waitLED`, no que diz respeito ao consumo de mudanças de estado de LED preservadas. De qualquer forma, é muito mais difícil acioná-lo não intencionalmente.*
 
Então `waitLEDRepeat` é a escolha certa, se a tarefa é pausar HIDScripts até que a interação humana ocorra. Claro que também pode ser usado para ramificação (branching), pois fornece o mesmo objeto de retorno que `waitLED` faz. 

Até este ponto, ganhamos um bom conhecimento sobre HIDScript (claro que não sobre tudo, ainda nem examinamos as capacidades de controle de mouse dessa linguagem de script). De qualquer forma, este tutorial é sobre o workflow e conceitos básicos do P4wnP1 A.L.O.A. Então, não vamos examinar outros recursos do HIDScript, por agora, e seguimos em frente.

Vamos resumir o que aprendemos sobre o workflow e conceitos do P4wnP1 até agora:
- podíamos iniciar ações como injeção de teclas a partir do cliente CLI, sob demanda
- podíamos usar o webclient para alcançar o mesmo, enquanto tínhamos controle adicional sobre os jobs HIDScript
- se conectarmos uma fonte de alimentação externa ao P4wnP1 A.L.O.A., anexamos/desanexamos de diferentes hosts USB e HIDScripts já iniciados continuam funcionando perfeitamente 
- podíamos configurar a pilha USB exatamente conforme nossas necessidades (e alterar sua configuração em tempo de execução, sem reiniciar o P4wnP1)
- podíamos escrever HIDScripts multifuncionais, com lógica complexa baseada em JavaScript (com suporte para funções, loops, ramificações etc. etc.)

### 3. Workflow parte 2 - Modelagem e TriggerActions

Antes de prosseguir com os outros conceitos principais do P4wnP1 A.L.O.A., vamos refinar nosso primeiro objetivo, que era "executar uma injeção de teclas contra um host USB":

- O novo objetivo é digitar "Hello world" no editor de um host Windows USB (notepad.exe). 
- O editor deve ser aberto pelo P4wnP1 (não manualmente pelo usuário).
- O editor deve ser fechado automaticamente, quando qualquer um dos LEDs do teclado do host USB for alternado.
- Toda vez que o P4wnP1 for anexado ao host USB, este comportamento deve se repetir (com fonte de alimentação externa, sem reinicialização do P4wnP1)
- O processo *deve ser executado apenas uma vez*, a menos que o P4wnP1 seja reanexado ao host USB, mesmo que mudanças sucessivas de LED do teclado ocorram após o HIDScript ter sido iniciado.
- Mesmo que o P4wnP1 seja reinicializado, o mesmo comportamento deve ser recuperável sem recriar detalhes da configuração do zero, novamente.

Iniciar o notepad, digitar "Hello world" e fechar o notepad após uma mudança de LED poderia ser feito com as coisas que aprendemos até agora. Um HIDScript correspondente poderia ser algo como:```
// Starting notepad
press("WIN R");         // Windows key + R, to open run dialog
delay(500);             // wait 500ms for the dialog to open
type("notepad.exe\n"); 	// type 'notepad.exe' to the run dialog, append a RETURN press
delay(2000);            // wait 2 seconds for notepad to come up

// Type the message
type("Hello world")     // Type "Hello world" to notepad

// close notepad after LED change
waitLED(ANY);           // wait for a single LED change
press("ALT F4");        // ALT+F4 shortcut to close notepad

//as we changed content, there will be a confirmation dialog before notepad exits
delay(500);             // wait for the confirmation dialog
press("RIGHT");         // move focus to next button (don't save) with RIGHT ARROW
press("SPACEBAR");      // confirm dialog with space

Isto deveria ter funcionado. Isto significa que é possível iniciar HIDScripts armazenados a partir de todas as aplicações que suportam comandos de shell ou a partir de um simples script bash, utilizando o cliente CLI do P4wnP1 A.L.O.A.

Seria até possível iniciar o script remotamente a partir de um cliente CLI compilado para Windows. Supondo que o host Windows consiga alcançar o P4wnP1 A.L.O.A. via WiFi e o IP do P4wnP1 esteja definido como `172.24.0.1`, o comando adequado seria assim:```
P4wnP1_cli.exe --host 172.24.0.1 hid run tutorial1.js

O script fornecido acima, de fato, seria executado toda vez que o P4wnP1 for conectado a um host USB. Mas o script não é muito robusto, porque há um segundo `waitLED` envolvido, que espera até que o notepad.exe seja fechado novamente.

Fazer dessa forma envolve vários problemas. Por exemplo, se o P4wnP1 for desconectado antes de "Hello world" ser digitado, o `waitLED` agora bloqueante seria aquele antes de `press("ALT F4")` e a execução continuaria exatamente neste ponto do HIDScript assim que o P4wnP1 for conectado novamente a um host USB (talvez diferente).

Um critério definitivo de invalidação para a abordagem escolhida é o seguinte problema: O requisito de que o script deve ser executado apenas uma vez após conectar o P4wnP1 a um host USB não poderia ser atendido, pois pressionar NUM LOCK várias vezes reiniciaria o script repetidamente.

Então, como resolvemos isso?

#### Vamos apresentar as TriggerActions

A solução para o problema são as chamadas "TriggerActions". Como o nome sugere, este conceito de workflow do P4wnP1 A.L.O.A. dispara ações com base em gatilhos predefinidos.

Para ter uma ideia do que estou falando, vá até a aba "TRIGGER ACTIONS" no webclient. Dependendo da configuração atual, pode já existirem TriggerActions. Não nos preocupamos com as TriggerActions existentes agora.

Clique no botão "ADD ONE" e uma nova TriggerActions deve ser adicionada e instantaneamente aberta no modo de edição.
A nova TriggerAction está desabilitada por padrão e precisa ser habilitada para se tornar editável. Então alternamos o interruptor de habilitação.

Agora, no menu suspenso chamado "Trigger", a opção "USB gadget conectado ao host" deve ser selecionada. A ação deve ter uma predefinição de "escrever entrada de log" selecionada. Deixamos assim e clicamos no botão "Update".

A TriggerAction recém-adicionada deve estar visível na visão geral das TriggerActions agora (a de maior ID) e mostrar um resumo do Trigger selecionado e da Ação selecionada em formato legível.

Para testar se a TriggerAction recém-definida funciona, navegue até a aba "Event Log" do webclient.
Certifique-se de que o webclient está aberto via WiFi (não USB ethernet). Aplique alimentação externa ao P4wnP1, desconecte-o do host USB e conecte-o novamente. Uma mensagem de log deve ser enviada ao cliente toda vez que o P4wnP1 for conectado a um host USB, imediatamente.

Se você repetiu isso algumas vezes, talvez tenha notado que o gatilho "USB gadget conectado ao host" dispara muito rápido (ou em um estágio inicial da fase de enumeração USB). Para ser mais preciso: Quando este gatilho dispara, sabe-se que o P4wnP1 foi conectado a um host USB, mas não há garantia de que o host USB conseguiu carregar todos os drivers de dispositivo USB necessários.
**Na verdade, é muito improvável que o driver do teclado USB esteja carregado quando o gatilho dispara. Temos que manter isso em mente.**

Antes de prosseguirmos com nossa tarefa, fazemos um teste adicional. Voltando para a aba "TriggerAction" e pressionamos o pequeno botão azul com aparência de lápis para nossa TriggerAction recém-criada. Acabamos no modo de edição novamente.

Desta vez, ativamos a opção `One shot`. Volte para o "Event Log" depois, e novamente, desconecte e reconecte o P4wnP1 do host USB. Desta vez a TriggerAction deve disparar apenas uma vez. Não importa quantas vezes o P4wnP1 seja reconectado ao host USB depois, nenhuma nova mensagem de log indicando uma conexão USB deve ser criada.

Vale a pena mencionar que uma TriggerAction "One shot" não é excluída após o gatilho disparar. Em vez disso, a TriggerAction é desabilitada novamente. Reabilitar permite reutilizar uma TriggerAction sem redefini-la. Nada é perdido até que o botão vermelho "lixeira" seja pressionado em uma TriggerAction, que excluirá a respectiva TriggerAction.

**Aviso: Se o botão de exclusão de uma TriggerAction for clicado, a TriggerAction é excluída permanentemente sem confirmação adicional.**

Neste ponto, vamos fazer o óbvio. Editamos a TriggerAction criada e selecionamos "iniciar um HIDScript" em vez de "escrever entrada de log" para a ação a ser executada. Além disso, desabilitamos "one-shot" novamente. Um novo campo de entrada chamado "nome do script" é mostrado. Clicar neste campo de entrada abre uma caixa de diálogo de seleção para todos os HIDScripts armazenados, incluindo nosso HIDScript `tutorial1.js` criado anteriormente.

*Antes de testarmos se isso funciona, deixe-me fazer uma observação rápida sobre a ação "escrever entrada de log": O P4wnP1 A.L.O.A. não mantém registro de quais gatilhos já foram disparados. Isso significa que as entradas de log criadas por uma ação "escrever entrada de log" são entregues a todos os clientes ouvintes, mas não são armazenadas pelo serviço P4wnP1 (por várias razões). O webclient, por outro lado, armazena a entrada de log até que o próprio webclient seja recarregado. O mesmo se aplica a eventos relacionados a trabalhos HIDScript. Se um HIDScript termina (com sucesso ou erro), um evento é enviado para todos os webclients atualmente abertos. Em resumo, cada webclient tem um estado de execução que contém mais informações do que o próprio serviço principal. Se o estado de execução do webclient crescer demais (uso excessivo de memória), basta recarregar o cliente para limpar as informações de estado "históricas". Se o serviço principal se comportasse da mesma forma e armazenasse todas as informações históricas, rapidamente ficaria sem recursos. Portanto, este conceito se aplica à maioria dos subsistemas do P4wnP1 A.L.O.A.*

Agora de volta à nossa tarefa. Temos uma TriggerAction pronta, que deve disparar nosso HIDScript toda vez que o P4wnP1 for conectado a um host USB.

Dependendo do host USB alvo, isso funciona de forma mais ou menos confiável. Na minha configuração de teste, não funcionou de jeito nenhum e há um motivo:

Vamos revisar as primeiras linhas do nosso HIDScript:```
// Starting notepad
press("WIN R");         // Windows key + R, to open run dialog
delay(500);             // wait 500ms for the dialog to open
type("notepad.exe\n"); 	// type 'notepad.exe' to the run dialog, append a RETURN press
... snip ...

Armazenar o script modificado sob o mesmo nome (`tutorial1`) sobrescreve o HIDScript anterior sem confirmação adicional, como já foi mencionado. Portanto, não há necessidade de ajustar nosso TriggerAction, pois o nome do HIDScript ao qual o TriggerAction se refere não mudou.

Com essa pequena alteração, tudo deve funcionar como esperado e o script deve ser acionado toda vez que nos conectarmos a um host USB, mas executado apenas uma vez.

Agora, se o P4wnP1 for reiniciado ou perder energia, nosso HIDScript sobreviveria, porque o armazenamos de forma persistente, mas o TriggerAction desapareceria. Escusado será dizer que os TriggerActions também podem ser armazenados de forma persistente.

O botão "store" na aba "TriggerAction" funciona exatamente como o do editor de HIDScript. Deve-se notar que *todos os TriggerActions atualmente ativos* serão armazenados se o diálogo "store" for confirmado (incluindo os desabilitados).
A melhor prática é excluir todos os TriggerActions que não pertencem à tarefa no escopo atual antes de armazenar (eles já devem ter sido armazenados anteriormente, se necessário) e armazenar apenas o pequeno conjunto de TriggerActions relevantes para a tarefa atual, usando um nome adequado. Existem duas opções para carregar de volta os TriggerActions armazenados para os ativos:
 - "load & replace" limpa todas as ações de acionamento ativas e carrega apenas as armazenadas
 - "load & add" mantém os TriggerActions já ativos e adiciona os armazenados. Assim, "load & add" pode ser usado para construir um conjunto complexo de TriggerActions a partir de conjuntos menores. O conjunto resultante pode então, novamente, ser armazenado.

Por enquanto, devemos armazenar apenas nosso único TriggerAction, que inicia nosso HIDScript. O nome que usamos para armazenar é novamente `tutorial1` e não entrará em conflito com o HIDScript chamado `tutorial1`.

Confirme o armazenamento bem-sucedido clicando no botão "load&replace" na aba "TriggerAction". O conjunto de TriggerActions armazenado deve estar na lista e nomeado como `tutorial1`.

**Aviso: Os diálogos "load" de TriggerAction permitem excluir TriggerActions armazenados clicando no botão vermelho "lixeira" ao lado de cada ação. Clicar no botão exclui permanentemente o respectivo conjunto de TriggerActions, sem confirmação adicional**

Neste ponto, poderíamos excluir com segurança nosso TriggerAction da aba "TriggerActions" (!!não com o botão de lixeira de um dos diálogos de load!!).

Com o TriggerAction excluído dos ativos, nada acontece se desconectarmos e reconectarmos o P4wnP1 do host USB.

De qualquer forma, o conjunto de TriggerActions armazenado `tutorial1` persistirá em reinicializações e poderá ser recarregado a qualquer momento.

Em vez de recarregar o conjunto de TriggerActions usando o webclient, tentaremos fazer isso usando o cliente CLI.

Vamos dar uma olhada rápida na tela de ajuda do subcomando `template deploy`:```
root@kali:~# P4wnP1_cli template deploy -h
Deploy given gadget settings

Usage:
  P4wnP1_cli template deploy [flags]

Flags:
  -b, --bluetooth string         Deploy Bluetooth template
  -f, --full string              Deploy full settings template
  -h, --help                     help for deploy
  -n, --network string           Deploy network settings template
  -t, --trigger-actions string   Deploy trigger action template
  -u, --usb string               Deploy USB settings template
  -w, --wifi string              Deploy WiFi settings templates

Global Flags:
      --host string   The host with the listening P4wnP1 RPC server (default "localhost")
      --port string   The port on which the P4wnP1 RPC server is listening (default "50051")

A TriggerAction que dispara o HIDScript nas conexões de host USB está agora carregada novamente e deve ser exibida na 
aba TriggerActions do webclient. Se o P4wnP1 A.L.O.A. estiver conectado a um host USB, o script deve ser executado novamente.

Armazenar, carregar e implantar templates é um dos dois conceitos principais por trás do fluxo de trabalho de automação do P4wnP1, 
o outro são as já conhecidas TriggerActions. Vale mencionar que não apenas conjuntos de TriggerActions podem ser
armazenados e carregados como templates, mas também as TriggerActions podem ser usadas para implantar templates já armazenados, se 
isso fizer sentido.

Revisitando nossas tarefas, parece que todos os requisitos definidos agora são atendidos:
- digitamos "Hello world" no editor de um host Windows USB 
- o editor é aberto pelo P4wnP1, não manualmente pelo usuário
- o editor é fechado automaticamente, quando um dos LEDs do teclado alterna uma vez
- toda vez que o P4wnP1 é conectado a um host USB, esse comportamento se repete
- o HIDScript é executado apenas uma vez, a menos que o P4wnP1 seja reconectado ao host USB, mesmo que alterações sucessivas nos LEDs do teclado ocorram
- se o P4wnP1 for reiniciado, o mesmo comportamento pode ser recuperado carregando o conjunto de TriggerActions armazenado (que novamente 
se refere ao HIDScript armazenado). Isso pode ser alcançado com um único comando CLI ou com um simples "load&add" ou
"load&replace" da aba de trigger action do webclient.

Mais uma vez, vamos adicionar objetivos adicionais:
- deve ser garantido que a configuração USB tenha a funcionalidade de teclado habilitada (a configuração atual não faz
isso e a TriggerAction não pode iniciar o HIDScript caso o teclado USB esteja desabilitado)
- a configuração criada deve ser aplicada na inicialização do P4wnP1 A.L.O.A., sem a necessidade de carregar manualmente o conjunto de TriggerActions. A configuração deve sobreviver a uma reinicialização do P4wnP1.

Para alcançar os dois objetivos adicionais, temos que mergulhar em um novo tópico e ...

#### Introduzir Master Templates e Startup Master Template

Antes de examinar os Master Templates, fazemos algo que ainda não fizemos, porque tudo funcionou conforme o esperado 
até agora: Definimos uma configuração USB válida, correspondente à nossa tarefa!

- número de série do dispositivo: 123456789
- nome do produto do dispositivo: Auto Writer
- fabricante do dispositivo: The Creator
- ID do Produto: 0x9876
- ID do Fornecedor: 0x1D6B
- funções USB habilitadas
  - Teclado HID
  - Mouse HID
  
Vamos dar uma olhada na tela de uso do comando CLI, que pode ser usado para implantar essas configurações, primeiro:``` 
root@kali:~# P4wnP1_cli usb set -h
set USB Gadget settings

Usage:
  P4wnP1_cli usb set [flags]

Flags:
  -e, --cdc-ecm               Use the CDC ECM gadget function
  -n, --disable               If this flag is set, the gadget stays inactive after deployment (not bound to UDC)
  -h, --help                  help for set
  -k, --hid-keyboard          Use the HID KEYBOARD gadget function
  -m, --hid-mouse             Use the HID MOUSE gadget function
  -g, --hid-raw               Use the HID RAW gadget function
  -f, --manufacturer string   Manufacturer string (default "MaMe82")
  -p, --pid string            Product ID (format '0x1347') (default "0x1347")
  -o, --product string        Product name string (default "P4wnP1 by MaMe82")
  -r, --rndis                 Use the RNDIS gadget function
  -s, --serial                Use the SERIAL gadget function
  -x, --sn string             Serial number (alpha numeric) (default "deadbeef1337")
  -u, --ums                   Use the USB Mass Storage gadget function
      --ums-cdrom             If this flag is set, UMS emulates a CD-Rom instead of a flashdrive (ignored, if UMS disabled)
      --ums-file string       Path to the image or block device backing UMS (ignored, if UMS disabled)
  -v, --vid string            Vendor ID (format '0x1d6b') (default "0x1d6b")

Global Flags:
      --host string   The host with the listening P4wnP1 RPC server (default "localhost")
      --json          Output results as JSON if applicable
      --port string   The port on which the P4wnP1 RPC server is listening (default "50051")

O resultado do comando (um pouco longo) mostra as configurações USB resultantes. Vamos verificar a aba "USB settings" do 
webclient para confirmar que foram aplicadas. Todas as alterações devem ser refletidas, se nada deu errado.

Embora seja perfeitamente possível implantar uma configuração USB usando a CLI, existem vários benefícios em usar o webclient 
em vez da CLI. Neste caso:
- alterar as configurações pelo webclient é mais fácil e conveniente
- o webclient mantém um estado interno das configurações, o que permite definir configurações USB sem realmente implantá-las (a
CLI, por outro lado, só poderia manipular configurações implantando-as. Isso, novamente, redefine toda a pilha USB do 
P4wnP1 e toda a funcionalidade dependente. Por exemplo, um HIDScript já em execução seria interrompido ou as interfaces de rede USB 
seriam reimplantadas)
- as configurações atuais do webclient podem ser armazenadas em um template persistente, sem implantá-las previamente
- o cliente CLI (atualmente) não é capaz de armazenar configurações USB

No nosso caso atual, é obviamente uma escolha melhor usar o webclient para as alterações necessárias nas configurações USB. 
A vantagem da abordagem CLI (que já usamos aqui): Como a CLI nos forçou a implantar as configurações USB, pudemos
confirmar que estão funcionando, antes de armazená-las em um template persistente.

Vamos continuar com o armazenamento das configurações USB:

Novamente clicamos no botão "store", desta vez na aba "USB settings". Mais uma vez chamamos o template `tutorial1` (não
há conflito com o template TriggerAction armazenado com o mesmo nome, porque um namespace diferente é usado para 
configurações USB).


Agora temos dois novos templates armazenados persistentemente::
1) um template para o conjunto TriggerAction, chamado `tutorial1`
2) um template para as configurações USB, também chamado `tutorial1`

Supondo que o estado (das configurações USB atuais, TriggerActions ou ambos) mudou de alguma forma, poderíamos recarregar ambos os 
armazenamentos de uma só vez, emitindo o seguinte comando CLI:```
P4wnP1_cli template deploy --usb tutorial1 --trigger-actions tutorial1

### Canal oculto WiFi

O canal oculto WiFi não foi portado para Go e não faz parte do núcleo do P4wnP1. De qualquer forma, a funcionalidade legada é fornecida. Para que o canal oculto funcione, várias condições devem ser atendidas:
- uma injeção de teclas deve ser aplicada ao cliente alvo para injetar o stage1
- o stage1 carrega o stage2 através de uma versão simplificada do canal oculto HID, portanto, um dispositivo USB HID especial deve ser fornecido e um servidor especial de canal oculto HID deve ser iniciado no P4wnP1 para fornecer o stage2
- um segundo servidor deve ser iniciado e fazer interface com o firmware WiFi modificado, para gerenciar clientes que se conectam através do canal oculto WiFi e fornecer acesso interativo ao shell para esses clientes (o servidor é uma aplicação de console destinada a ser executada em um multiplexador de terminal, como `screen`)

Todas as condições mencionadas podem ser cumpridas usando o conjunto de recursos do P4wnP1 A.L.O.A., se os componentes necessários (stager HID, servidor do canal oculto WiFi, agente cliente a ser entregue) forem fornecidos.

Realizar essa tarefa com o P4wnP1 A.L.O.A. é um ótimo exemplo de suas capacidades. Além disso, ajuda a distinguir o que o P4wnP1 A.L.O.A. deve ser e o que não deve ser.

P4wnP1 A.L.O.A. não se destina a:
- ser uma ferramenta "armamentizada"
- fornecer payloads RTR, que poderiam ser executados por qualquer pessoa, sem entender o que está acontecendo ou quais riscos estão envolvidos

P4wnP1 A.L.O.A. se destina a:
- ser uma plataforma flexível, de baixo custo e tamanho de bolso
- servir como facilitador para tarefas como a descrita aqui
- apoiar a prototipagem, teste e execução de todos os tipos de tarefas relacionadas a USB, comumente usadas durante pentests ou engajamentos de redteam, sem fornecer uma solução estática finalizada

Em certo sentido, a pasta `/usr/local/P4wnP1/legacy` abriga as ferramentas externas necessárias para executar o canal oculto WiFi (nomeadamente o servidor WiFi, o servidor stager do canal oculto HID e o agente cliente do canal oculto WiFi). Esses componentes podem ser considerados partes externas (não pertencem ao núcleo do P4wnP1 A.L.O.A.).

Além disso, o P4wnP1 A.L.O.A. fornece uma configuração que utiliza os componentes fornecidos para fazer as seguintes coisas:
- ataque drive-by contra hosts Windows para entregar código cliente em memória para baixar stage2 via canal oculto HID, baseado em injeção de teclas (HIDScript)
- iniciar a injeção de teclas assim que o P4wnP1 for conectado a um host USB (TriggerAction emitindo HIDScript)
- trazer o stager, que entrega o agente cliente do canal oculto WiFi via canal oculto HID, assim que a injeção de teclas começar (TriggerAction executando um script bash, que por sua vez inicia o servidor externo)
- trazer o servidor do canal oculto WiFi quando necessário (mesmo TriggerAction e BashScript)
- implantar uma configuração USB que fornece um teclado USB (para permitir injeção de teclas) e um dispositivo HID bruto adicional (serve como canal oculto para entrega do stage2) - as configurações USB são armazenadas em um template de configurações
- implantar uma configuração WiFi, que permite acesso remoto ao P4wnP1, para permitir interação com o frontend CLI do servidor do canal oculto WiFi - as configurações WiFi são armazenadas em um template de configurações
- fornecer um ponto único de entrada para implantar todas as configurações necessárias de uma só vez (feito por um Master Template, que consiste em configurações WiFi adequadas, configurações USB adequadas e as TriggerActions necessárias para iniciar o HIDScript)

O Master Template é chamado "wifi covert channel". Ao implantá-lo a partir da aba "generic settings" do webclient ("DEPLOY STORED" do Master Template Editor) o P4wnP1 A.L.O.A. está configurado pronto para executar todos os passos descritos.

Assim que for reconectado a um host USB, ele deve começar a digitar o stage1 e os servidores correspondentes são iniciados internamente.
De uma sessão SSH (por exemplo, via WiFi), o servidor do canal oculto WiFi pode ser acessado usando `screen -d -r wifi_c2` para interagir com clientes que se conectaram de volta através do canal oculto WiFi.

Como a injeção de teclas depende do layout de idioma do host USB, o HIDScript correspondente chamado `wifi_covert_channel.js` tem uma variável `language` que pode ser usada para ajustar o layout do teclado em uso. Além disso, há uma variável chamada `hide` (falso por padrão). Se `hide` for definido como verdadeiro, a janela do console no cliente fica oculta enquanto stage1 é digitado. Isso, novamente, destaca como tarefas complexas podem ser reduzidas a uma simples variável booleana, graças ao HIDScript e ao motor JavaScript subjacente.

O demo "wifi covert channel" fornecido com os Master Templates do P4wnP1 também pode ser usado como Master Template de inicialização, pois o acesso WiFi ainda é possível e, assim, a configuração pode ser alterada novamente, remotamente a qualquer momento.

O BashScript envolvido, que é chamado de uma TriggerAction, é um bom exemplo de quão flexível o cliente CLI pode se tornar. Como o stager HID precisa saber em qual arquivo de dispositivo escutar (aquele que representa o dispositivo HID genérico), mas esta informação só está disponível em tempo de execução (depende das funções de gadget USB habilitadas), o script solicita ao CLI que informe o dispositivo HID correto executando `hidraw=$(P4wnP1_cli usb get device raw)`.

O BashScript completo está hospedado na pasta `/usr/local/P4wnP1/scripts`, como todos os scripts bash que devem ser acessíveis a partir de TriggerActions.

### Bluetooth NAP

O P4wnP1 fornece funcionalidade de rede baseada em Bluetooth sobre o Bluetooth Network Encapsulation Protocol (BNEP). A funcionalidade atualmente mais interessante é o Bluetooth Network Access Point (NAP), que permite acesso remoto Bluetooth baseado em IP ao P4wnP1, por exemplo, a partir de dispositivos móveis.

Para usar este recurso, algumas coisas devem ser conhecidas:
- A interface de rede Bluetooth, chamada `bteth`, pode ser configurada e modelada como as outras interfaces de rede (webclient ou CLI)
- Para permitir acesso NAP a partir de um Android (iPhone não testado), o dispositivo móvel não só precisa se conectar, mas adicionalmente o P4wnP1 precisa fornecer um IP adequado para o gateway padrão na interface `bteth` via DHCP. Isso ocorre porque o dispositivo móvel deseja usar o NAP como gateway para a Internet (que seria o uso pretendido). Se o NAP em si não fornecesse um gateway, o Android não faria mais solicitações após o DHCP D.O.R.A. A maneira mais fácil de contornar isso é instruir o servidor DHCP a fornecer o IP da própria interface `bteth` como gateway padrão (opção 3 do DHCP). Mesmo que não haja uma conexão upstream real, isso funcionou durante meus testes - pois o dispositivo móvel precisa acessar o gateway com comunicação de camada 3 para "telefonar para casa". Mesmo que testes de conectividade sucessivos falhem, a conexão de camada 3 funcional persiste. Isso permite, por exemplo, acesso SSH via Bluetooth. Com "High Speed" ativado, o webclient também funciona muito bem.
- Para permitir o emparelhamento baseado em PIN, o Simple Secure Pairing (SSP) deve ser desativado. Se o SSP estiver ativado, o agente de emparelhamento em execução confirma todas as chaves de acesso (o que significa ainda menos segurança do que com o emparelhamento PIN legado, pois qualquer dispositivo pode se conectar). Talvez uma caixa de diálogo de confirmação para emparelhamento baseado em passkey via SSP seja implementada para o CLI/webclient no futuro, mas atualmente isso está fora do escopo. Recomendo fortemente desativar "discoverable" e "bondable" se o SSP estiver em uso, assim que o dispositivo pretendido tiver emparelhado.
- Outra desvantagem de ter o SSP desativado é que "High Speed" não seria utilizável para conexões Bluetooth (ou para ativar o High Speed, o emparelhamento deve ser feito com SSP). Sem "High Speed" ativado (usa quadros 802.11 para comunicação), levaria cerca de 10 minutos para solicitar o webclient; com high speed ativado, leva alguns segundos. No entanto, usar SSH e o cliente CLI através de um NAP sem "High Speed" deve ser aceitável.
- As configurações padrão da interface de rede Bluetooth (`bteth_startup`) e as configurações padrão do Bluetooth (`startup`) devem permitir acesso "Low Speed" via SSH com emparelhamento PIN legado. O PIN é `1337` e pode ser alterado no webclient.

### Grupos de TriggerAction

As TriggerActions vêm com uma ótima capacidade de roteamento chamada "Groups". Não consegui criar uma demonstração do recurso a tempo, mas estou planejando incluir um exemplo de um contador binário de 4 bits baseado em LED (usando GPIOs, um interruptor alternador e 4 LEDs).

A ideia dos grupos é a seguinte:

Considere que você deseja ter 4 TriggerActions (TAs) disparando no mesmo Trigger (por exemplo "on attached to USB host"). Você poderia conseguir isso criando 4 TAs, cada uma com o Trigger "on attached to USB host".

Alternativamente, você poderia criar uma TriggerAction que envia o valor `1` para um grupo chamado `"connected"` quando o "on attached to USB host" ocorre. Agora você define suas outras 4 TriggerActions para disparar quando o valor `1` for recebido em um grupo chamado `"connected"`. O resultado seria o mesmo e não faria muito sentido por enquanto (na verdade, precisa de mais uma TriggerAction). O único efeito positivo, por enquanto, é que as TriggerActions são ligeiramente mais legíveis, graças ao nome do grupo, que pode ser escolhido livremente.

Agora a primeira coisa avançada que você poderia fazer é executar o seguinte comando CLI:```
P4wnP1_cli trigger send --group-name=connected --group-value=1

Isso pode ser usado para executar scripts a partir de TriggerActions, utilizando a CLI (com todo seu poder, como GPIO).


Trabalho em andamento, seções faltantes:
- HIDScript Trigger variables (variáveis fornecidas aos HIDScripts acionados por TriggerActions)
- HIDScript helpers (funções do powershell)
- HIDScript demo snake (mouse)
- USB Mass storage (genimg helper)

## 4. Resgate: Ajuda, não consigo acessar o P4wnP1 A.L.O.A. pois estraguei a configuração

P4wnP1 A.L.O.A. não protege você de configurações incorretas, que o tornam inutilizável (assim como um console root não te protegeria de executar `rm -rf /`).

Caso você tenha estragado tudo, aqui estão algumas ideias de como consertar:

### Backup do banco de dados

Antes de fazer alterações críticas em uma configuração ainda funcional do P4wnP1, crie um backup do banco de dados. Isso pode ser feito a partir da aba 'Configurações Genéricas' do webclient ou através da CLI, com o comando `P4wnP1_cli db backup`. O backup será armazenado na pasta `/usr/local/P4wnP1/db` com o nome escolhido. A função 'restore' ou o comando `P4wnP1_cli db restore` pode ser usado para restaurar um backup existente. Um backup contém todos os templates armazenados (USB, WiFi, Rede, Bluetooth, TriggerActions, MasterTemplates) e o Master Template de Inicialização que foi definido. O backup não inclui HIDScripts ou BashScripts, pois ambos são armazenados como arquivos para facilitar a edição.

### Não tenho backup e estraguei tudo

Quando o P4wnP1 A.L.O.A. inicia, ele verifica se existe um banco de dados. Se o banco de dados não existir, ele preenche um novo banco de dados baseado em um backup inicial que acompanha o P4wnP1 A.L.O.A.

O backup inicial está armazenado em `/usr/local/P4wnP1/db/init.db` e **nunca deve ser deletado ou sobrescrito**.

Para forçar o P4wnP1 a recriar, o banco de dados atual deve ser deletado. Isso pode ser feito montando o cartão SD do P4wnP1 A.L.O.A. em um sistema capaz de escrever partições EXT.

Feito isso, delete a pasta `/usr/local/P4wnP1/store` da partição raiz do cartão SD. Isso deleta o banco de dados e, portanto, força a recriação na próxima inicialização do P4wnP1.

### Tenho um backup, mas não consigo acessar o P4wnP1 para restaurá-lo

Se você não conseguir restaurar um banco de dados existente por não ter acesso, ainda pode seguir os passos de 'Não tenho backup e estraguei tudo'. Além de deletar a pasta `/usr/local/P4wnP1/store`, substitua o arquivo `/usr/local/P4wnP1/db/init.db` pelo do seu backup (certifique-se de ter uma cópia de backup do init.db).

Isso deve recriar seu banco de dados personalizado quando o P4wnP1 for reiniciado.

### Estraguei o Master Template de Inicialização do meu backup

Se você tem um backup cujo Master Template de Inicialização não funciona, você precisa fazer alguns passos adicionais, pois não é possível alterar o Template de Inicialização diretamente em um backup.

Primeiro siga os passos de 'Não tenho backup e estraguei tudo' que recriam o banco de dados inicial do P4wnP1. Após uma reinicialização do P4wnP1, você deve conseguir acessar o webclient do P4wnP1 remotamente novamente.

Vá para as 'Configurações Genéricas' e restaure seu próprio backup (aquele com o Master Template de Inicialização errado).

O 'Master Template de Inicialização' deve mostrar seu Master Template 'quebrado' como selecionado. Se não for o caso, recarregue a aba do navegador que hospeda o webclient.

Novamente, navegue até a aba 'Configurações Genéricas' e selecione um Master Template de Inicialização que seja conhecido por funcionar.

Neste ponto, você deve estar pronto para reiniciar.

### Nenhum dos acima ajudou

Desculpe, parece que você terá que recriar seu cartão SD do P4wnP1 A.L.O.A. a partir de uma imagem limpa.

## 5. Créditos

Em construção, ordem aleatória

- @JohanBrandhorst (troca próxima sobre gRPC-web via gopherjs, implementação ridiculamente rápida de 'websocket para server streaming', solicitação de funcionalidade)
- @steevdave, @_binkybear (scripts de build Kali, discussão e troca contínua)
- @Re4sonKernel (Suporte na movimentação das alterações de kernel do P4wnP1 para um repositório bem mantido e popular, colaboração em correções do Bluez)
- @SymbianSyMoh (Inspiração para reativação de ataque HID sem reinicialização)
- @quasarframework (poderia listar isso como bibliotecas de terceiros, mas o trabalho feito aqui é insano; a aparência do webclient do P4wnP1 é mais ou menos baseada nos componentes padrão desta bela biblioteca)
- @CyberArms (um dos primeiros apoiadores do P4wnP1, escritor do melhor tutorial e até livros sobre tais tópicos)
- @LucaBongiorni (não apenas um dos primeiros apoiadores, ele faz em hardware o que só consigo fazer em software; ele dá palestras sobre o tópico USB e honra soluções de código aberto, no geral um grande cara e uma inspiração)
- @evilsocket (seu blog me impulsionou para Go, um grande desenvolvedor OSS, leia seu código e você saberá o que quero dizer)
- @RoganDawes e @Singe da @SensePost (caras inspiradores)
- @Swiftb0y (Apoiador inicial, criador do 'antigo' Wiki do P4wnP1, testador inicial de ideias para o P4wnP1 A.L.O.A.)
- @marcaruel (discussão sobre detecção de borda GPIO usando periph.io)

## 6. Tarefas e suporte

Esta não é uma lista de tarefas completa, mas alguns marcos ainda estão pendentes e eu ficaria feliz em receber algum apoio da comunidade nisso
- Portar a funcionalidade completa de canal encoberto HID para o núcleo Go (estou sozinho nisso)
- **adicionar comando de configuração Bluetooth para CLI**
- Criar layouts de teclado adicionais (atualmente br, de, es, fr, gb, it, ru e us são suportados)
- estender funcionalidade Bluetooth para permitir conexão com outros dispositivos detectáveis (autenticação e confiança)
- mover funcionalidade WiFi KARMA de ferramenta Python dedicada para o núcleo do P4wnP1 (com suporte ao webclient)
- Criar documentação completa para HIDScript (basicamente só falta a parte do mouse)
- Criar documentação completa para o P4wnP1 (esperando pela comunidade)
- Livrar-se de uma dependência restante do docker netlink (veja o README da pasta `netlink`)

Nota sobre Bluetooth: 

P4wnP1 funciona com ligações personalizadas à API Bluez. Embora a API Bluez suporte Low Energy (GATT, emulação de periféricos etc.), não está planejado integrar essa funcionalidade no P4wnP1 A.L.O.A.

Nota sobre Nexmon: 

P4wnP1 utiliza nexmon. A maioria das pessoas conhece nexmon como uma modificação de firmware que permite ativar o modo monitor e injeção de pacotes para chips WiFi Broadcom (incluindo o BCM43430a1, usado pelo Raspberry Pi Zero W). Mas nexmon é mais, é um framework que permite modificar blobs de firmware ARM (após um pouco de engenharia reversa), com patches escritos em linguagem C de alto nível. P4wnP1 usa este framework para aplicar patches personalizados ao firmware WiFi, que habilitam suporte KARMA baseado em hardware e suporte de firmware (assim como driver) para o canal encoberto WiFi. Não é objetivo destas modificações fornecer modo monitor ou suporte a injeção adequados para a interface WiFi integrada. Embora a funcionalidade legada de modo monitor do nexmon esteja incluída no firmware WiFi atual, ela é considerada 'errônea', pois interfere com a funcionalidade WiFi padrão usada pelo P4wnP1 (crashes se a interface for usada no modo estação, etc.).

## 7. Direitos Autorais

    P4wnP1 A.L.O.A.
    Copyright (C) 2018 Marcus Mengs

    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program.  If not, see <http://www.gnu.org/licenses/>.