Indigo Virgo

Caríssimo(a) Leitor(a),

Peço que leia com atenção e visão crítica, sempre tomando em conta que:

· Devido ao uso de indentação em múltiplos níveis, a visualização deste artigo poderá não ser perfeita em smartphones, sendo preferíveis dispositivos com telas no formato 16:9 (notebooks, desktops etc.).

· Este artigo não é opinativo, mas apenas didático.

· Este artigo não versa sobre tipos ou usos específicos de programas de computador, ou sistemas de processamento digital.

Durante a leitura, não se intimide com termos técnicos ou com a lógica das soluções apresentadas para os exemplos propostos, pois tudo sempre estará didaticamente explicado em linguagem simples (não-informatiquês).

Ficarei feliz se você usar a compreensão aqui adquirida para formar opinião sobre eficiência, precisão e confiabilidade de quaisquer aplicativos, programas, serviços, ou Sistemas Computacionais.

Porém, se você se enquadra em pelo menos uma destas condições...

· Não suporta ler atentamente mais do que meia página de texto;

· Pratica "leitura diagonal", supondo assimilar conteúdos didáticos;

· Detesta ter de aprender para formar opinião própria;

· Prefere conceitos e opiniões mainstream;

· Pretende apenas verificar se o autor seria pró ou contra isto ou aquilo...

Por favor, não leia este artigo.
Aplique o seu tempo a procurar entretenimento na Internet.

Autor

Formação em engenharia de produção (Poli-USP), atuando desde 1977 em análise, arquitetura, desenvolvimento, programação, implantação e gestão de sistemas (software, hardware, infraestrutura), dos jurássicos mainframes Burroughs & IBM, aos mais recentes dispositivos computacionais, com expertise teórica e prática em Sistemas Operacionais [ MS-DOS 2.0 ~ 4.1, PC-MOS/386, IBM OS/2, Windows 3.1 ~ 11, Linux, Android, Chrome OS ], Linguagens e Ambientes de Programação e Desenvolvimento [ Assemblers Z80, 8086, 8088, i286 ~ i486, AMD k5 ~ Ryzen, Moto68000, Intel Core® i3 ~ i9, Fortran, Cobol, Algol, HTML, php, inúmeros RDBMS, MS.SQL Server, ApacheWebServer, C, C++, C#, MS.Visual Studio, MS.NET, ASP, Python, Java, JavaScript, e outras in between ].

Conteúdo

1. Objetivos

2. A quem se destina

3. Texto didático e simples sobre Dispositivos Computacionais e Software

3.1. O que são Dispositivos Computacionais?

Exemplos

3.2. Elementos em comum

3.2.1. Camada dos softwares Aplicativos

Como se produz um Aplicativo

A - Produção do Código-Fonte

A.1. Exemplo de Código-Fonte bastante tosco

A.2. Código-Fonte pode conter atividades maliciosas?

A.3. Rotinas Externas podem conter atividades maliciosas?

B - Compilação e Linkagem do Código-Fonte

B.1 - Compilação do Aplicativo

B.2 - Linkagem do Aplicativo

B.3. Linkagem das Rotinas Externas

B.4. Scripts de Compilação e Linkagem podem conter atividades maliciosas?

C – Carga do Programa Executável

C.1. Carga de Programa Executável pode ensejar atividades maliciosas?

3.2.2. Camada do Sistema Operacional

3.2.2.1. Exemplos de sistemas operacionais bem conhecidos

3.2.2.2. Sistemas Operacionais podem conter atividades maliciosas?

3.2.3. Camada de Hardware

3.2.3.1. Exemplos de elementos de hardware

3.2.3.2. Firmware – Chips contendo software

3.2.3.3. Firmware pode conter atividades maliciosas?

4. Tornando este tema mais interessante

4.1. Imaginando um conjunto de necessidades a serem atendidas por um Aplicativo

4.2. Solução proposta por um Aplicativo Fruticrático

4.3. Divagando sobre atividades maliciosas no Aplicativo Fruticrático

4.3.1. Imaginando motivos para atividades maliciosas

4.3.2. Imaginando a concretização de uma atividade maliciosa

4.3.3. Tentando constatar uma atividade maliciosa

4.3.3.1. Constatando por meio de testes práticos

4.3.3.2. Constatando por análise de software

4.3.3.3. Constatando por outras análises

5. Sistemas Computacionais

6. Sistemas Computacionais de Missão Crítica

7. Requisitos Mínimos para Validação de Confiabilidade de Sistemas Computacionais

Homologação

8. Conclusões?

1. Objetivos

Apresentar didaticamente explanações extremamente simplificadas sobre Dispositivos Computacionais e seus Aplicativos, quando utilizados no âmbito de um Sistema Computacional (doravante, simplesmente por "Sistema" – v. definição no item 5.).

Proporcionar um entendimento básico dos atributos de precisão, segurança, confiabilidade e lisura (doravante, simplesmente "Confiabilidade") de Aplicativos e Sistemas, bem como de seu processo de utilização para qualquer finalidade específica.

Proporcionar um entendimento básico da relevância de cada elemento físico e lógico de Aplicativos e Sistemas, para a efetividade dos mencionados atributos de Confiabilidade.

2. A quem se destina

Ao público em geral, leigo em Tecnologia da Informação, interessado em aprender, compreender e formar opinião independente sobre os aspectos de Confiabilidade de Aplicativos e Sistemas.

3. Texto didático e simples sobre Dispositivos Computacionais e Software

3.1. O que são Dispositivos Computacionais?

Consideremos apenas tipos de Dispositivos Computacionais mais conhecidos, que trataremos simplesmente por "Dispositivos".

Exemplos

· Smartphones

· Tablets

· Notebooks

· Computadores desktop

· Caixas eletrônicos

· Terminais de consulta (em shoppings, por exemplo)

· Terminais de apostas lotéricas

· Terminais para pesquisa de preferências ou satisfação dos Clientes

3.2. Elementos em comum

Todos estes Dispositivos possuem elementos em comum, que podemos simplificadamente considerar como "camadas":

1. Camada dos softwares Aplicativos

2. Camada do Sistema Operacional

3. Camada de Hardware

Vejamos mais detalhadamente cada uma destas camadas...

3.2.1. Camada dos softwares Aplicativos

Em essência, esta camada contém os programas de computador através dos quais os usuários interagem com os Dispositivos.

Exemplos de softwares Aplicativos:

o Assistentes pessoais

o Editores de textos

o Planilhas de cálculo

o Aplicativos contábeis

o Aplicativos comerciais

o Aplicativos de IRPF, IRPJ e correlatos

o Softwares para pesquisa de preferências ou satisfação dos Clientes

Como se produz um Aplicativo

Lembrando que estamos tratando de programas (softwares) destinados a dispositivos comuns, como os já mencionados, podemos dizer que, da fase de produção à fase de utilização, todo software passa por estas etapas:

A - Produção do Código-Fonte

B - Compilação do Código-Fonte

C – Carga do Programa Executável

Precisaremos detalhar de forma simples as três etapas deste processo, para compreendermos que todos os elementos envolvidos são de extrema relevância para a Confiabilidade de um Sistema.

A - Produção do Código-Fonte

Utilizando linguagens de programação (p.ex., Phyton, C, C++ etc.), programadores escrevem o Código-Fonte, basicamente um conjunto de arquivos de texto contendo seqüências lógicas de instruções a serem executadas pelo Dispositivo (lembrando: smartphone, tablet, notebook, terminais de serviços etc.

Apenas para oferecer uma visão breve e simples do conteúdo lógico de um Código-Fonte, vejamos um Aplicativo hipotético, escrito com a também hipotética linguagem de programação "TodoMundoEntende".

Nota

Na verdade, se usássemos uma linguagem de programação real, cada linha deste Aplicativo hipotético corresponderia a um conjunto de linhas de difícil leitura por pessoas leigas em programação.

Por exemplo, na linguagem de programação C++, a linha 1 do nosso Aplicativo seria escrita assim:

clrscr()

#include <iostream>
using namespace std;

int main() {
cout << "Quais os seus números da sorte hoje?";
return 0;
}

A.1. Exemplo de Código-Fonte bastante tosco

Aplicativo Números da Sorte

1. Limpa a tela e escreve: Quais os seus números da sorte hoje?

2. Aguarda alguém tocar na tela.

3. Chama a Rotina Externa [Teclado Numérico].

4. Escreve: Quantos números de 1 a 100 você deseja sortear?

5. Aguarda o usuário digitar um número.

Se número digitado = zero, volta ao passo 1.

Se número digitado = 100

Escreve: "Não é necessário sortear!"
Aguarda 5 segundos
Volta ao passo 1

Se número digitado estiver entre 1 e 99, prossegue...

Se nada for digitado, aguarda 10 segundos e retorna ao passo 1.

6. Cria a variável [Quantidade]

Memoriza a quantidade de números desejada.

7. Desenha grid de tamanho adequado à quantidade de números.

Exemplo...

8. Cria o arquivo [Já Sorteados] para armazenar os números gerados.

9. Cria a variável [Contador], para um contador de números gerados.

Inicializa a variável [Contador] com o valor zero.

10. Chama a Rotina Externa [Gera Número Aleatório]

Recebe em retorno um número gerado.

11. Verifica se o número gerado já está no arquivo [Já Sorteados].

Em caso positivo, gerou um número repetido...

Volta ao passo 10.

Em caso negativo

Armazena o número gerado no arquivo [Já Sorteados]
Prossegue...

12. Exibe o número aleatório gerado, em uma posição livre do grid.

13. Incrementa o valor da variável [Contador]

(Contador = Contador + 1).

14. Verifica se já gerou a quantidade de números desejados

Se [Contador] < [Quantidade]

Continuar gerando números >>> Retorna ao passo 10.

Se [Contador] = [Quantidade]

Já gerou os números desejados >>> Prossegue...

15. Exibe os botões [Imprimir] e [Encerrar]

Botão [Encerrar]

Prossegue para o passo 16

Botão [Imprimir]

Imprime o grid contendo os números sorteados.
Exemplo, para um usuário que solicitou 18 números:

15	27	17	01	45	03
25	55	56	99	08	02
20	60	07	23	05	98

Prossegue para o passo 16.

Se nenhum botão for pressionado em 30 segundos...

Prossegue para o passo 16.

16. Encerramento

Apaga a variável [Contador].
Apaga a variável [Quantidade].
Apaga o arquivo [Já Sorteados].
Retorna ao passo 1

No link abaixo, implementei uma versão deste Aplicativo, adaptada para ser executada em uma guia do navegador (programada com HTML e JavaScript).

• Para usá-la mais de uma vez, recarregue a página do Aplicativo.
• Para voltar a este artigo, feche a guia do Aplicativo.

App – Números da sorte

A.2. Código-Fonte pode conter atividades maliciosas?

Qualquer atividade maliciosa pode ser programada direta e explicitamente no Código-Fonte do chamado Programa Principal de um software.

Programa Principal (como aquele apresentado em A.1) é aquele que determina a sequência lógica principal das atividades de um Aplicativo, recorrendo a chamadas a Rotinas Externas para realizar atividades subsidiárias.

Entretanto, identificar trechos de códigos potencialmente maliciosos não é tarefa trivial, principalmente devido a fatores como:

· A baixa legibilidade de determinadas linguagens de programação, mesmo para profissionais da área.

· A extensão do Código-Fonte examinado, que pode chegar a milhões de linhas de código (linhas de texto contendo instruções), em determinados sistemas.

· O possível uso de técnicas de mascaramento adotadas pelos eventuais "desenvolvedores maliciosos", incluindo a inserção de bugs (erros de lógica) para "despistamento".

Empreitadas deste tipo exigem profissionais de TI extremamente capacitados, utilizando ferramentas (softwares) de análises estática e dinâmica, durante o tempo que se faça necessário para adquirir entendimento pleno de todos os aspectos do funcionamento do Código-Fonte examinado.

Ferramenta de análise estática: analisa simplesmente o texto e a lógica do Código-Fonte.

Ferramenta de análise dinâmica: dentre inúmeras outras funções, analisa o Código-Fonte do Aplicativo durante a sua execução, mostrando simultaneamente cada linha de código que estiver sendo executada.

A.3. Rotinas Externas podem conter atividades maliciosas?

Notemos que o nosso Código-Fonte bastante tosco chama as rotinas externas [Teclado Numérico] e [Gera Número Aleatório], as quais, neste caso, devem executar as tarefas definidas pelos seus nomes.

Todavia, cada Rotina Externa é, na verdade, um outro Programa de Computador, com o seu próprio Código-Fonte, seu próprio processo de Compilação etc.

Portanto, mesmo sendo (em geral) dedicadas a atividades específicas, subsidiárias ao Programa Principal do Aplicativo, as Rotinas-Externas podem, sim, incluir atividades maliciosas nos seus Códigos-Fonte.

B - Compilação e Linkagem do Código-Fonte

Para que o Dispositivo (smartphone, tablet, notebook, terminal de serviços etc.) possa "entender" e executar as instruções do Código-Fonte do Aplicativo, é necessário transformar esse Código-Fonte (um simples arquivo de texto) em um Programa Executável.

Este processo de transformação ocorre (usualmente) em 2 etapas:

· Compilação

· Linkagem

B.1 - Compilação do Aplicativo

Esta primeira etapa consiste em "entregar" o Código-Fonte (arquivo de texto aqui denominado "Aplicativo.txt") a um Compilador específico para a linguagem de programação usada.

Compilador - é um programa de computador capaz de ler as instruções (textuais) do Código-Fonte e traduzi-las para uma linguagem binária compatível com a máquina (Dispositivo).

Durante este processo, para traduzir o Código-Fonte do Aplicativo.txt, o Compilador obedece a uma sequência definida por um Script de Compilação (um conjunto de instruções textuais, também produzido pelos desenvolvedores do Aplicativo).

Nosso Aplicativo.txt transforma-se então em um arquivo escrito em linguagem binária, que batizaremos como Aplicativo.bin (o sufixo do nome de arquivo varia muito, mas utilizaremos "bin" para facilidade de identificação).

Este arquivo Aplicativo.bin contém as instruções originais do Código-Fonte, agora traduzidas para linguagem binária, algo que, entretanto, ainda não é um programa que possa ser executado pela máquina (Dispositivo).

Lembrando que isto é uma simplificação da simplificação...

B.2 - Linkagem do Aplicativo

Este é o segundo passo para a transformação do Código-Fonte em Programa Executável.

Para que a máquina (Dispositivo) possa executar as instruções traduzidas em linguagem binária, contidas no arquivo Aplicativo.bin, é necessário transformá-lo em um Programa Executável.

Basicamente, "entrega-se" o arquivo binário Aplicativo.bin a um Linker.

Linker - é um programa de computador capaz de ler as instruções binárias do arquivo Aplicativo.bin e construir o Programa Executável Aplicativo.exe.

B.3. Linkagem das Rotinas Externas

Durante o processo de Linkagem (construção do Programa Executável), o Linker obedece a um Script de Linkagem (outro conjunto de instruções textuais, também produzido pelos desenvolvedores do Aplicativo) para organizar e interconectar as instruções binárias do Aplicativo.bin, bem como incorporar e conectar, onde necessário, as Rotinas Externas eventualmente "chamadas" pelo Código-Fonte.

No momento da Linkagem, tais Rotinas Externas (que podem ter sido desenvolvidas por terceiros, ou pelos próprios programadores do Aplicativo) precisam já estar presentes no ambiente de Compilação e Linkagem, ou ser trazidas de um ambiente externo para o ambiente de Compilação e Linkagem

(via Internet, por exemplo).

Neste nosso exemplo, durante a construção do executável Aplicativo.exe, o Linker procurará os arquivos binários (bin) das Rotinas Externas:

· [Teclado Numérico]

· [Gera Número Aleatório]

B.4. Scripts de Compilação e Linkagem podem conter atividades maliciosas?

Sim!

Bastaria que, ao construir o Programa Executável do Aplicativo, um desses Scripts incorporasse, por exemplo, uma Rotina Externa maliciosa ou um segmento de código-fonte malicioso, similar àqueles que veremos no item 4.3.

C – Carga do Programa Executável

O Aplicativo, sob a forma de Programa Executável, será carregado (gravado) e utilizado no Dispositivo (neste nosso exemplo, um hipotético Terminal de serviços).

C.1. Carga de Programa Executável pode ensejar atividades maliciosas?

Cabe enfatizar que, se compilarmos duas versões "parecidas" do mesmo Código-Fonte (por exemplo, uma delas com e outra sem um determinado trecho de Código-Fonte), não teremos como descobrir "quem é quem" simplesmente examinando os respectivos Programas Executáveis.

Sim, existem ferramentas e procedimentos de descompilação, para se chegar ao Código-Fonte original de determinado Programa Executável.

Todavia, comparar o Código-Fonte assim obtido e o Código-Fonte supostamente original é um processo trabalhoso e complexo, que nem sempre resulta em conclusões inequívocas.

Assim, faz-se indispensável ter certeza de que o Programa Executável carregado no Dispositivo seja exatamente aquele cujo processo de produção tenha sido completamente monitorado e aprovado (Código-Fonte, Rotinas Externas, Compilação, Linkagem e respectivos Scripts).

Evidentemente, podemos também conceber testes de funcionamento dos Programas Executáveis supostamente diferentes, objetivando detectar diferenças de comportamento sob as mesmas condições de uso, tarefa esta também complexa e que nem sempre resulta em conclusões inequívocas.

3.2.2. Camada do Sistema Operacional

3.2.2.1. Exemplos de sistemas operacionais bem conhecidos

o Windows

o Android

o iOS

o Unix

o Linux

O Sistema Operacional compreende um enorme e complexo conjunto de elementos de software responsáveis por operar a parte física do Dispositivo e prover ao Aplicativo todos os recursos físicos e lógicos de que precise para funcionar.

(Lembrando, estamos exemplificando com apenas um Aplicativo).

Constitui-se de uma infinidade de programas gerenciadores e controladores de cada recurso físico e lógico existente no Dispositivo, incluindo também (por exemplo) o conjunto de interfaces de vídeo, áudio, entrada e saída de dados por dispositivos como teclados, digitalizadores, câmeras, displays etc. etc. etc.

3.2.2.2. Sistemas Operacionais podem conter atividades maliciosas?

Pelo fato de ser a camada "sobre a qual" o Aplicativo "roda" (funciona) e da qual o Aplicativo depende para obter acesso aos recursos físicos e lógicos de que necessite, o Sistema Operacional detém o poder de realizar qualquer coisa, quer solicitada pelo Aplicativo, quer totalmente à revelia do Aplicativo.

Sim, diversas linguagens de programação possuem a capacidade de acessar diretamente o Hardware, mas isto não elimina o mencionado "poder" do Sistema Operacional.

3.2.3. Camada de Hardware

Constitui-se de todos os elementos físicos (e elementos lógicos associados) existentes no Dispositivo.

3.2.3.1. Exemplos de elementos de hardware

· Placa-mãe

· Processador (CPU)

· Chips de Firmware, incluindo:

o BIOS

o Relógio de Tempo Real (RTC)

o Chips de segurança proprietários

o Chips geradores de números aleatórios

· Chipset (eventualmente incluído na classe de firmware)

· Memória de trabalho (RAM)

· Memórias de armazenamento interno (HDD, SSD & outras)

· Memórias externas (flash drives, cartões etc.)

· Interfaces de comunicação (Ethernet, Wi-Fi, Bluetooth, Firewire, USB etc.)

· Interfaces de entrada e saída, como teclado, mouse, touchpad, touchscreen, leitor de digitais, câmera, display, áudio, terminais de vários tipos etc.

· Fonte de alimentação, bateria etc.

3.2.3.2. Firmware – Chips contendo software

A camada de Hardware incorpora também chips regraváveis contendo softwares de controle e gerenciamento denominados Firmware, significando que todo e qualquer Firmware presente no dispositivo deverá ser plenamente conhecido e estar sob absoluto controle dos gestores de um Sistema Computacional.

3.2.3.3. Firmware pode conter atividades maliciosas?

Códigos maliciosos eventualmente inseridos em componentes de Firmware seriam capazes de executar quaisquer atividades insuspeitadas, de forma imperceptível e à revelia dos Aplicativos e do próprio Sistema Operacional.

4. Tornando este tema mais interessante

4.1. Imaginando um conjunto de necessidades a serem atendidas por um Aplicativo

· Uma Rede de Centrais de Abastecimento Regionais pretende otimizar as compras e o fornecimento de frutas para os comerciantes que as revendem aos Clientes.

· Um Aplicativo de pesquisa irá monitorar diariamente a preferência dos Clientes por determinadas frutas.

· O Aplicativo será utilizado em milhares de Terminais de Pesquisa (Dispositivos) instalados em sacolões e setores de hortifruti de supermercados, por todo o país.

· Cada estabelecimento ou comerciante possuirá somente um Terminal.

· Como a preferência do Cliente poderá depender da oferta de frutas encontrada em cada estabelecimento, decidiu-se que um mesmo Cliente poderá votar mais de uma vez por dia em estabelecimentos diferentes, mas não em um mesmo estabelecimento.

· Todos os Terminais serão idênticos, consistindo basicamente de um computador simples, dotado de touchscreen (tela sensível ao toque), áudio, conexão com a Internet, Relógio de Tempo Real sincronizado pela Internet, Número de Identificação do Terminal (ID) gravado em firmware, botão liga/desliga, botão de reset embutido.

· Em cada região, todos os Terminais enviarão diariamente os seus resultados a um computador instalado na respectiva Central de Abastecimento Regional, o qual totalizará os dados e emitirá relatórios para gestão de compras e fornecimentos de frutas.

· Os computadores das Centrais de Abastecimento Regionais enviarão diariamente as suas totalizações aos computadores da Administração da Rede, onde trabalham os Gestores da Rede.

4.2. Solução proposta por um Aplicativo Fruticrático

Este seria o Código-Fonte escrito com a hipotética linguagem de programação "TodoMundoEntende".

Relembrando a Nota já apresentada em 3.2.1 - A

Na verdade, se usássemos uma linguagem de programação real, cada linha deste Aplicativo hipotético corresponderia a um conjunto de linhas de difícil leitura por pessoas leigas em programação.

Aplicativo Fruticrático

1. Terminal ligado e inicializado.

2. Aplicativo inicializado.

Obtém o ID do Terminal, gravado em Firmware ( Exemplo: 61812145 )

Obtém a Localização do Terminal (consulta uma Tabela de Localizações)

Cria novo arquivo [Registro de Preferências]

Nome do arquivo = Número do Terminal-Data-Pref

Exemplo: 61812145-02102022-Pref

Cria novo arquivo [Log de Terminal]

Nome do arquivo = Número do Terminal-Data-Log

Exemplo: 61812145-02102022-Log

[Log de Terminal] – Registra "Início de funcionamento" + data + hora

3. Verifica se o Terminal foi desligado corretamente (v. passo 16)

Se não encontrar o sinalizador de desligamento correto (SDC)

Ocorreu um Reset
[Log de Terminal] - Registra a ocorrência de Reset no dia anterior.

Se encontrar o sinalizador de desligamento correto (SDC)

Não ocorreu um Reset
[Log de Terminal] - Registra desligamento correto no dia anterior.
Deleta o arquivo SDC

Prossegue para o passo 4

4. Teste de Terminal

Exibe os botões [Uso normal] e [Testar Terminal]

Se pressionar [Testar Terminal]

[Log de Terminal] – Registra "Terminal teste - início+data+hora"

Botão [Encerrar teste] permanece disponível na base da tela.

Terminal opera normalmente, até que se pressione [Encerrar teste].

A qualquer momento, se [Encerrar teste] for pressionado:

[Log de Terminal] – Registra "Terminal teste - fim+data+hora"
Vai para o passo 12 - Encerramento diário – Execução

Se pressionar [Uso normal]

[Log de Terminal] – Registra "Terminal uso normal+data+hora"

Remove os botões [Uso normal] e [Testar Terminal]

Prossegue para o passo 5

5. Tela Inicial

Limpa a tela
Exibe a imagem de uma cesta de frutas
Escreve "Qual a sua fruta preferida?"
Escreve "Toque na tela para iniciar."
Aguarda alguém tocar na tela.

6. A partir deste passo, o botão [Sair] permanece disponível na base da tela.

A qualquer momento, se o Cliente pressionar [Sair]:

Registra este evento no [Log de Terminal]
Interrompe o processo
Volta para a Tela Inicial – passo 5

7. Identificação do Cliente

7.1. Chama a Rotina Externa [Teclado Numérico]

7.2. Escreve: "Informe o seu CPF"

7.3. Chama a Rotina Externa [Valida CPF]

7.4. Se CPF inválido

Informa "CPF inválido. Por favor, tente novamente"
Limpa o campo CPF + aguarda 3 segundos + volta ao passo 7.2

7.5. Se CPF válido

Prossegue para o próximo passo

8. Verifica se Cliente já participou da pesquisa

(neste estabelecimento, nesta data).

Consulta o arquivo [Registro de Preferências], pelo CPF do Cliente

Se já participou

o Escreve "Você já participou hoje. Gratos pela colaboração!"

o Aguarda 10 segundos e volta para a Tela Inicial – passo 5

Se não participou

o Prossegue para o próximo passo

9. Seleção da fruta preferida

Cria a variável [Preferência atual]

Exibe uma scrollable list (lista suspensa) em ordem alfabética.

Selecione a sua fruta preferida.

*Sua Preferência*	*Número*
*Abacate*	01
*Abacaxi*	02
*Ameixa*	03
*Banana*	04
*Goiaba*	05
*Laranja*	06
*Maçã*	07
*Mamão*	*...*
*Melancia*	*....*
*Melão*	*...*
*Morango*	*...*
*Pêra*	*...*
*...*	*...*

O Cliente deverá rolar a lista de seleção e tocar no nome da fruta selecionada.

Se selecionar uma fruta

Destaca o nome da fruta, na lista de seleção.
Exibe os botões [Confirma] e [Corrige]

Se pressionar [Confirma]

Grava nome e número da fruta, na variável [Preferência atual]
Exemplo: Ameixa 03
Prossegue para o passo 10.

Se pressionar [Corrige]

Volta para a rolagem da lista de seleção.

Se não pressionar nem [Confirma], nem [Corrige]

Aguarda 60 segundos
Grava preferência em branco, na variável [Preferência atual]

Exemplo: Branco 00

Prossegue para o passo 10.

Se não selecionar uma fruta e parou a rolagem da lista de seleção.

Aguarda 60 segundos
Grava preferência em branco, na variável [Preferência atual]

Exemplo: Branco 00

Prossegue para o passo 10.

10. Gravação da preferência do Cliente

[Registro de Preferências] - grava os seguintes dados:

CPF do Cliente
Data e hora da participação
Nome e número da fruta escolhida, contidos em [Preferência Atual]

Apaga a variável [Preferência atual]

[Log de Terminal] - Registra evento "Cliente participou"

inclusive para preferência em branco

Chama a Rotina Externa [Musiquinha]

Escreve: "Agradecemos pela sua participação!"

11. Encerramento Diário – Verificação

Verifica a data e o horário

Se não chegou o momento de encerrar

Volta para a Tela Inicial – passo 5

Se já chegou o momento de encerrar

Prossegue para o próximo passo.

12. Encerramento Diário – Execução

Limpa a tela e escreve "Encerrando... Aguarde..."

[Log de Terminal] – Registra data e hora do encerramento.

Chama a Rotina Externa [Processa Preferências]

o Processa o [Registro de Preferências]

· arquivo de exemplo: 61812145-02102022-Pref

[Log de Terminal] – Registra conclusão de [Processa Preferências]

Escreve: "Relatório Gerencial de Preferências"

Gera e imprime o relatório, a partir do [Registro de Preferências]

[Log de Terminal] – Registra a emissão do Relatório Gerencial

13. Transmissão de dados

Limpa a tela e escreve "Transmitindo dados..."

[Log de Terminal] – Registra início do evento [Transmissão de dados]

Chama a Rotina Externa [Conecta Central]

Estabelece conexão (criptografada) com o computador central

Fecha os arquivos [Registro de Preferências] e [Log de Terminal]

Chama a Rotina Externa [Transmite dados]

Envia arquivos [Registro de Preferências] e [Log de Terminal]

(arquivo de exemplo: 61812145-02102022-Pref )

(arquivo de exemplo: 61812145-02102022-Log )

Chama a Rotina Externa [Conecta Central]

Encerra a conexão (criptografada) com o computador central

Reabre o arquivo [Log de Terminal]

[Log de Terminal] – Registra conclusão da Transmissão de Dados

Escreve "Transmissão de dados concluída."

14. Limpa a tela e escreve: "Relatório Gerencial de Atividade do Terminal"

Gera e imprime um Relatório Gerencial

A partir do arquivo [Log de Terminal]

[Log de Terminal] – Registra a emissão do Relatório Gerencial

15. Histórico de dados

(Arquiva dados dos últimos 30 dias de operação do Terminal.)

Move para o Histórico os arquivos

[Registro de Preferências] ( exemplo: 61812145-02102022-Pref )
[Log de Terminal] ( exemplo: 61812145-02102022-Log )

Exclui arquivos com mais de 30 dias de idade.

[Log de Terminal] – Registra a manutenção do Histórico de dados.
[Log de Terminal] – Registra entrada na fase de Desligamento.

16. Desligamento

Limpa a tela e escreve:

"Processamento encerrado. Desligando o Terminal."

Fecha os arquivos [Registro de Preferências] e [Log de Terminal]
Grava um arquivo Sinalizador de Desligamento Correto (SDC).
Desliga o Terminal.

4.3. Divagando sobre atividades maliciosas no Aplicativo Fruticrático

Para enfatizar a relevância de cada elemento e de cada fase (do desenvolvimento à utilização) pertinentes ao chamado "ciclo de vida" de qualquer software, analisemos o nosso Aplicativo Fruticrático, em busca de possibilidades de atividades maliciosas.

4.3.1. Imaginando motivos para atividades maliciosas

· Suponhamos que a nossa Rede de Centrais de Abastecimento compre frutas de um fornecedor que tenha interesse em melhorar o "desempenho" de determinadas frutas em detrimento de outras, nas pesquisas realizadas pelos Terminais Fruticráticos.

· Suponhamos ainda que tal fornecedor esteja ciente de que essa "melhora de desempenho" seria vista como aceitável em determinadas regiões, porém vista com desconfiança em outras regiões.

· Suponhamos finalmente que esse fornecedor tenha influência sobre desenvolvedores (internos ou externos) do nosso Sistema de Terminais, de modo que tais "profissionais" incluíssem algum código malicioso no Código-Fonte do Aplicativo ou em alguma das suas Rotinas Externas.

4.3.2. Imaginando a concretização de uma atividade maliciosa

Assumindo as más intenções das hipóteses acima, imaginemos como um talentoso desenvolvedor poderia inserir em nosso Aplicativo um código malicioso que atendesse aos anseios do fornecedor desonesto.

Notemos que o Código-Fonte chama estas Rotinas Externas:

· [Teclado Numérico]

· [Valida CPF]

· [Musiquinha]

· [Processa Preferências]

· [Conecta Central]

· [Transmite dados]

Observemos que:

§ A Rotina Externa [Processa Preferências] é chamada no passo 12 do nosso exemplo.

§ O passo 12 ocorre durante o Encerramento Diário de uso dos Terminais.

§ O passo 12 ocorre antes da Emissão dos Relatórios Gerenciais e da Transmissão de Dados.

§ Assim sendo, torna-se impossível usar tais Relatórios para "conferir" o arquivo [Registro de Preferências].

Portanto, uma forma "bastante convidativa" para o talentoso desenvolvedor adulterar os resultados do Aplicativo, seria programar a Rotina Externa [Processa Preferências] para:

Consultar o [Log de Terminal] e verificar se Terminal está sob teste.

Terminal sob teste

Processar normalmente o [Registro de Preferências] (totalizações etc.)

Terminal sob uso normal

Consultar o ID do Terminal
Consultar uma tabela de IDs versus localização dos Terminais
Determinar a localização do Terminal
Consultar uma Tabela de alterações programadas, conforme a localização do Terminal.

Por exemplo:

Região	Alteração no [Registro de Preferências]
N	Agressiva
NE	Agressiva
CO	Nenhuma
SE	Branda
S	Moderada

Processar o [Registro de Preferências], aplicando a alteração programada.

"Devolver" ao Programa Principal o arquivo [Registro de Preferências].

Considere-se ainda que, para alterar os resultados globais das pesquisas em cada região, seria necessário que um percentual elevado dos Terminais (preferivelmente todos) estivesse utilizando o Aplicativo contendo código malicioso.

Isto significa que, para lograr tal feito, não bastaria ao fornecedor desonesto mobilizar, por exemplo, uma ação de hackers que conseguissem invadir alguns Terminais para alterar o software em uns poucos estabelecimentos.

4.3.3. Tentando constatar uma atividade maliciosa

Suponhamos que, na Administração da Rede de Centrais de Abastecimento (a contratante deste Sistema de Terminais Fruticráticos), os Gestores, analisando os resultados das pesquisas, viessem a suspeitar do "desempenho muito melhorado" de determinadas frutas, em determinadas regiões geográficas.

Suponhamos ainda que, por quaisquer motivos, esses Gestores tenham total controle sobre os computadores totalizadores das Centrais Regionais e total confiança nos resultados recebidos dos mesmos, de modo que sua desconfiança recaísse sobre os inocentes Terminais Fruticráticos.

4.3.3.1. Constatando por meio de testes práticos

Embora esses Gestores não tivessem como saber, a priori, que os Terminais Fruticráticos, assim como a sua Rotina Externa maliciosa [Processa Preferências], operam de forma maliciosa sob condições normais de uso, porém de forma irrepreensível sob condições de teste, é evidente que quaisquer bons especialistas em software os aconselhariam a testar os Terminais procurando bloquear essa possível "dupla personalidade".

Assim, a forma prática de detectar uma adulteração dos resultados seria:

· Nas "regiões geográficas suspeitas", testar uma quantidade representativa de Terminais sob condições normais de uso, ou seja, sem utilizar o botão [Testar Terminal] e sem admitir qualquer interferência que permitisse aos Terminais detectar que estariam sendo testados.

· Durante estes testes, registrar as preferências dos Clientes, utilizando algum tipo de recurso de aferição externo aos Terminais, quer fosse imprimindo a tela a cada preferência confirmada, quer fosse filmando, ou o que seja...

4.3.3.2. Constatando por análise de software

Considerando que os mencionados Gestores não teriam como saber, a priori, em qual camada (software, sistema operacional, hardware...) dos Terminais poderia existir algum código malicioso, seria necessário compor uma equipe de especialistas altamente qualificada, munida das ferramentas (softwares) de análise que considerassem necessárias, e exigir dos fornecedores dos softwares o acesso pleno e irrestrito aos Códigos-Fonte do Aplicativo Fruticrático, de suas Rotinas Externas, do Sistema Operacional Utilizado etc.

Como já mencionado em 3.2.1 item A.2, dependendo da extensão e da complexidade dos Códigos-Fonte, esta tarefa poderá se estender no tempo, acarretar custos elevados, produzir resultados que certamente serão questionados por "experts" (quase sempre ineptos formuladores de opiniões de aluguel...)

4.3.3.3. Constatando por outras análises

É possível também aplicar métodos estatísticos aos resultados das pesquisas, estabelecer correlações, comparações de resultados atuais e históricos, de resultados regionais e globais, análise de resultados de diferentes Terminais na mesma região etc.

Entretanto, estas análises post-mortem poderiam, quando muito, caracterizar fortes indícios, mas não prova irrefutável da ocorrência de atividades maliciosas.

5. Sistemas Computacionais

De maneira abrangente e simplificada, um Sistema Computacional (genérico) consiste de um conjunto de Aplicativos (softwares) inter-relacionados, o hardware (equipamentos), o ambiente tecnológico em que esses softwares irão "rodar", bem como os recursos humanos responsáveis pela sua implantação, operação e manutenção.

6. Sistemas Computacionais de Missão Crítica

Já, Sistemas de Missão Crítica são aqueles concebidos para prover serviços computacionais essenciais a instituições, entidades, órgãos públicos, negócios etc., primando por garantir (aos dados, aos processos e aos resultados) as seguintes características:

· não-interrupção;

· precisão;

· qualidade;

· segurança;

· confiabilidade;

· rastreabilidade (traceability).

Evidentemente, para garantir tais capacidades e características, é necessário que a gestão de um Sistema de Missão Crítica tenha total controle sobre todos os aspectos de desenvolvimento, implantação, manutenção, utilização, segurança etc.:

· do software utilizado em sua operação;

· do hardware utilizado em sua operação;

· do ambiente tecnológico em que irá operar;

· de todos os recursos humanos envolvidos.

7. Requisitos Mínimos para Validação de Confiabilidade de Sistemas Computacionais

Podemos agora enunciar um conjunto básico de requisitos de confiabilidade para Sistemas Computacionais em geral,

Homologação

Em geral, homologação se refere à adequação dos softwares (Sistema) às necessidades dos usuários e à sua compatibilidade em relação ao ambiente tecnológico em que o Sistema operará.

Para não entrarmos em aspectos como assinaturas digitais, criptografia etc., utilizaremos o termo "homologação" para designar um conjunto de providências (exames técnicos, testes, auditorias, due diligences, ou o que seja...) garantidoras de que, uma vez examinados, testados, aprovados e instalados, o software, o sistema operacional e o hardware não mais serão modificados, durante todo o período de sua utilização.

R E Q U I S I T O S
R E Q U I S I T O S

A - Camada do Aplicativo
Que todos os Códigos-Fonte sejam submetidos a um processo de homologação realizado durante o tempo que se faça necessário, com o uso de ferramentas de análise estática e dinâmica reconhecidas pela comunidade global de desenvolvedores de software, como confiáveis, adequadas e eficientes para o tipo de Código-Fonte e o volume de linhas de código a serem analisadas.
Que todos e quaisquer Elementos Externos (p.ex., Bibliotecas e APIs de terceiros) sejam também homologados, pelos mesmos meios utilizados na homologação dos Códigos-Fontes do Sistema.
Que os Códigos-Fonte homologados, bem como os Elementos Externos homologados, sejam exatamente os mesmos submetidos ao processo de Compilação para gerar os Programas Executáveis do Sistema.
Que os Compiladores e Linkers usados para gerar os Programas Executáveis sejam produtos amplamente utilizados pela comunidade global de desenvolvedores de software, sem quaisquer alterações e que, uma vez selecionados, sejam homologados.
Que os Compiladores e Linkers usados para gerar os Programas Executáveis sejam exatamente os mesmos homologados.
Que, durante os processos de Compilação, os Compiladores e Linkers incorporem aos Programas Executáveis somente os elementos homologados (Códigos-Fonte e Elementos Externos), garantindo-se a não incorporação de quaisquer elementos não-homologados, quer presentes no ambiente de Compilação, quer trazidos de ambientes externos (p.ex., via Internet).
Para cumprimento do item anterior, que todos os Scripts de Compilação e Linkagem sejam também homologados, adotando-se medidas para garantir que tais Scripts homologados, e somente eles, sejam utilizados em Tempo de Compilação.
Que sempre se possa aferir que os Programas Executáveis carregados nos Dispositivos sejam exatamente os mesmos gerados nos passos anteriores e devidamente homologados.
Se desejar compreender esta camada em detalhe, volte ao tópico 3.2.1, itens A e B. Caso contrário, prossiga para o próximo item.

B - Camada do Sistema Operacional
Que o Sistema Operacional tenha todos os seus componentes completa e detalhadamente homologados, incluindo-se interfaces do usuário, serviços, drivers e runtimes, kernel etc.
Que o Sistema Operacional utilizado seja exatamente aquele homologado.
Se desejar compreender esta camada em detalhe, volte ao tópico 3.2.2. Caso contrário, prossiga para o próximo item.

C - Camada do Hardware
Que os softwares contidos em chips regraváveis (Firmware) sejam completa e detalhadamente homologados. (p.ex., BIOS, chips de segurança, Real Time Clock (RTC) etc.)
Que em cada unidade de Hardware existam recursos de validação capazes de garantir que os Firmwares presentes sejam exatamente aqueles que foram homologados.
Que não existam quaisquer recursos capazes de regravar ou modificar Firmware, em quaisquer partes do Código-Fonte, ou do Sistema Operacional, ou de mídias externas eventualmente usadas no Sistema.
Se desejar compreender esta camada em detalhe, volte ao tópico 3.2.3. Caso contrário, prossiga para o próximo item.

E - Em relação aos procedimentos externos ao Sistema
Que o Sistema Operacional e os Programas Executáveis carregados nos Dispositivos sejam exatamente os mesmos gerados a partir dos Códigos-Fonte homologados.
Se desejar compreender esta camada em detalhe, volte ao tópico 3.2.1, item C.

8. Conclusões?

Em minha modesta opinião, como procurei demonstrar ao longo deste artigo, para podermos apenas supor a existência de um Sistema Computacional 99,999% seguro e confiável (deixando 0,001% por conta dos bugs...), fazem-se necessários:

· O contínuo atendimento a um extenso conjunto de Requisitos Mínimos para Validação de Confiabilidade de Sistemas, pelos seus gestores, desenvolvedores, operadores e stakeholders. E aqui, a expressão "contínuo atendimento" significa que os mencionados Requisitos Mínimos devem ser aplicados não apenas às versões iniciais de Software, Bibliotecas Externas, Compiladores, Linkers, Sistemas Operacionais, Hardware, Firmware etc., mas também a todos e quaisquer updates, upgrades, ou mínimas alterações que venham a sofrer.

· A excelência das práticas de gestão de desenvolvimento, gestão de pessoal técnico, gestão de recursos internos e externos e elementos de segurança, conduzindo também à certeza de que todos e quaisquer recursos utilizados no Sistema sejam exatamente aqueles avaliados e aprovados segundo os mencionados Requisitos Mínimos para Validação de Confiabilidade.

· A sistemática "abertura" do Sistema para reexames técnicos completos e plenos sob todos os aspectos.

Espero haver contribuído para que os(as) Leitores(as) tenham uma compreensão clara e simplificada deste tema.

Por favor, não reproduza este artigo, no todo ou em parte.
Isto comprometeria o design (formatação, indentação etc.) planejado para favorecer a didática.
Quaisquer partes do texto perderão seu significado, se reproduzidas fora do contexto.
Se desejar compartilhar, apenas copie o link deste post.
O autor lhe agradece por haver lido o artigo e por respeitar este pedido.

25 de novembro de 2024

Broken inside

7 de abril de 2023

Crônica inútil sobre Algoritmos da Vergonha

· Atenção exclusiva

· Precisam de rehab

· Roteiro da felicidade

· Inteligência artificial sem alma

28 de fevereiro de 2023

Do Código-Fonte ao Sistema Computacional Confiável, para leigos em informática.