Pesquisar este blog

terça-feira, 18 de abril de 2023

Ofuscamento de código fonte - Source Code Obfuscation - TCC Pós graduação em Desenvolvimento de Sistemas Mainframe - BUGA

Proteção de Código Fonte via Ofuscamento – TCC - Faculdade ULT - Desenvolvimento Sistemas Mainframe

Resumo:
No desenvolvimento de software, principalmente em aplicações da era da internet, o ofuscamento de código é importante para proteger a propriedade intelectual. A legislação brasileira ainda não oferece proteção total contra cópias, modificações e uso não autorizado de programas. Técnicas de ofuscamento servem como camada extra de defesa, dificultando engenharia reversa e cópia indevida, especialmente em sistemas legados como mainframes em COBOL. Este trabalho apresenta conceitos, exemplos e códigos, ilustrando vantagens e desvantagens de cada técnica.

Palavras-chave: ofuscamento, código fonte, mainframe, engenharia reversa, proteção, patente, direitos autorais, COBOL, código redundante.

Documento completo do TCC:
Acessar o PDF do TCC

Lâminas da apresentação:
Acessar slides da apresentação


Tava vendo aqui, faz tanto tempo que ainda era meu nome morto.


Vídeo 1: Minha apresentação do TCC
Diploma de Pós-Graduação – Walter Buga Ramos
Figura 1: Meu diploma!

Transcrição da Apresentação do TCC – Proteção de Código Fonte via Ofuscamento

Olá, eu sou aluna do curso de Desenvolvimento de Sistemas Mainframe da ULT e esta é a apresentação do meu trabalho de conclusão de curso.

Vamos começar! Vou falar um pouquinho sobre o meu trabalho, que é sobre ofuscamento de código. Então, vou abordar um pouco sobre direito autoral, engenharia reversa, mecanismos de proteção contra engenharia reversa, as técnicas de ofuscamento de código (que é o foco do trabalho) e as conclusões que podemos tirar.

Proteção de software no Brasil

O que temos hoje para proteção de software no Brasil? Existem leis para proteger o código como obra literária. Você tem o direito de autor assegurado por lei: quem fez o programa tem o direito autoral sobre aquela obra que produziu.

Você também pode proteger programas juridicamente por meio de patentes. É possível patentear um programa de computador, gerando um pedido de patente no INPI. Após todo o trâmite, se aceito, seu software se torna patenteado. Esses dois sistemas de proteção (direito autoral e patente) funcionam no Brasil e resolvem disputas sobre cópias não autorizadas e execuções de código sem autorização do desenvolvedor.

O que cada proteção abrange

O direito autoral assegura proteção para telas, interfaces, estruturas do programa, código fonte e elementos literais. Compara-se o código-fonte para identificar cópias. Já a patente pode proteger fluxogramas inéditos, arquivos de banco de dados, algoritmos novos, funcionalidades específicas e inéditas. Se você criar um algoritmo novo e o patentear, ninguém pode usar sem sua autorização.

Tanto pelo direito autoral quanto pela patente, é possível fazer contratos para cessão de direitos ou pagamento de royalties.

Outras formas de proteção

Mesmo com registro de patente e direito autoral, a proteção não é absoluta. Se alguém copiar seu programa, você pode provar a autoria, mas o processo é burocrático e caro.

Outro caminho para proteger programas é dificultar a cópia através da engenharia reversa. A engenharia reversa tenta entender como um programa funciona a partir do executável, reproduzindo o código-fonte original ou funcionalidades similares. É uma técnica controversa, pois alguém pode se apropriar do trabalho de desenvolvimento sem permissão.

Engenharia reversa: quando é usada

A engenharia reversa pode ser útil se você perdeu o código-fonte original, mas ainda tem a aplicação. Em alguns casos, é justificável, mas na maioria das vezes é usada para obter código sem permissão do proprietário.

Mecanismos de proteção via software

Além da proteção jurídica, existe a proteção via software, que é dificultar a engenharia reversa. Uma das técnicas mais utilizadas é o ofuscamento de código, muito comum na internet e em linguagens como JavaScript. O objetivo é dificultar o entendimento do programa, tornando a engenharia reversa mais trabalhosa.

Técnicas de ofuscamento de código

  • Remover comentários e informações redundantes: Deixa o código mais enxuto e difícil de entender.
  • Renomear variáveis: Trocar nomes significativos por nomes aleatórios, dificultando a leitura.
  • Reordenar o código-fonte: Fazer saltos no fluxo do programa para embaralhar a lógica.
  • Trocar comandos e estruturas por equivalentes: Substituir comandos simples por outros mais complexos ou equivalentes.
  • Inserir código redundante: Adicionar trechos que não fazem nada, confundindo quem lê o código.

Essas técnicas são especialmente úteis em programas legados, como os escritos em COBOL para mainframe.

Exemplo prático: programa de tabuada

No trabalho, foi criado um programa de tabuada em COBOL. O código original é claro, bem comentado e fácil de entender. Após aplicar as técnicas de ofuscamento, o código ficou com variáveis sem significado, comandos reordenados e trechos embaralhados, mas o resultado da execução é idêntico ao original. Para o usuário, não há diferença, mas para quem tenta entender o código, fica muito mais difícil.

Conclusão

Não existe método 100% seguro para ofuscamento de código. As técnicas dificultam o entendimento e a engenharia reversa, mas não garantem proteção total. O custo-benefício deve ser avaliado: quanto mais rebuscado o código, mais difícil de entender, mas também mais difícil de manter. O ofuscamento é uma técnica interessante, fácil de aplicar e que pode proteger bem o código-fonte contra cópias e engenharia reversa.

Transcrição adaptada e formatada a partir do vídeo de apresentação do TCC sobre ofuscamento de código.

WALTER RAMOS NETO PROTEÇÃO DE CÓDIGO FONTE VIA OFUSCAMENTO UNIÃO LATINO AMERICANA DE TECNOLOGIA JAGUARIAÍVA, 2016 WALTER RAMOS NETO PROTEÇÃO DE CÓDIGO FONTE VIA OFUSCAMENTO Monografia apresentada à Banca Examinadora do Curso de Pós-Graduação Desenvolvimento de Sistemas Mainframe da ULT como exigência para sua conclusão, sob a orientação da Professora Maristela Regina Weinfurter Teixeira. UNIÃO LATINO AMERICANA DE TECNOLOGIA JAGUARIAÍVA, 2016 BANCA EXAMINADORA Jaguariaíva, ____ de____________ de 2016 Dedicatória Ao meu filho, Vinicius e minha companheira de longa data, Juliana. Amo vocês. Agradecimentos A todos profissionais envolvidos na elaboração, manutenção, controle e logística do curso de especialização em Desenvolvimento de Sistemas Mainframe da ULT. Ao Acir Mandello Junior por sua ajuda imprescindível nos momentos de problemas e inconsistências no sistema. Ao Juscelino Niano Lindolm por todo apoio administrativo ao longo do curso. A professora Maristela Regina Weinfurter Teixeira agradeço a ajuda na elaboração desse trabalho e paciência ao longo de todo o curso. A todos que, de uma forma ou de outra, colaboraram para a realização e finalização deste trabalho. where COBOL maintenance programming is considered a pleasant alternative to growing rice or raising pigs." -Edward Yourdon Resumo No desenvolvimento de software, principalmente em aplicações da era da internet, o ofuscamento de código é algo importante devido ao resguardo da proteção intelectual, mesmo assim o assunto é pouco conhecido e estudado nas universidades pobre em referências acadêmicas. A legislação em vigor no país não fornece um nível de proteção adequado para que o desenvolvedor de um software se sinta seguro contra cópias ilegais, modificações, usos não autorizados do conteúdo de seu programa e a pirataria, como proteção adicional pode-se utilizar técnicas de ofuscamento de código. Neste trabalho foram apresentadas técnicas com o objetivo de proteger o software contra engenharia reversa, oferecendo ao desenvolvedor resguardo dos danos que não são contemplados nas leis de software em vigor, através da transformação do programa original em ofuscado. Muitos sistemas versam sobre ou se relacionarem com sistemas legados, especialmente em mainframes; tais sistemas não possuem documentação suficiente ou até mesmo inexistente. Os conceitos, exemplos e partes de código ilustram as desvantagens e as vantagens do uso de cada técnica de proteção frente a tentativas de entendimento de programas através do uso da engenharia reversa. Esse trabalho acabou sendo também uma referência para que futuras gerações não repitam os erros do passado e que possam conscientemente proteger seu código quando necessário ou mesmo auxiliar no entendimento de algum programa que acabou sendo ofuscado ao longo dos anos sem que essa tenha sido a intenção. Palavras-chave: Ofuscamento; código fonte; mainframe; engenharia reversa; prote ção; patente; direitos autorais; COBOL; código redundante. Abstract In software development, especially in the era of internet applications, code obfuscation is usual its use in Java programs a market practice, yet it is little known and studied in universities lacking academic references. In mainframe environment, the source code is accidentally obfuscated and is very well used in COBOL programs of legacy systems. The law does not provide an adequate level of protection for developer feel secure against copying, modification and unauthorized use of the content of their program, the use of obfuscation techniques provides a complementary additional protection. In this work were presented techniques to protect software against reverse engineering, providing additional layer of protection against damages that are not covered by software laws, by transforming the original program in obfuscated program. Many systems deal with or relate to legacy systems, especially in mainframes; such systems do not have sufficient documentation or are nonexistent, the source code is not commented, their complex structures, there are portions that are no longer executed, finally, some programs are almost unintelligible. In many source codes existing today on mainframes can be said that the source code is obfuscated because they present characteristic elements of protection techniques used in obfuscation. The concepts, examples and code portions illustrate the disadvantages and advantages of using each protection technique against the attempts of reverse engineering. This work can be used as a reference so that future generations do not repeat past mistakes and can consciously protect your code when necessary or even help to understand some program that was eventually obfuscated over the years without being the intention. Key Words: Obfuscating; source code; mainframe; reverse engineering; protection; patent; copyright; COBOL; redundant code. Lista de ilustrações Figura -Processo de Engenharia Progressiva x Engenharia Reversa Figura Figura -Trecho de código fonte com dead code Figura -Trecho de código fonte original Figura -Programa HelloWorld em COBOL Apêndice A Figura -Programa HelloWorld em COBOL ofuscado Apêndice B Figura -Execução do programa TABUADA Lista de tabelas Tabela 1 -Patente x Direito autoral Lista de abreviaturas AMD Advanced Micro Devices CEE Comunidade Econômica Europeia COBOL COmmon Business Oriented Language ER Engenharia Reversa IBM Internacional Business Machines INPI Instituto Nacional da Propriedade Industrial OMPI Organização Mundial da Propriedade Intelectual TRIPS Trade-Related Aspects of Intellectual Property Rights WWW World Wide Web Sumário PROTEÇÃO DE CÓDIGO FONTE VIA OFUSCAMENTO.................................................................... 1 PROTEÇÃO DE CÓDIGO FONTE VIA OFUSCAMENTO.................................................................... 2 Dedicatória ............................................................................................................................................. 4 Agradecimentos .................................................................................................................................... 5 Epigrafe .................................................................................................................................................. 6 Resumo .................................................................................................................................................. 7 Abstract .................................................................................................................................................. 8 Lista de ilustrações............................................................................................................................... 9 Lista de tabelas.................................................................................................................................... 10 Lista de abreviaturas .......................................................................................................................... 11 Introdução ............................................................................................................................................ 13 Capítulo 1 -Direito autoral e Ofuscamento em programas de computador ................................. 15 1.1. Direitos autorais e programas de computador ...................................................................... 15 1.2. A Origem do Ofuscamento de código de Programas de Computador ................................. 18 Capítulo 2 Engenharia Reversa ...................................................................................................... 20 2.1. As Origens da Engenharia Reversa..................................................................................... 20 2.2. É correto utilizar a engenharia reversa ? .............................................................................. 23 2.3. Questões Econômicas da Engenharia Reversa ................................................................... 25 Capítulo 3 Mecanismos de Proteção.............................................................................................. 27 3.1. Mecanismos de Proteção Jurídica ........................................................................................ 27 3.2. Mecanismos de Proteção via Software ................................................................................. 28 Capítulo 4 -Técnicas de ofuscamento.............................................................................................. 31 4.1. Auto documentação............................................................................................................... 33 4.2. Minificação de código ............................................................................................................ 35 4.3. Minificação e ofuscamento.................................................................................................... 37 4.4. Compilação e link edição ...................................................................................................... 39 4.5. Código redundante ................................................................................................................ 40 4.6. Geração de dumb code......................................................................................................... 43 4.7. Revisão de código e padronização ....................................................................................... 44 Conclusão ............................................................................................................................................ 46 REFERÊNCIAS..................................................................................................................................... 48 ANEXO A FOLHETO DE DIVULGAÇÃO SOFTWARE DE OFUSCAMENTO ................................ 53 APÊNDICE A -CÓDIGO FONTE PROGRAMA COBOL HELLO SEM OFUSCAMENTO................. 57 APÊNDICE B -CÓDIGO FONTE PROGRAMA COBOL HELLO OFUSCADO ................................. 58 APÊNDICE C -CÓDIGO FONTE PROGRAMA TABUADA SEM OFUSCAMENTO ......................... 59 APÊNDICE D -CÓDIGO FONTE PROGRAMA TABUADA OFUSCADO.......................................... 62 APÊNDICE E EXECUÇÃO DO PROGRAMA TABUADA ................................................................ 63 Introdução A proteção de código fonte vem sendo uma grande preocupação das corporações ao longo das últimas décadas por inúmeros fatores que serão expostos ao longo desse trabalho, uma das maneiras existentes para tal processo é o ofuscamento. Segundo AURÉLIO 2001, ofuscar tem o significado de ocultar, encobrir, impedir de ver ou de ser visto, turvar, tornar menos claro ou menos perceptível, empanar, fazer diminuir a intensidade, toldar, turvar a vista, perder o brilho. Observa-se que o objetivo principal do ofuscamento é o de dificultar a visualização de algo, assim sendo, a técnica que será apresentada nesse trabalho visa proteger os códigos fontes de programas através da implantação de elementos que turvem a leitura do código. Uma das formas de proteção existente é a proteção de software através do depósito de patente e registro de programas junto aos órgãos competentes, no caso do Brasil o INPI -Instituto Nacional da Propriedade Industrial, essa caracteriza abordagem jurídica para a proteção a outra forma é através de alterações no código fonte do programa. No capítulo I serão abordados temas relacionados ao direito autoral aplicado a códigos fonte de programas de computador suas implicações e consequências. Além do direito do autor será apresentada uma abordagem que visa proteger tais programas através de técnicas computacionais conhecidas como ofuscamento de código. O capítulo II traz uma discussão sobre a origem da engenharia reversa, realiza uma análise sobre ser correto ou não o uso de tal abordagem sob o ponto de vista jurídico, suas implicações e como ela é vista pelas leis brasileiras e pela comunidade internacional, aborda também as questões econômicas associadas ao uso da engenharia reversa. Já no capítulo III são apresentados os mecanismos de proteção de programas de computador. São discutidas as bases para a proteção de programas de compu tador através de modificações no código fonte e retoma-se a discussão sobre o direito autoral, mas agora com um viés de proteção diferente do capítulo I que apresentava a legislação vigente. No capítulo IV são abordadas diversas técnicas de ofuscamento de código segundo uma sequência de mais fácil entendimento iniciando-se pela auto documentação, seguida pela minificação de código, uma abordagem um pouco mais complexa e necessária é o processo de compilação e link edição, são apresentadas para finalizar o capítulo e as técnicas de ofuscamento conhecido o código redundante e a geração de dumb code ambas de alta complexidade e difícil entendimento e aplicação. Para finalizar o capítulo apresenta-se a revisão de código fonte. Na conclusão são considerados todos os aspectos levantados ao longo do texto e são apresentadas as conclusões sobre o ofuscamento de código que podem ser obtidas desse trabalho. Capítulo 1 -Direito autoral e Ofuscamento em programas de computador 1.1. Direitos autorais e programas de computador O software tornou-se um bem no início da década de 70 (Pereira dos Santos, 1997). Desde então iniciou-se uma série de medidas internacionais para protegê-lo. No Brasil apenas em 1987 foi promulgada a lei do software que protege o direito do autor de programas de computador. Em 1990 a União Europeia através da Diretiva 91/250/CEE definiu um padrão mínimo de proteção, complementados pelos acordos TRIPS (Acordo sobre os Aspectos dos Direitos de Propriedade Intelectual Relacionados ao Comércio) de 1994 e Tratado de direito de autor da OMPI de 1996. Em 2000 os tratados internacionais sobre o tema passaram a diferenciar a tecnologia empregada como um adicional a ser protegido, visto que a funcionalidade de um programa não é objeto de proteção através do direito autoral e sim através de patentes. (Pereira dos Santos, 1997). O código fonte em tese não circula, pois é no código fonte que contém o trabalho intelectual e a tecnologia do programa de computador. O que se tem é a patente de invenção implementada pelo programa de computador, o código não é protegido por patente e sim por direito autoral, porém é algo extremamente complicado defender que um programa não foi copiado de outro ou qual foi produzido primeiro. Em vista disso a utilização de técnicas computacionais auxilia o direito no que diz respeito à cópia indevida, pois se o código fonte for ininteligível, possuir marcas únicas e características (marca ) fica facilitado o processo de garantia de propriedade intelectual. Pode-se patentear a solução técnica que o software implementa, não suas funcionalidades, afinal a solução é uma invenção e uma forma de corrigir algum problema, entretanto o código e os melhoramentos não podem ser patenteados sendo protegidos apenas por direito de autor o qual apresenta dificuldades em sua defesa isto porque as leis vigentes segregaram o direito do autor e a propriedade intelectual conforme ilustra a tabela 1. Direito do autor Propriedade Intelectual (patente) Interfaces/Telas Fluxograma Estrutura Formato de arquivos e banco de dados Código Fonte Algoritmo Elementos Literais Funcionalidade Tabela 1 -Patente x Direito autoral Com a proteção pelo sistema de patente, protege-se o objeto com a funcionalidade que o programa introduziu. Para tanto, o software deve preencher as condições necessárias para solicitação do patenteamento, que são: resolução de um problema técnico encontrado no estado da técnica, resultar em aplicação prática e ter efeito técnico novo. (Lei nº10.196, 2001) No Brasil temos uma sistemática bem específica sobre a proteção autoral. Em 1987 a lei 7646 apresentava duas partes distintas, o regime de proteção e a comercialização, ela reservava mercado para produtos e empresas nacionais desde que existisse a tecnologia e empresas no Brasil que suprissem as necessidades. O mainframe podia ser vendido pela IBM pois não existia nem a tecnologia nem empresas que o fabricassem. Já em 1998 com a promulgação da lei 9609 foram estabelecidos o tratamento igualitário para produto estrangeiro e nacional e o fim da reserva de mercado. Previu-se também o programa de computador como obra intelectual protegida. Atualmente o regime básico do programa de computador é o da lei especial, com a aplicação subsidiária da legislação do direito de autor podendo dessa forma, o autor, reivindicar a paternidade do programa de computador e o de opor-se a alterações não autorizadas quando impliquem deformação, mutilação ou outra modificação em seu programa (Pereira dos Santos, 1997). O prazo para a proteção é de 50 anos e em termos jurídicos a lógica central do programa é de domínio público. Os direitos sobre os programas de computador são regidos pela lei 7646/87 que basicamente diz que salvo disposição em contrário, o empregador ou contratante do serviço é dona dos direitos desse programa. As boas práticas do mercado reforçam essa prerrogativa nos contratos de trabalho e prestação de serviço, sendo recomendável a entrega do código fonte, que é a tecnologia propriamente dita. (Murta,1998) Como diversos programas podem realizar a mesma função e possuírem códigos fontes distintos o direito do autor que é baseado em elementos literais deixa de proteger esse software uma vez que apenas o código fonte (estrutura geral, telas e interfaces de usuários) e o código objeto (carga ou executável) são protegidos pelo direito autoral. Uma alteração um pouco rebuscada no código fonte original já faz com que um perito não consiga classificar o novo código fonte (ou objeto) como uma cópia do original. A proteção apenas pelo direito autoral contra cópia, plágio, aproximação, aproveitamento, clonagem, reutilização é insuficiente pois a confirmação dessas práticas é extremamente complexa e por vezes não pode ser afirmada com precisão, embora seja uma cópia se não for descarada não é um processo simples. É indicado o uso de patente para complementar a proteção do código protegendo assim o algoritmo utilizado, a funcionalidade, o fluxograma, parâmetros, estrutura de dados e arquivos. (Dragoni, 2014) Dois ou mais programas podem ser semelhantes em dadas situações e totalmente diferentes em outras embora possam possuir funcionalidades equivalentes a comprovação da cópia é extremamente trabalhosa. Muitas vezes a semelhança de funcionalidade gera a semelhança na forma de expressão, seja por causa da observância de conceitos normativos e técnicos ou mesmo pelas características funcionais da aplicação, por vezes a implementação de determinado algoritmo só pode ser feito de uma forma e se ambos programas o utilizarem eles serão iguais, e mesmo assim não serão cópias. Para casos de plágio, segundo as leis vigentes, não é violação de direito de autor quando ocorrer semelhança entre programas que se derem por força das ca racterísticas funcionais de sua aplicação, da observância de preceitos normativos e técnicos, ou de limitação de forma alternativa para sua expressão. (Art. 6, III, Lei 9609/98, previsão idêntica ao art. 7, III, da lei 7646/87) Em síntese, o sistema do Direito Autoral é muito bom para cópia servil, mas quando se trata de proteger tecnologia e evitar o plágio não é o melhor sistema. 1.2. A Origem do Ofuscamento de código de Programas de Computador Devido à maneira como foi concebida a tecnologia utilizada na World Wide Web, leia-se internet, não há como proibir o acesso a determinados códigos fontes, como os javascripts por exemplo. A saída encontrada pelos profissionais de TI foi fazer códigos nos quais mesmo o usuário tendo acesso a ele não consiga entender o que ele faz. Uma sacada sensacional que recebeu o nome de ofuscamento, essa técnica é uma das formas mais fáceis e baratas para proteger um software contra engenharia reversa. (Collberg et al, 2002) A técnica do ofuscamento tem como objetivo principal tornar códigos ininteligíveis, mesmo quando não esse objetivo não é atingido, a sua simples utilização produz um considerável aumento na dificuldade de leitura do código. O processo é simples em seu conceito e sua utilização é justificada pela preservação da propriedade intelectual do desenvolvedor do software. (Somekawa, 2012) Simples transformações de layout são suficientes para dificultar a compreensão de um código, tais alterações associadas com transformações no fluxo do processamento, inclusão de variáveis sem sentido e definições não usuais completam o ferramental básico para dificultar a análise e entendimento de um código fonte. (Collberg et al, 1997) De carona no ofuscamento veio uma prática que há muito já é de conhecimento do programador COBOL que não segue muito os padrões de sua firma e prefere a velocidade no desenvolvimento do código em detrimento a clareza para o entendimento das futuras gerações. Ofuscação de código tem sido utilizado majoritariamente em 3 grandes áreas, na manutenção evolutiva de sistemas na qual a nova versão do programa tenha recebido apenas alguns ajustes ou uma nova funcionalidade o código fonte é totalmente diferente, na integridade do programa visto que o código fonte sendo de difícil compreensão sua modificação é muito mais complicada e para a proteção de direitos como no caso dos algoritmos. (Cohen, 1993) As técnicas de ofuscação abordadas nesse trabalho são classificadas como estáticas, isto é, após o código ter sido ofuscado ele não mais sofrerá alterações. Existem as dinâmicas que fogem ao escopo desse trabalho nas quais alterações continuam a ocorrer no programa (geradas e mantidas por ele mesmo) em seu próprio funcionamento muito utilizado em vírus de computador (VírusBrasil, 2016). Nesse capítulo foi apresentado um estudo sobre a legislação brasileira e sobre tratados internacionais que apresentam como tema a proteção de programas de computador, desde o programa pronto até seu código fonte que é o artefato/insumo para a produção de todo e qualquer software. As diferenças básicas entre o que pode ser e é protegido por lei de autor e por patente é apresentada na tabela 1 e discutida ao longo do texto. Da análise da legislação e do programa de patentes verifica-se que os meios jurídicos não fornecem a proteção necessária para uma completa blindagem dos softwares sendo necessária a aplicação de uma camada extra de segurança nos programas que é fornecida através do ofuscamento de código. Capítulo 2 Engenharia Reversa 2.1. As Origens da Engenharia Reversa A expressão é originária do direito norte-americano de conhecida na indústria de hardware, bélica, automação e de semicondutores. Por que utilizar engenharia reversa de software? O programa é comercializado em código objeto. O registro de programas resguarda o sigilo do código fonte. O código fonte é tratado como segredo empresarial. A utilização da engenharia reversa é indicada em algumas situações: Quando se possui o código fonte do sistema, mas não existe sua documentação. Existência de código duplicado. Dificuldade de manutenção do sistema. Erros gerando outros erros. Processos que possuem comportamento desconhecido e imprevisível. Os objetivos principais da engenharia reversa são: Interoperabilidade Clonagem Suporte técnico Em relação a interoperabilidade a engenharia reversa objetiva o desenvolvimento de interfaces lógicas (compatibilidade entre programas), por sua vez a clonagem objetiva apenas cópia das funcionalidades do programa, por vezes estendendo- se até mesmo a interfaces de uso do usuário, finalizando o suporte técnico é uma vertente que visa a correção de erros, introdução de modificações e desenvolvimen to de adaptações, sendo por vezes autorizado e dessa maneira, lícito do ponto de vida jurídico. (Fetrim, 1999) A engenharia reversa pode gerar diferentes níveis de abstração, sendo que cada nível requer uma determinada quantidade de esforço por parte do investigador. Quanto maior o nível de abstração melhor a compreensão e facilidade do entendimento do funcionamento do programa. O processo de análise e compreensão de um programa já existente e funcional com o objetivo de entender o seu funcionamento é o que melhor define a engenharia reversa. (Fetrim, 1999) A obtenção dos elementos do código fonte de um programa de computador a partir do seu código objeto é um dos objetivos preconizados pela engenharia reversa. Os passos para obtenção do código fonte são: (a) Análise do funcionamento do programa (black box analysis em inglês), e (b) Descompilação ou desassemblagem que é o processo inverso ao da com- Compilar é transformar o código fonte em objeto, o processo inverso chama- se descompilação que é o ato de converter um arquivo inteligível apenas para os computadores em um código fonte que pode ser interpretada por detentores de co nhecimento de determinada linguagem de computação. A engenharia reversa e código a partir do programa compilado em seu objeto que é o entendimento do programa. (Boccardo, 2010) que é a visualização do ecuperação d 2.1. A abstração como ato transformador Atos destinados a obter, a partir de um produto acabado, o código fonte que deu origem ao programa é um processo extremamente trabalhoso que envolve quase que todas as áreas do conhecimento relacionadas ao desenvolvimento de softwares. Entretanto nenhuma disciplina versa sobre a abstração, que é a habilidade primordial para que esse tipo de processo logre êxito. A abstração apresenta diversos níveis sendo que cada passo no processo de desenvolvimento de software seria um refinamento do nível anterior contendo um maior detalhamento das funções que serão realizadas por esse nível. (Lynn, 2004) Informações numa forma mais global possuem alto grau de abstração sendo que seu extremo oposto seria a forma mais detalhada que apresenta baixo grau de abstração. Nos passos ou estágios iniciais do ciclo de vida de um software as informações possuem alto nível de abstração e nos estágios finais baixo nível de abstração Figura 1 -Processo de Engenharia Progressiva x Engenharia Reversa1 A engenharia progressiva é o processo tradicional de desenvolvimento de um software é regida pela disciplina de engenharia de software e é caracteriza-se por desenvolvimento em cascata no qual partindo de um nível de abstração alto chega- se a um nível baixo. Em contrapartida a engenharia progressiva temos a engenharia reversa que partem de um baixo nível de abstração para um alto nível e tem como objetivo a descoberta de como um programa foi feito e de como ele funciona. Extraido de: Valéria Delisandra Fetrim, Apoio à Documentação de Engenharia Reversa de Software por Meio de Hipertextos, Dissertação de Mestrado, USP-São Carlos, 1999, p. 9. 2.2. É correto utilizar a engenharia reversa? Duas correntes em 1980 surgiram para estudar a lógica de um programa. Uma delas defendia que a engenharia reversa deveria ser livre e praticada sem qualquer tipo de intervenção ou de regras. A outra corrente por sua vez afirmava que o estudo de um programa através da engenharia reversa não devia ser permitido. (Pereira dos Santos, 1997). Menos de uma década depois do início dos debates sobre a possibilidade de se estudar um programa através da engenharia reversa ser uma pratica livre ou não. A corrente de pensamento que prevaleceu e está em vigor até a atualidade foi a de proibir a engenharia reversa. O que se discute no direito é o processo da engenharia reversa e não o que se faz depois que se obtém o pseudocódigo fonte. Do ponto de vista da compatibilidade com o sistema de Direito de Autor existem: (a) Exclusão da proteção de ideias, conceitos, etc. Todos que utilizam um algoritmo de um programa já existente, mas que gerariam seu programa de uma forma essencialmente diferente não seria responsável por violação de direitos autorais. (ULMER & KOLLE, 1983)2 Basicamente entende-se que a utilização de um algoritmo não pode ser considerada uma violação de direito autoral. (b) A proibição pela Lei de Direitos Autorais equivale a criar um regime de segredo do conteúdo do programa inaplicável às obras tradicionais. direitos de autor para o software permite, pela primeira vez na história das propri (BERNARD, 1993)3 Da tradução livre observa-se que o direito do autor no âmbito do software é considerado um segredo. (c) A engenharia reversa pode implicar a realização de atos atentatórios contra a exclusividade do autor. A reprodução e transformação da forma de expressão do programa de computador obtido através da engenharia reversa do código objeto para extração do pseudocódigo transitória ou incidental está prevista e proibida pelo Art. 30, § 1o da Lei Direito Autoral. Segundo as leis vigentes (Lei 9.609/98 Lei do Software) não é necessária a autorização do titular dos direitos quando a reprodução do código e a tradução da sua forma forem indispensáveis para obter as informações necessárias à interoperabilidade de um programa de computador criado independentemente, com outros programas, uma vez preenchidas as seguintes condições: (a) esses atos serem realizados pelo licenciado ou por outra pessoa que tenha o direito de utilizar uma cópia do programa, ou em seu nome por uma pessoa devidamente autorizada para o efeito; (b) não se encontrarem já fácil e rapidamente à disposição das pessoas referidas as informações necessárias à interoperabilidade; (c) esses atos limitarem-se a certas partes do programa de origem necessárias à interoperabilidade. O Art. 6, IV da Lei 9.609/98 (Lei do Software) cita possibilidades de estudo que não constituem ofensa aos direitos do titular de programa de computador, sendo a) Integração de um programa, mantendo-se suas características essenciais, a um sistema aplicativo ou operacional, tecnicamente indispensável às necessidades do usuário, desde que para o uso exclusivo de quem a promoveu. Dessa forma, a descompilação segundo a lei vigente sobre softwares de computador brasileira seria livre, embora não seja legal, ela pode ser realizada sem punição. Segundo Oliveira Ascensão (Direito Autoral, 1997, p. 671) orquanto a integração, requerendo ato de transformação ou adaptação, pressupõe a descompilação, ou seja, a proteção não é legal, mas todas as licenças de uso de software proíbem a engenharia reversa. 2.3. Questões Econômicas da Engenharia Reversa O benefício fundamental da tecnologia de ER (Engenharia Reversa) é o aumento do entendimento de um sistema o que facilita a atividade de manutenção e consequentemente aumento da produtividade (vantagens financeiras). As partes do sistema que vão sofrendo a engenharia reversa já são funcionais e podem ser utilizadas em outras aplicações. O aumento da produtividade na etapa de desenvolvimento de software através do reuso, garantindo a qualidade já existente no aplicativo original torna o sistema mais fácil de ser mantido, suportado e evoluído. (Penteado, 2009) Baseado nas características do sistema que sofrerá o processo de Engenharia Reversa não se pode no início da análise quantificar com precisão quanto trabalho será necessário para obter o sistema funcional desassemblado, isto é, seu código fonte. Em vista disso, nas aplicações da Engenharia Reversa os custos podem ser invariavelmente difusos dependendo de como foi concebido o software, podendo ser facilmente analisado e gerado um código fonte novo com iguais funcionalidades ou extremamente complexo a ponto de inviabilizar a ER mas qualquer que seja o caso, apenas depois de iniciada a análise é que será conhecida a complexidade do desafio. (Ayres,1987) A ER pode facilitar novos desenvolvimentos pelo exame de como sistemas similares foram construídos e assim as equipes de projetistas podem obter mais informações para as decisões a serem tomadas nos novos projetos, como foi o notório caso apresentado a quem estuda essa área que é a do bombardeiro da segunda guerra mundial o Tupolev. (Gordon, 2002) Todo projeto que vá utilizar a ER, além das implicações econômicas, deve sempre levar em consideração as implicações legais. Os japoneses no pós-guerra adotaram a ER de maneira massiva, o que contribui positivamente em sua indústria até 1960 quando deixaram de simplesmente copiar produtos e tecnologias e passaram a desenvolvê-las. (Sicsu, 1989), No episódio russo do avião bombardeiro Tupolev, os russos optaram por realizar a engenharia reversa de um avião já pronto e funcional ao invés de criarem um projeto novo para seu novo bombardeiro, no caso dos russos eles conseguiram realizar uma análise que os fez optar pela engenharia reversa ao processo tradicional, mesmo que os custos dessa operação fossem bem mais elevados o prazo estimado para a execução da ER foi bem inferior ao do projeto tradicional. Nesse capítulo foi apresentado um estudo sobre a engenharia reversa seus aspectos legais analisando-se diversos estudioso do tema os quais chega-se à conclusão que a engenharia reversa embora seja algo ilegal do ponto de vista jurídico pode ser considerada uma pratica livre. Foram elencados motivos e os objetivos para a utilização da engenharia reversa. Os passos que são seguidos no processo da análise do funcionamento até sua desassemblagem e obtenção do código fonte também foram citados. Traçou-se um paralelo entre o processo comum de engenharia progressiva/tradicional e a engenharia reversa (figura 1) E para finalizar foi citado um episódio de engenharia reversa utilizada durante a segunda guerra mundial na qual os custos do projeto de ER superaram em muito o da engenharia tradicional, mas foi escolhido devido ao curto prazo para implantação do produto. Capítulo 3 Mecanismos de Proteção Existem apenas dois tipos de proteção aos programas de computador que podem ser utilizadas, a proteção jurídica através de registro de obra intelectual e de patentes ou via software com modificações nos programas evitando seu entendimento e possíveis cópias. A proteção do software como um problema de âmbito global tratado pelo direito surgiu há mais de três décadas e sempre foi tratado com duas vertentes, o direito do autor e a patente, sendo que ambos sistemas de proteção coexistem em harmonia e são complementados pela proteção via software. 3.1. Mecanismos de Proteção Jurídica Existe uma natureza dualista, ou híbrida, do software como sendo uma criação utilitária como um processo ou como uma forma de expressão. Sob a ótica estritamente funcional uma criação técnica que vise a solução de problemas específicos (caráter utilitário) deve ser enquadrada como um processo, já sob a ótica da geração de saber, o software seria uma forma de expressão pois envolve a implementação de um processo lógico, isso é, o software é um conjunto organizado de instruções para a realização de funções determinadas. (Pereira dos Santos, 1997). O software possui aspecto simbólico e textual da mesma forma que uma criação intelectual que se exterioriza pelo modo expressivo (obra intelectual), dessa forma o programa de computador é implementado utilizando uma linguagem natural e codificada. (Lei nº10.196 sobre Propriedade Industrial de 2001) Justamente por apresentar essa natureza hibrida, de obra intelectual e de inovação, o software pode ser protegido tanto pelo direito do autor como através de patentes. Sob a tutela do direito autoral a criação, como natureza jurídica de obra intelectual, protege apenas e unicamente o código fonte e seus elementos literais e não literais, a tutela legal fica então sujeita ao critério de originalidade, caso o código so fra algumas modificações que descaracterizem sua origem, o direito do autor não consegue proteger esses casos. Por sua vez no caso da patente, como a natureza jurídica é de invenção -sendo que a tutela legal incide basicamente sobre a solução técnica (especificações), critérios de novidade, atividade inventiva e aplicação industrial -a inovação é protegida. Então, proteção de software é um problema universal que todos os países têm de lidar. Proteção de Software é também um velho problema... Eu digo velho novo problema, porque a questão agora data de cerca de trinta anos, pelo menos nos países onde a computação conheceu seus primeiros desenvolvimentos. No entanto, é uma questão tópica. E esse é o caso, porque, mesmo que o acordo TRIPS diz em seu artigo 7º: "Os programas de computador, quer seja o código fonte ou objeto, serão protegidos como obras literárias conforme a Convenção de Berna (1971)", a pergunta que perdurou por dez ou quinze anos, de acordo com os países, da patente na abordagem da "protegibilidade". Na verdade, a história da proteção de software é uma história caótica. E a questão da proteção de software aparece hoje como uma questão de "oscilação" entre os dois polos que, por um lado é copyright (direito autoral) e, por outro lado, é patente, com o que implica em termos de complexidade. É necessário saber sobre ao direito do autor do software e sobre a sua patenteabilidade, mas também sobre a coexistência de dois sistemas de proteção. (VIVANT, 2009)4 Pode-se inferir que devido as características intrínsecas dos programas de computador, mais especificamente pela sua inovação e por sua maneira de ser expresso como uma obra intelectual; os softwares podem ser protegidos juridicamente tanto pelo sistema de patentes como por direito autoral. 3.2. Mecanismos de Proteção via Software As técnicas de proteção de um software visam dificultar a engenharia reversa, assegurando que o software executa como esperado e protegendo o software de pirataria. (Collberg et al, 1998) Existem algumas técnicas para esconder informações em programas de computador, o presente trabalho focará em 3 tipos que além de esconder, protegem o código e lhe fornecem uma grande capacidade de incompreensão. Técnicas de ofuscação de código dificultam engenharia reversa através de um aumento no grau de ininteligibilidade do código. Este aumento se caracteriza por modificações sintáticas que dificultam a compreensão do software mantendo, porém, as funcionalidades originais do programa (sua semântica). (Boccardo, 2010) Avanços incrementam o poder dos software para engenharia reversa com o objetivo de descobrir vulnerabilidades, realizar alterações indevidas, ou furtar propriedade intelectual... Atualmente, existe pouco conhecimento, entre os desenvolvedores de software, sobre a importância do uso destas (BOCCARDO, 2010) A engenharia reversa em programas de computador envolve geralmente duas fases: análise e modificação. Na análise, é objetivado compreender como funciona o programa, a modificação por sua vez se dá quando já se possui o conhecimento adequado do software e então pode-se criar um novo a partir do que foi compreendido. A utilização de técnicas de ofuscamento de código tenta dificultar o entendimento do software através da modificação de alguma parte do programa, da extração de algoritmos e sua substituição por outros, alteração nas rotinas de cálculos, mudanças no fluxo seguido pelo programa. Para implementar essas técnicas o programador vai adicionando, alterando e modificando diversos elementos em um programa fazendo com que ele se torne o mais rebuscado possível sem alterar seu funcionamento. Zaytsev (2005) Ofuscar um programa refere-se entre outros aspectos a geração de um novo programa funcionalmente equivalente no qual a coleta de dados de funcionamento por engenharia reversa é extremamente mais complexa que no programa não ofuscado. É recomendável que o programa que será ofuscado já esteja pronto, testado e funcionando conforme as especificações que lhe foram propostas, pois as altera ções implementadas para ofuscar o código não devem de maneira alguma alterar o funcionamento original do software. Do ponto de vista da propriedade intelectual, essas técnicas utilizadas pelos analistas, desenvolvedores, programadores visam esconder informações sobre tópicos que não podem possuir propriedade, como é o caso dos algoritmos -seja esse algoritmo uma novidade ou uma versão aprimorada de algum já existente que depois de muito investimento para implementá-lo percebe-se que não é muito lucrativo distribui-lo livremente. A ofuscação de código fonte tem se mostrado uma técnica bastante útil para esconder informações valiosas dentro de um programa. (Collberg et al, 1997) O ofuscamento do código fonte eleva a dificuldade de compreensão do código levando o programador espião a desistir da análise visto a alta complexidade do programa. Essa análise de um código a fim de determinar suas funcionalidades, características visando o entendimento do programa como um todo recebe o nome de engenharia reversa. A dificuldade no entendimento do código ofuscado se baseia na quantidade de dinheiro e tempo que serão gastos na análise do programa (Collberg et al, 1997) Um efeito secundário e positivo que o ofuscamento acaba produzindo é o aumento da segurança do programa contra tentativas de ataque, popularmente conhecido como hackea-lo, isto é, contra tentativas de descobrimento de vulnerabilidades, uma vez que estando o programa praticamente ilegível, a dificuldade para encontrar erros e falhas é altamente elevada, afinal, o adversário ou invasor sequer entende o que o programa está fazendo. Os mecanismos de proteção via software são técnicas utilizadas para ofuscar um sistema de computador as quais versam, em sua grande maioria, sobre alterações na estrutura do código fonte do programa através da inclusão de artifícios que possuem a finalidade pura e simples de confundir e dificultar o entendimento do que o programa é e do que o programa faz de verdade. Capítulo 4 -Técnicas de ofuscamento Conforme explicitado nos capítulos anteriores, como mecanismos para proteger um programa de computador existem a via jurídica e a via do software, dando continuidade e aprofundando os conhecimentos relativos à proteção via softwares temos as técnicas de ofuscamento de código. Dentre as técnicas estáticas existem alguns grupamentos de acordo com as transformações a serem realizadas no código, como: -Alterações apenas na estrutura do código que não geram diferença no código objeto / programa final e que versam sobre a remoção de informações redundantes ou desnecessários, em inglês minyfi e a renomeação de identificadores e variáveis. 4 Figura 2 - Alterações no fluxo de processamento do programa que geram diferença no código objeto / programa final causando um maior consumo de CPU que o programa gerado pelo código original tais como dificultar a análise do fluxo de controle pela inserção de saltos condicionais ou não durante o processamento do programa além da eliminação de sessões do programa e reordenação do código fonte. - -code ou códigos espúrios na qual o programador insere trechos de código que podem ou não ser executados de acordo com determinadas situações fazendo com que o estudante que estiver analisando o programa sequer saberá se determinado trecho será executado ou não. (COLLBERG et al, 1998). Essas alterações da mesma maneira que as alterações no fluxo de processamento geram diferenças no programa final causando um maior consumo de CPU que o programa gerado pelo código original Figura 3 -Trecho de código fonte com dead code A figura 3 acima ilustra um trecho de um programa que possui um dead code, isto é, um trecho de código que jamais será executado. No exemplo temos que to - das. Nesse caso pode-se inferir que o programador realizou a manutenção do código e não se atentou para retirar as linhas que ficaram mortas no código. -Alterações estruturais para comandos equivalentes como a troca de um laço enquanto por um laço até, utilização de claúsulas unitárias de cálculos decompondo um cálculo mais rebuscado, inserção de IFs encadeados ou troca de situações de igualdade por outras possibilidades, a alteração de estruturas de controle e contadores e uma infinidade de estruturas que podem ser decompostas, alteradas ou incluídas contendo as mesmas funcionalidades, mas com um grau de compreensão muito rebuscado. (COLLBERG et al, 1997) Essas alterações podem ou não gerar diferença no código objeto / programa final depende da linguagem de programação e das opções de compilação. Deve-se sempre lembrar de inserir comandos similares e utilizar variáveis espelho ou mesmo a própria variável sendo seu valor armazenado antes de modificações e recuperado após elas mantendo seu valor original em trechos . Inserção de instruções sem função dentro do código: Geralmente são utilizadas expressões que verificam determinados valores de uma dada variável e alteram o fluxo do processamento ou processam partes do programa que não geram nada de útil apenas gastam processamento e levam o analista a loucura tentando entender determinado trecho do programa. ZAYTSEV (2005) Essas alterações causam mudanças no fluxo de processamento, utilizam CPU para realizar tarefas sem relação ao objetivo do programa e com isso acabam gerando um programa bem diferente do original. A utilização das técnicas estáticas listadas acima visa tornar o mais difícil possível a tarefa de descobrir de onde veio e para onde seguira a execução do programa e se o trecho a ser executado ou que foi executado é útil ou não. Não há sentido em incluir um trecho para dificultar o entendimento do analista adversário se o trecho destoar por completo do restante do programa, portanto os do código fonte. 4.1. Auto documentação Uma das grandes vantagens da linguagem COBOL é que ele é auto documentável, essa característica predominante do COBOL ocorre pois em sua concepção foram utilizados termos e semânticas da língua inglesa que facilitou muito o aprendizado da linguagem e também sua disseminação. (Wojciechowski, 2010) Por se assemelhar muito ao modo da escrita inglesa muitos códigos fonte de programas escritos em COBOL podem ser entendidos até mesmo por pessoas totalmente leigas com apenas algum conhecimento de lógica e um pouco de inglês. Segue baixo um comando simples da linguagem. ADD VALOR-1 TO VALOR-2 O comando acima é uma adição, ao ler o comando automaticamente o leitor consegue interpreta-lo, qualquer pessoa com um mínimo de discernimento da língua inglesa e que conheça um pouco de matemática deve ter entendido algo como Adicione o valor-1 ao valor-2 Entretanto o comando também pode aceitar uma outra sintaxe ADD VALOR-1 TO VALOR-2 GIVING VALOR-3 A qual não apresenta nenhum segredo, seria adicione o valor-1 ao valor-2 e de o resultado (GIVING) no valor-3. Uma outra maneira de fazer a mesma operação e que talvez até mais fácil de ser compreendida pois se assemelha a uma formula matemática e não a um texto é COMPUTE VALOR-3 = VALOR-1 + VALOR-2 Ambos comandos ADD ou COMPUTE podem gerar erros e o COBOL os trata de maneira bem parecida utilizando-se um ou SIZE ERROR ADD VALOR-1 TO VALOR-2 GO TO ENCERRA-EXECUCAO END-ADD O leitor mesmo que desavisado entenderá que se acontecer algum erro será exibida uma mensagem de erro e o processamento seguira para o encerramento (GO TO ENCERRA-EXECUCAO) Esse tipo de situação gerou muito conforto para os analistas e programadores que por vezes acabaram se acostumando a não documentar o código. Como nos exemplos acima pode-se ver que mesmo sem qualquer comentário sobre o que o comando realiza é possível o seu entendimento sem grandes esforços. Uma vez que os códigos fontes são bem guardados, os programas são compilados e o usuário não tem acesso a nenhum desses componentes nunca houve preocupação com a facilidade do entendimento do código. Em linguagens de programação mais atuais principalmente em aplicações WEB esse tipo de situação é completamente desaconselhável e indesejado, nesses sistemas o usuário, um concorrente, um adversário, vulgo, hacker ou qualquer pessoa tem acesso ao código fonte que está em execução, isso gera um novo cenário e uma vasta gama de problemas que os programadores de COBOL sequer um dia ousaram pensar. (Somekawa, 2012) Os problemas advindos da proliferação dos códigos fontes em claro, especificamente no COBOL é muito bem-vindo ainda mais que os sistemas costumavam ter pouca ou nenhuma documentação, porém na era da internet, os analistas de sistemas WEB precisam que o código seja inteligível somente para eles próprios, o usuário final não precisa e não é recomendável que tenha acesso e entenda o funcionamento do código. (Venkatesan, 2002) 4.2. Minificação de código Em português criou-se um estrangeirismo ou neologismo vindo do inglês minify, que nada mais é que reduzir. A palavra equivalente existe em português, mas no meio das pessoas que trabalham com informática, mais especificamente com programação, optou-se pelo uso de minificação de código. A minificação é processo de retirar os comentários, elementos acessórios, unir os comandos e tornar o código o mais enxuto ou reduzido possível. (WU et al., 2010) Além do código fonte do programa não possuir comentários muitos elementos excluídos do código, identidade visual, espaços, tabulações e outros elementos são suprimidos do código, por exemplo Esse trecho de código fonte acima encontra-se minificado, se comentado e utilizando-se a sintaxe completa dos comandos de acordo com as boas práticas, esse mesmo código se torna: Figura 4 -Trecho de código fonte original 5 A minificação não deve ser entendida como uma técnica de proteção quando utilizada sozinha, pois a lógica do programa ainda continua exposta e de fácil compreensão, o estudante apenas encontrara um pouco de dificuldade em remontar ou expandir o código minificado. Ao reduzir um código fonte suas funcionalidades permanecem inalteradas. Para o computador que executará o programa pronto não existe qualquer diferença entre o programa original sem sofrer o processo de redução e o programa reduzido, isto é, não existe diferença nenhuma no programa executável, apenas em seu código fonte. 4.3. Minificação e ofuscamento Do ponto de vista analítico o ofuscamento é algo mais elaborado que a minificação, pois requer um pouco de esforço do programador e do analista para que seu código se torne mais difícil de entendimento. Vamos ao exemplo clássico do primeiro programa de computador que todos deveriam aprendem quando começam a programar em uma nova linguagem, que é o HelloWorld, no COBOL ele seria algo como o exemplo abaixo: Figura 5 -Programa HelloWorld em COBOL Apêndice A Entre as partes da figura acima numeradas entre 1 e 2 o leitor não precisa se deter muito a tentar compreender o significado de cada linha existente no código fonte. Nesse primeiro momento digamos apenas que todas as instruções, comandos, identificadores existentes fazem parte do que é considerado um cabeçalho padrão sendo utilizado em todos os programas COBOL com pouca ou nenhuma variação. Atualmente nas versões do mainframe e de seu sistema operacional quase nada agregam, ainda existem por razões históricas e de compatibilidade, algo que a IBM jamais abriu mão. Existem muitas razões pelas quais programas e aplicativos existentes não podem ser alterados. Talvez a aplicação foi comprada em um pacote, de modo que você não tem acesso ao código fonte. Talvez alguém possui o aplica-tivo; talvez ele roda em sistema de outra pessoa. Talvez a fonte foi perdido, e não há ninguém que conhece o programa muito bem. Talvez a lógica do programa é tão complexa que as alterações são consideradas muito perigosas (IBM,2014)6 O que interessa no processo de ofuscamento é o próprio código gerado após a utilização de alguma das técnicas. Um simples comando, DISPLAY com a frase como o da figura 5 pode ser ofuscado fazendo com que o entendimento do que o programa fique bem complicado. Figura 6 -Programa HelloWorld em COBOL ofuscado Apêndice B Uma das poucas informações que podem ser extraídas do código acima é que será emitida uma mensagem (comando DISPLAY), mas para descobrir o conteúdo que ser exibido será necessário dispender um pouco mais de tempo e analisar o que existe dentro das variáveis utilizadas no comando. Nesse exemplo foi utilizado ao invés da frase em claro 'Hello World!' foram utilizadas três variáveis sendo seus nomes não contém qualquer significado e seus conteúdos encontram-se inicializados em hexadecimal. Antes do comando para exibição da mensagem foi executada uma movimentação com subscritor MOVE 1C TO 1D (6:7) para despistar o adversário. Ao código podem ser implementadas outras movimentações, cálculos diversos, outras variáveis, enfim, uma infinidade de artifícios para que o código fique o mais ininteligível possível. O ofuscamento de código (Code Obfuscation em inglês) é um método muito seguro e de fácil aplicação. Atualmente existem no mercado inúmeros software para realizar a tarefa, uma simples pesquisa na internet em sites de busca obtém diversos resultados, tanto pagos como gratuitos, mas para a linguagem COBOL não existem muitas opções, mais especificamente, foram encontrados apenas um software para a linguagem que é o Redvers Cloaking Device (ANEXO 1). 4.4. Compilação e link edição No processo para fazer com que um programa funcione, isto é, execute, algumas etapas devem ser seguidas para que seu código fonte se transforme em um executável. Basicamente e de maneira simplista seriam compilação e link edição. Na etapa de compilação o seu código fonte, por exemplo em COBOL, é convertido para uma montagem assembler, que recebe o nome de código de máquina, essa listagem contém seu programa convertido para a linguagem mais básica dos computadores, necessitando apenas sua link edição ou bind. (AHO; SETHI; ULLMAN, 2007) Caso um adversário resolva atacar o código depois do programa já finalizado e pronto para uso (depois de link editado) e, portanto, executável. O trabalho dispendido para tentar entender como é o funcionamento do programa é de extrema dificuldade e só se justifica em casos excepcionais, embora possível esse tipo de abordagem para a engenharia reversa é muito dispendioso e geralmente impraticável. Pode-se adicionar uma camada extra de proteção ao se utilizar o ofuscamento também no código de máquina gerado pelos compiladores ou montadores antes da link edição para geração do programa executável (módulo carga no caso do mainframe), nesses casos o acesso ao código fonte do programa não é possível e se quer faria sentido pois o programa que estava no código fonte original teve seu funcionamento alterado (embora mantido o processo de entrada e saída) pelo ofuscamento de seu código de máquina, sendo a engenharia reversa de desmontar o programa ofuscado segundo Wroblewski uma tarefa inútil embora 100% de proteção jamais será alcançada. (Barack et al, 2001) 4.5. Código redundante Outra técnica empregada para dificultar o entendimento é a utilização de código redundante, que nada mais é do que uma parte de código sem qualquer utilidade prática ou funcional, serve única e exclusivamente para dificultar o entendimento e atrapalhar a análise do código. A situação de código redundante ocorre por vezes de maneira totalmente despretensiosa e sem qualquer cuidado por parte do programador, muitas vezes partes de código sem qualquer função continuam a existir pois em algum momento da história de vida daquele programa foi utilizado uma outra linha de execução e esqueceu- se de retirar essa parte do código do módulo ou mesmo de simplesmente comentar sua inutilização. (BODÍK; GUPTA, 1997) Um código redundante em inglês, é inserido em um programa por alterações no código, qualquer um pode escrever um programa que acabe possuindo dead code, uma função antiga que deixa de ser utilizada e se torna obsoleta, as variáveis que eram utilizadas por essa função também se tornam redundantes, pois assim como a parte do código que deixou de ser referenciado essas variáveis também o serão. Esse tipo de alteração ou mudança ocorre devido a evoluções no código nas quais o analista não prestou muita atenção que em sua mudança partes do código deixariam de ser referenciadas e simplesmente as deixou no programa. (AIVOSTO, 2016) Uma outra causa muito comum e talvez a mais proeminente para a existência de código redundante seja a reutilização de programas, em outras palavras, o conhecido copie e cola, vulgo Control + C, Control+ V. Ao copiar um programa esqueleto, modelo, similar, padrão ou qualquer outra nomenclatura que possa existir muitas partes do código fonte desse módulo não servirão para o novo programa; variáveis, sessões, comentários do programa original continuarão a existir no código novo sendo que só servirão para confundir e dificultar o entendimento, sempre que for reutilizar um módulo para servir de modelo para um novo programa é recomendável uma análise do código fonte depois de finalizada a codificação a fim de detectar a existência de dead-code no programa. (Wojciechowski, 2010) Os compiladores COBOL mais atuais possuem análise desses elementos, indicando no relatório de compilação a ocorrência de pedaços do código fonte que nunca serão executados. (AIVOSTO, 2016) No mercado existem produtos específicos para análise desse tipo de situação, muitos deles detectam e otimizam o código automaticamente, sendo a parte desnecessária simplesmente suprimida no momento da compilação e o analista tendo que não se preocupar muito com o que aquele código fazia, afinal ele foi ignorado, porém algumas situações nem o melhor dos produtos pode detectar ou prever e nesses casos o programador fica horas analisando um trecho do programa até descobrir que ele não serve para absolutamente nada. Por exemplo: Caso o programador simplesmente se esqueça de comentar a sessão 2000TRATA- REJEICAO inteira ou de excluir suas linhas de código ela se tornou automa ticamente e sem o menor propósito um código redundante, isto é, ela consta no código fonte, porém jamais será referenciada ou executada. Embora nos compiladores atuais uma mensagem seja gerada informando que determinada parte do código não será executada e consequentemente não será considerada, o programador mais desavisado ou mesmo pela correria da rotina simplesmente ignora esse aviso e o código sem utilidade continuará a existir. A existência de linhas de código sem utilidade é um desserviço para o sistema como um todo, ao se deparar com essa situação o programador ou analista deve prontamente retirar essa parte do programa. O código limpo contendo comentários e possuindo apenas elementos válidos e executáveis no fluxo normal de processamento torna o trabalho de análise muito mais fácil, o analista, programador ou quem quer que esteja lendo o código realizará uma leitura muito mais fácil, conseguirá um entendimento mais linear do código e suas funcionalidades e nos casos de manutenções, sejam elas evolutivas, corretivas ou emergenciais -principalmente nas emergenciais) a tarefa fica muito mais simples. (MANTOAN, 2011) Os fabricantes de software de análise de código, entre eles Aivosto, Semantic Designs, Asetechs, Modern Systems, CA, MicroFocus, são categóricos em afirmar que cerca de 30% a 40% das linhas de códigos de programas do legado do mainframe em COBOL são código redundantes. (Microfocus, 2012) A simplicidade do código deve ser sempre levada em consideração ainda mais em se tratando de linguagem de programação estruturadas como no caso do COBOL. Ao encontrar um código muito rebuscado, utilizando algoritmos complexos, sem comentários ou com comentários que vieram de outros programas e não significam nada para a análise do programa em estudo ou mesmo programas muito extensos (mais de 3000 linhas de código) o analista tende a perder muito tempo para tentar entender para que serve cada variável utilizada e qual o seu domínio (valores que podem ser aceitos), o que cada parte do programa realmente faz, se determinada parte do programa realmente é executada ou se é simplesmente um código redundante. 4.6. Geração de dumb code Existem alguns momentos que são cruciais para a geração ou não de código redundante, são eles: Antes de reutilizar um código fonte já existente: -Ao comprar um código pronto ou customizável pois o vendedor por não ter tomado os cuidados necessários para lhe entregar um código limpo, uma análise minuciosa do código deve ser realizada antes do fechamento da compra ou do contrato. -Ao solicitar a construção do código para uma fábrica de software pois os padrões podem não ter sido seguidos à risca, o modelo utilizado possuir inconsistência ou ainda o módulo entregue não ter sido revisto com os critérios necessários. A revisão de programas oriundos de terceiros DEVE ser sempre realizada antes da aceitação do serviço. Quando um novo membro começa a trabalhar com uma nova sigla ou novo sistema deve-se atentar para que o novato entenda e aprenda como funciona o sistema antes de iniciar suas codificações, para isso a análise dos códigos fontes, fluxos, estudo de manuais é essencial, no momento da análise dos programas o novato pode detectar pedaços de código sem uso e deve realizar sua eliminação. (BODÍK; GUPTA, 1997) Novas versões de programas, em muitas situações a simples evolução de versão do programa já não é mais possível devido a sua complexidade ter alcançado o grau mais elevado possível o não entendimento. Nesses casos o programa precisa ser reescrito e nesse processo para que todas as funcionalidades ainda em uso do programa antigo continuem a existir e funcionar novos módulos são criados. A detecção manual e remoção de código redundante é muito trabalhosa e só é recomendada nos casos de um novo membro integrou-se à equipe e precisa adquirir os conhecimentos daquele sistema ou mesmo na reescrita de programas, nos demais casos o uso de ferramentas automatizadas é mais aconselhável. (Modern Systems, 2016) Existem no mercado inúmeras ferramentas para remoção de dead code, todas elas funcionam basicamente da mesma forma analisando e inspecionando o código fonte a fim de encontrar partes não utilizadas, para isso cada fabricante utiliza seu próprio algoritmo, mas todos geram um relatório da análise e disponibilizam opções para que o usuário decida o que fazer com as partes que não são utilizadas, desde uma simples marcação nas colunas de numeração indicando um dead code, passando pelo comentário dessas linhas ou mesmo simplesmente apagando essas partes do código. (Ca Tecnologies, 2011) Um dos maiores problemas, se não um dos únicos que a automatização da remoção de código redundante pode gerar é a deleção de código bom, por esse motivo as ferramentas informam no relatório que embora tenham detectado determinado pedaço de código como redundante, algumas dessas porções não são certeza, são potencias e recomendam a análise manual do trecho do programa para evitar a exclusão de código utilizável e, portanto, bom. Essa situação caso ocorra pode acarretar no não funcionamento do programa ou nos casos mais graves em comportamento anômalo gerando resultados totalmente imprevisíveis e geralmente catastróficos. 4.7. Revisão de código e padronização Um tópico merece atenção especial que é a revisão do código, a revisão além de servir para garantir que o que foi solicitado realmente foi entregue, fornece uma documentação adicional para o sistema e auxiliam a minimizar os riscos envolvidos no projeto, a detecção de erros no programa, funcionalidade ou mesmo do sistema como um todo antes do envio para a produção, gera uma economia significativa de tempo e dinheiro sem deixar de mencionar em todos os contratempos que um código com problemas gera ao ser baixado em produção. Ao se rever um código, o nível de conhecimento do sistema é aumentado, novos membros podem aproveitar a oportunidade e se inteirar das novas funcionalidades e de como estão interligados e se inter-relacionam os novos componentes do sistema, a preferência à revisão deve ser dada aos membros que não foram os codificadores dos programas, encontrar uma anomalia em um código que a própria pessoa gerou é uma tarefa de titãs, as boas práticas de mercado e padronizações de desenvolvimento de software preconizam que esse tipo de situação seja evitada sempre que possível. (Asetechs, 2016) A padronização e os bons costumes de um dado sistema devem ser levados em consideração quando da revisão do código, porém caso o programa tenha sido desenvolvido baseado no padrão mais atual da organização e precisa ser integrado aos códigos já existentes (mais antigos e com outros modelos) não é recomendável que o código seja aderente ao padrão antigo do sistema. Os novos módulos que forem desenvolvidos e as manutenções corretivas ou evolutivas no sistema devem sempre seguir os manuais e padrões mais atuais da instalação. (Semantic Designs, 2016) Conclusão Ao longo do texto nos capítulos 1 e 3 foram discutidos os aspectos jurídicos da proteção de software, suas origens, leis e tratos internacionais além de ilustrado os dois tipos de proteção existentes por patente ou por direito autoral. Como complementação às leis e para garantir uma proteção efetiva de suas criações os profissionais que trabalham com desenvolvimento de softwares inventaram o ofuscamento de código. O ofuscamento de código protege os programas de computador contra os ataques da engenharia reversa, técnica elaborada que visa a obtenção de segredos do cerne dos softwares, seja o próprio código fonte ou apenas um algoritmo novo. Alguns questionamentos sobre a utilização ou não da engenharia reversa, questões econômicas e exemplos de seu uso foram levantados no capítulo 2. As ferramentas utilizadas para ofuscar um código fonte foram trabalhadas ao longo de todo o capítulo 4. Foram apresentados exemplos de minificação, emprego de código redundante, dumb code e discutidos os aspectos da revisão e da padronização dos programas. As técnicas apresentadas como meios de proteção de código são passíveis de ataques e não garantem a proteção total do código, isso não tem como acontecer, não existe (Boccardo, 2010) uma proteção 100% segura. É impossível proteger sua criação contra a engenharia reversa, pode-se sim, dificultar bastante o trabalho de um eventual adversário. O mercado de espionagem industrial é um fomentador da engenharia reversa, mesmo empresas e industrias renomadas como a AMD (Info World, 1992) já se utilizaram ou ainda utilizam dessa técnica para observar o desenvolvimento dos produtos de seus dos concorrentes e porque não criar novos produtos e serviços que utilizem alguma ideia que acabou de ser descoberta por engenharia reversa. As técnicas de transformação dos programas sejam por ofuscamento, redução, código espúrio adicionam camadas de proteção extra ao código proporcionando uma maior tenacidade, resiliência e robustez contra uma possível tentativa de análise do código (engenharia-reversa). No apêndice C encontra-se um programa de cálculo de tabuada completo e funcional, com comentários, estruturado e de fácil entendimento, por sua vez, no apêndice D o mesmo programa sofreu alterações utilizando-se as técnicas de ofuscamento e seu entendimento é bem complexo. A execução de ambos os programas tem o mesmo resultado e o usuário não consegue perceber qual versão estaria em execução. (Apêndice E) O ofuscamento de código fonte degrada o desempenho e possui custo relativamente baixo e fácil implementação, mesmo que as técnicas a serem seguidas não façam parte de um cadastro prévio elas são facilmente codificadas e podem ser reutilizadas sem muito trabalho, porém toda e qualquer modificação no código fonte original implicará em um maior consumo de processamento. A técnica implementada no programa não deve jamais prejudicar o usuário final do sistema, a preocupação em demasia com o não entendimento do código fonte pode levar a um problema grandioso para o usuário caso algum procedimento que o usuário tome leve a um ponto do programa que não foi previsto, portanto testes são essenciais em programas ofuscados para detectar e corrigir eventuais falhas que foram geradas pelo próprio processo. A relação custo x benefício deve ser analisada com bastante critério pelo analista desenvolvedor juntamente com o time de performance para que os custos adicionais incluídos por ventura do ofuscamento não sejam proibitivos do ponto de vista computacional. Se no código do programa existam segredos, tecnologias inovadoras, algoritmos inéditos ou aperfeiçoados a utilização das técnicas aqui apresentadas é uma boa sugestão para proteção desse software. Referências 1. Acordo sobre Aspectos dos Direitos de Propriedade Intelectual Relacionados ao Comercio Trade-Related Aspects of Intelectual Property Rights. Tratado internacional, integrante do conjunto de acordos assinados em 1994 que culminou na criação a Organização Mundial do Comércio (WTO). 2. AHO, Alfred V.; SETHI, Ravi; ULLMAN, Jeffrey D.. Compilers: principles, techniques, and tools. 2. ed. Boston: Addison-wesley Longman Publishing, 2007. 1038 p. 3. AIVOSTO. Dead code detection and removal. 2016. Disponível em: . Acesso em: 06 out. 2016. 4. AKEMI, Nim Bus., -Virus. VírusBrasil, ed, 1. Disponível em:< http://virusbrasil.8m.com/>.Acesso em: 15 ago. 2016. 5. ASCENSÃO, José de Oliveira, Direito autoral. 2 ed. ref. e ampl. Rio de Janeiro: Renovar, 1997. p. 671 6. ASETECHS Consulting, KRIS applications and services Disponível em:< http://asetechs.com/NewSite2016/Products/KRIS_Solutions.htm>.Acesso em: 20 ago. 2016. 7. AYRES, Robert U. º 57,jul.set 1987. 8. , Paris, Dalloz, 1993, p. 290. 9. BOAZ Barak, Oded Goldreich, Russell Impagliazzo, Steven Rudich, Amit Sahai, Salil Vadhan, Ke Yang, On the (Im)possibility of Obfuscating Programs, Advances in Cryptology Computer Science vol. 2139, pp. 1-18, Santa Barbara, CA, November 2001 10.BOCCARDO, Davidson Rodrigo ; MACHADO, Raphael Carlos Santos ; CARMO, Luiz Fernando Rust da Costa. Transformações de código para proteção de software. In: SIMPÓSIO BRASILEIRO EM SEGURANÇA DA INFROMAÇÃO E DE SISTEMAS COMPUTACIONAIS, 10., 2010, Fortaleza. Anais... Fortaleza: Universidade Estadual do Ceará, Universidade Federal do Ceará,2010. Disponível em: http://www.insert.uece.br/sbseg2010/anais/04_minicursos/minicurso_03.pdf 11.BODÍK, Rastislav; GUPTA, Rajiv. Partial dead code elimination using slicing transformations. In: ACM SIGPLAN 1997 CONFERENCE ON PROGRAMMING LANGUAGE DESIGN AND IMPLEMENTATION, 97., 1997, New York. Conference. New York: Acm, 1997. v. 32, p. 159 -170. 12.BRASIL. Lei nº 10.196, de 14 de fevereiro de 2001 -Altera e acresce dispositivos à Lei n° 9.279, de 14 de maio de 1996, que regula direitos e obrigações relativos à propriedade industrial, e dá outras providências.. Diário Oficial da União. Brasília, DF, 16 fev. 2001. Seção 1, p. 4. 13.BRASIL. Lei nº 9.609, de 19 de fevereiro de 1998 -Dispõe sobre a proteção da propriedade intelectual de programa de computador, sua comercialização no País, e dá outras providências.. Diário Oficial da União. Brasília, DF, 20 jan. 1998. Seção 1, p. 1. 14.BRASIL. Lei nº 7646, de 18 de janeiro de 1987. Dispõe quanto à proteção da propriedade intelectual sobre programas de computador e sua comercialização no País e dá outras providências.. Diário Oficial da União. Brasília, DF, 22 jan. 1987. Seção 1, p. 22221. 15.Ca Tecnologies, Product Sheet: CA Optimizer®/II r8.5 Disponível em: . Acesso em: 25 ago. 2016. 16.COHEN F. . theory and experiments". In: IFIP-TC11, Computers and Security, pages 22 35, 1987. 17. Current trends in computer viruses". In: International Symposium on Information Security, 1991. 18. C Operating system protection through program evolution". Computer Security, 12(6):565 584, 1993. 19. A short course on computer viruses"(2nd ed.). John Wiley & Sons, Inc.,New York, 1994. 20.COLLBERG, C.; THOMBORSON, C.; Low, D. . ing transformations". Technical Report 148, Department of Computer Science, The University of Auckland, New Zealand, July 1997. 21.COLLBERG, C.; THOMBORSON, C; Low, D. . In: ACM SIGPLAN-SIGACT Sym posium on Principles of Progra uary 1998. 22.COLLBERG, C.; THOMBORSON, C; Low, D.. In: Proc. 1998 IEEE International Conference on Computer Languages, pages 28 38. 23.COLLBERG, C.,THOMBORSON, C. and dynamic embeddings", In: Principles of Programming Languages 1999, 24.COLLBERG C.; THOMBORSON C. -proofing, and obfuscation tools for software protection hnical Report TR00-03, The Department of Computer Science, University of Arizona, February 2000. 25.COLLBERG Christian S., THOMBORSON Clark. Watermarking, tamperproofing, and obfuscation -tools for software protection. In IEEE Transactions on Software Engineering, volume 28, pages 735 746, August 2002. 26.COMUNIDADE ECONÓMICA EUROPEIA. Diretiva nº 250, de 14 de janeiro de 1991. Relativa à protecção jurídica dos programas de computador. Conselho das Comunidades Europeias. Bruxelas, 14 jan. 1991. 27.DRAGONI, Matteo, al Dilemma . Tese de obtenção de título de pós doutorado, Universidade de Macerata, Departamento de Jurisprudência, 2014. 28.FERREIRA, Aurélio Buarque de Holanda. Novo Dicionário Eletrônico Aurélio. Curitiba: Positivo, 2010. CD-ROM. 29.FETRIM, Valéria Delisandra. Apoio à Documentação de Engenharia Reversa de Software por Meio de Hipertextos, Dissertação de Mestrado, USP-São Carlos, 1999. 30.GORDON, Yefin.; Rigmant Vladimir. Tupolev Tu-4: Soviet Superfortress, Midland Publishing Limited, 2002. 31.IBM. CICS Transaction Server. Disponível em: . Acesso em: 03 set. 2016. 32.INFO WORLD. São Francisco: Idg -International Data Group, v. 14, n. 49, 7 dez. 1992. 33.LYNN, B., M. Prabhakaran and A. Sahai, Positive results and techniques for obfuscation, Computer Science (2004), pp. 20 39. 34.MANTOAN, Fernando. Simplicidade de Código. 2011. Disponível em: . Acesso em: 25 jun. 2016. 35.MICROFOCUS. Transforming the Elephant in the Room: a Mainframe Story. Disponível em: . Acesso em: 05 jun. 2016. 36.MODERN SYSTEMS. What They Seem. Disponível em < http://modernsystems.com/cobol-codeassessment- things-arent-always-what-they-seem/ Acesso em 05 out. 2016. 37.MURTA FILHO, Antonio. Aspectos Penais Inovadores da Recente Lei 9.609, de 19.2.98. In Revista da ABPI, No. 29, Jul-Ago 1997. p. 29-33 38.ORGANIZAÇÃO MUNDIAL DA PROPRIEDADE INTELECTUAL. Acordo de Direitos Autorais, 20 dezembro 1996. Disponível em: . Acesso em: 27 jun. 2016. 39.PENTEADO, Rosângela. Engenharia reversa e reengenharia. 01 mar. 2009, 01 jul. 2009. 18 p. USFCar, Notas de Aula. 40.PEREIRA DOS SANTOS, Manoel. A Nova Lei de Software -aspectos controvertidos da protecão autoral, In Revista da ABPI, No. 29, Jul-Ago 1997. p. 29-33 41.PEREIRA DOS SANTOS, Manoel. Licença de Software. In Revista da ABPI, No. 25, Nov-Dez 1996, p. 39-46 42.Semantic Designs, COBOL CloneDR. Disponível em: http://www.semanticdesigns.com/Products/CloneDR/COBOLCloneDR.html? Home=COBOLTools>. Acesso em: 15 jul. 2016. 43.SICSÚ, Abraham Benzaquen. Em: Abraham Benzaquen SICSÚ , Orgs., Política Científica e Tecnológica: no Japão, Coréia do Sul e Israel. 1989, CETEM / CNPq, Rio de Janeiro. 44.SOMEKAWA, Daniel Marques. Ofuscamento de Código para Proteção de Programas Java contra Engenharia Reversa, Monografia de especialização, Universidade Tecnológia Federal do Paraná, 2012. 45.ULMER E, KOLLE G, "Copyright Protection of Computer Software", Syracuse Journal of International Law and Commerce, Vol. 14, No 2, 1983. 46.VIVANT Michel, "Software Protection", International Forum for the Union of the Mediterranean and the Challenges of Information Technology (IFUMCIT), Egito, 19.11.2009 47.VENKATESAN, Ashwini, "Code Obfuscation and Virus Detection", Tese de obtenção de título de mestre, Department of Computer Science, San Jose State University, 2008 48. Linguagem de Programação COBOL para , 2ª ed., Rio de Janeiro, Ciência Moderna., 2010. 49.WROBLEWSKI, Gregory, neral Method of Program Code Obfusca- Tese de obtenção de título de pós doutorado, Wroclaw University of technology, Institute of Engineering Cybernetics, 2002. 50.WU, Zhenyu; GIANVECCHIO, Steven; XIE, Mengjun. Mimimorphism: a new approach to binary code obfuscation. In: CCS '10 PROCEEDINGS OF THE 17TH ACM CONFERENCE ON COMPUTER AND COMMUNICATIONS SECURITY, 17., 2010, Nova Iorque. Nova Iorque: ACM, 2010. p. 536 -546. 51.ZAYTSEV, Vadim V.. A Different Perspective on Code Obfuscation. In: WORKSHOP ON LANGUAGE DESCRIPTIONS, TOOLS, AND APPLICATIONS ( ) 2005, Edinburgh, Scotland, Uk. Artigo para apreciação. Universidade de Amsterdam, 2005. p. 1 -12. Anexo A Folheto de divulgação software de ofuscamento Apêndice A -Código fonte programa COBOL HELLO sem ofuscamento Programa de Hello World em COBOL da figura 5: Apêndice B -Código fonte programa COBOL HELLO ofuscado Programa Hello Ofuscado da figura 6: Apêndice C - Código fonte programa TABUADA sem ofuscamento Apêndice D - Código fonte programa TABUADA ofuscado Apêndice E Execução do programa TABUADA Figura 7 -Execução do programa TABUADA

terça-feira, 15 de novembro de 2022

Master the Mainframe - Concurso da IBM que "ensina" o pessoal a usar um mainframe!

Atualizacao 2024 09 25 

- Oficina do futuro ja era
- Eu curti usar o VSCode pra mexer no mainframe, mas é melhor continuar no idZ/rDz seila que sigla que tem hoje, enfim, o eclipse pro sistema Z
- o Master the Mainframe virou um Hackton qualquer gameficado, nao gostei e nao participo ha um bom tempo.


segunda-feira, 18 de julho de 2022

Quando eu passei duas vezes no concurso do Banco do Brasil

E não é que eu nem lembrava que tinha passado duas vezes no concurso do BB ?!?!!?!

O site que mostra a aprovação é o

https://www37.bb.com.br/portalbb/resultadoConcursos/resultadoconcursos/arh0_lista.bbx?cid=730565

Captura de tela de minha dupla aprovação no Banco do Brasil
Figura1: Aprovado no BB duas vezes!

O texto que escrevi ta aqui embaixo,... -------------------------------------------------------------------------------------------------------------------------------------------------------...

Ia ser uma publicacao normal, mas nao rolou porque passa da quantidade de caracteres que a plataforma do linkedin permite...

A Ju conversou comigo hoje cedo sobre sair de um emprego e depois voltar pra ele, acabei divagando aqui na conversa e me afloraram algumas memorias que vou registrar pra não esquecer.

Consegui lembrar que vivi essa situação ao menos uma vez, quando prestei serviço pra IBM e voltei depois de um breve periodo na CI&T, que até hoje ainda não sei ao certo porque pedi pra sair e que é disparado a melhor firma que trabalhei, pode perguntar pro meu filho Vinicius e pro proprio dono, o Cesar Gon, que quando me desliguei, fiz questão de achar ele pra dizer isso pessoalmente!

As minhas passagens pela IBM foram tranquilas, tenho amigos que levo até hoje, ontem mesmo troquei ideia com a Greicy que esta lá no Banco Itaú há quase 5 anos, me peguei pensando que o tempo voa... quando dei um trampo lá no CTO do Itaú almoçei com ela e isso ja deve fazer uns bons 3 - 4 anos.

Na CI&T arrumei amigos novos, e reencontrei muitos outros que eu tinha trabalhado na sede da Stefanini em Jaguariuna, aqui do lado de casa, que foi o meu primeiro trabalho fora do mundo do funcionalismo público, valeu Valfredo, pela oportunidade!

Lembrei tambem de um caso muito peculiar e inusitado, eu um xóven com seus 20 e poucos anos, trabalhava feliz e contente na agencia Barão de Itapura do Banco do Brasil aqui em Campinas, um dia o gerente saiu pra ir seilá pra onde... e coincidencias da vida e parafraseando o poeta 'a gente sempre se encontra duas vezes na vida' e o mundo é pequeno; hoje trabalho de novo com ele no Banco Original.

O gerente que entrou no lugar não era um cara facil de lidar, cobranças descabidas, criticas na frente de todos, metas irreais, obrigação de fazer horas extras... não era só um sentimento meu, era geral. Eu me ferrei com o chefe novo, logo que ele chegou resolveu trocar meu horario, eu tava de boinha trabalhando minhas 6 horinhas de jornada de bancario, do meio dia as 18:15, conseguia ir pra Unicamp nas aulas de manha e de noite.

Com o passar do tempo a galera foi saindo, saindo leia-se trocando de agencia, eu tentei, tentei muito, mas não rolava, à época, o Amarelinho não tinha um processo claro para movimentação de funcionario sem comissão, que era meu caso, escrevi pra gestao de pessoas regional, nacional e pro diretor de pessoas, nada de alguem me ajudar.

Ai dei uma sorte daquelas e achei a solução, eu mesmo! Fui fazer o concurso de novo do Banco do Brasil e pensei que se eu passasse deveriam me chamar pra alguma agencia aqui da região, eu estava topando qualquer parada, tava muito ruim o clima na agencia e meu trabalho em si.

Hoje a galera chama a situação que eu vivi de "ambiente tóxico de trabalho" e "assedio moral", lembrei que até meu poster do matrix que eu tinha no meu cafofo lá na agencia o gerente novo mandou tirar.

Enfim, passei no concurso, mas antes de me chamarem pra tomar posse eu consegui uma transferencia pra um projeto piloto de agencias nivel 5, fiquei uns meses trabalhando com a Graça lá na superintencia no centro e montamos a agencia no Shopping Dom Pedro, foi uma delicia, trampinho gostoso, do lado de casa, no meio do caminho de casa pra Unicamp, horario certinho do meio dia as 6 de novo, foi uma das melhores épocas que tive no amarelinho.

Um dia me ligaram pra avisar que eu tinha passado no concurso e que tinha seila uma semana pra me apresentar e tomar posse... adivinha onde ?!?!?!?!?!

Enfim, fiquei alguns anos na agencia do Shopping, acabou que mudou todo mundo, eu tinha me formado, estava crente na minha cabeça que eu seria promovido e puf, chega um novo gerente, perdi o tesão... e acabei voltando pra Barão de Itapura, pra trabalhar num posto de atendimento que tinha naquele Elefante Branco da Dom Pedro, o CTI e acabei ficando, seila, acho que nem 3 meses que foi quando a Paula me chamou pra ir pra Tecnologia lá em Brasilia, em um processo seletivo interno que outro dia eu conto, por Brasilia fiquei longos anos, aprendi um oficio novo, dois na verdade e como tudo na vida se repete, eu novamente achei que seria promovido, dessa vez era certo, o Mané tinha prometido e tudo na minha cabeça levava a crer que seria mesmo, mas ai o Perez aposentou e junto com ele sua vaga de AP-4, puf, perdi o tesão de novo.

Depois dessa, acho que fiquei mais 1 ano no BB e pedi pra sair. Tinha deixado de ser concursado, 'funcionario publico', bancario e me tornaria um programador, analista, engenheiro de software, o nome que o valha!

Até que virei bancario de novo, agora no Banco Original.

Resumo da ópera, se nao esta legal, tente mudar, pode demorar, um dia voce consegue!

Mude de setor, de empresa, de atividade!

Só nao saia batendo portas e brigando com a galera porque pode ser que um dia voce volte, por vontade propria ou por simples destino!

E quando voltar, se voltar, as coisas não serao as mesmas, muitas pessoas ja nao estarao por lá e talvez os motivos que te levaram a sair nem existam mais.

É isso, no final das contas eu continuo fazendo amigos no trabalho!...

-------------------------------------------------------------------------------------------------------------------------------------------------------

lá no linkedim mesmo

https://www.linkedin.com/posts/buga-lu_saia-numa-boa-vai-que-um-dia-voc%C3%AA-volta-activity-6950591226962149376-5rX1

quarta-feira, 6 de julho de 2022

Saia numa boa, vai que um dia você volta!

Resumo: Buga compartilha memórias de mudanças de emprego na IBM, CI&T e Banco do Brasil, refletindo sobre ambiente tóxico e conselhos pra carreira.

Memórias de Carreira: Mudanças, Ambiente Tóxico e Lições

Ia ser uma publicação normal, mas não rolou porque passa da quantidade de caracteres que a plataforma do linkedin permite...

Contexto da Reflexão

A Ju conversou comigo hoje cedo sobre sair de um emprego e depois voltar pra ele, acabei divagando aqui na conversa e me afloraram algumas memórias que vou registrar pra não esquecer.

IBM e CI&T

Consegui lembrar que vivi essa situação ao menos uma vez, quando prestei serviço pra IBM e voltei depois de um breve período na CI&T, que até hoje ainda não sei ao certo porque pedi pra sair e que é disparado a melhor firma que trabalhei, pode perguntar pro meu filho Vinicius e pro próprio dono, o Cesar Gon, que quando me desliguei, fiz questão de achar ele pra dizer isso pessoalmente!

As minhas passagens pela IBM foram tranquilas, tenho amigos que levo até hoje, ontem mesmo troquei ideia com a Greicy que está lá no Banco Itaú há quase 5 anos, me peguei pensando que o tempo voa... quando dei um trampo lá no CTO do Itaú almocei com ela e isso já deve fazer uns bons 3 - 4 anos.

Na CI&T arrumei amigos novos, e reencontrei muitos outros que eu tinha trabalhado na sede da Stefanini em Jaguariúna, aqui do lado de casa, que foi o meu primeiro trabalho fora do mundo do funcionalismo público, valeu Valfredo, pela oportunidade!

Banco do Brasil e Ambiente Tóxico

Lembrei também de um caso muito peculiar e inusitado, eu um xóven com seus 20 e poucos anos, trabalhava feliz e contente na agência Barão de Itapura do Banco do Brasil aqui em Campinas, um dia o gerente saiu pra ir seilá pra onde... e coincidências da vida e parafraseando o poeta 'a gente sempre se encontra duas vezes na vida' e o mundo é pequeno; hoje trabalho de novo com ele no Banco Original.

O gerente que entrou no lugar não era um cara fácil de lidar, cobranças descabidas, críticas na frente de todos, metas irreais, obrigação de fazer horas extras... não era só um sentimento meu, era geral. Eu me ferrei com o chefe novo, logo que ele chegou resolveu trocar meu horário, eu tava de boinha trabalhando minhas 6 horinhas de jornada de bancário, do meio dia às 18:15, conseguia ir pra Unicamp nas aulas de manhã e de noite.

Com o passar do tempo a galera foi saindo, saindo leia-se trocando de agência, eu tentei, tentei muito, mas não rolava, à época, o Amarelinho não tinha um processo claro para movimentação de funcionário sem comissão, que era meu caso, escrevi pra gestão de pessoas regional, nacional e pro diretor de pessoas, nada de alguém me ajudar.

Aí dei uma sorte daquelas e achei a solução, eu mesmo! Fui fazer o concurso de novo do Banco do Brasil e pensei que se eu passasse deveriam me chamar pra alguma agência aqui da região, eu estava topando qualquer parada, tava muito ruim o clima na agência e meu trabalho em si.

Hoje a galera chama a situação que eu vivi de "ambiente tóxico de trabalho" e "assédio moral", lembrei que até meu poster do Matrix que eu tinha no meu cafofo lá na agência o gerente novo mandou tirar.

Enfim, passei no concurso, mas antes de me chamarem pra tomar posse eu consegui uma transferência pra um projeto piloto de agências nível 5, fiquei uns meses trabalhando com a Graça lá na superintendência no centro e montamos a agência no Shopping Dom Pedro, foi uma delícia, trampinho gostoso, do lado de casa, no meio do caminho de casa pra Unicamp, horário certinho do meio dia às 6 de novo, foi uma das melhores épocas que tive no Amarelinho.

Um dia me ligaram pra avisar que eu tinha passado no concurso e que tinha seilá uma semana pra me apresentar e tomar posse... adivinha onde?!?!?!?!

Enfim, fiquei alguns anos na agência do Shopping, acabou que mudou todo mundo, eu tinha me formado, estava crente na minha cabeça que eu seria promovido e puf, chega um novo gerente, perdi o tesão... e acabei voltando pra Barão de Itapura, pra trabalhar num posto de atendimento que tinha naquele Elefante Branco da Dom Pedro, o CTI e acabei ficando, seilá, acho que nem 3 meses que foi quando a Paula me chamou pra ir pra Tecnologia lá em Brasília, em um processo seletivo interno que outro dia eu conto, por Brasília fiquei longos anos, aprendi um ofício novo, dois na verdade e como tudo na vida se repete, eu novamente achei que seria promovido, dessa vez era certo, o Mané tinha prometido e tudo na minha cabeça levava a crer que seria mesmo, mas aí o Perez aposentou e junto com ele sua vaga de AP-4, puf, perdi o tesão de novo.

Depois dessa, acho que fiquei mais 1 ano no BB e pedi pra sair. Tinha deixado de ser concursado, 'funcionário público', bancário e me tornaria um programador, analista, engenheiro de software, o nome que o valha!

Até que virei bancário de novo, agora no Banco Original.

Conselhos Finais

Resumo da ópera, se não está legal, tente mudar, pode demorar, um dia você consegue!

Mude de setor, de empresa, de atividade!

Só não saia batendo portas e brigando com a galera porque pode ser que um dia você volte, por vontade própria ou por simples destino!

E quando voltar, se voltar, as coisas não serão as mesmas, muitas pessoas já não estarão por lá e talvez os motivos que te levaram a sair nem existam mais.

É isso, no final das contas eu continuo fazendo amigos no trabalho!

domingo, 5 de junho de 2022

Arrependimentos, importancia, erros e desculpas!

Reflexão sobre arrependimento, importância e desculpas

Era pra ser um post no facebook, mas acabei me alongando demais nos devaneios... ia falar só de um erro e do pedido de desculpas, mas lá vai!

Tem algumas frases, chavoes que eu não gosto. Esse aqui é um deles.

"Ninguém pode voltar atrás e fazer um novo começo. Mas qualquer um pode recomeçar e fazer um novo fim."

Chega a me dar gastura, porque não tem nada a ver! A única coisa que você pode, realmente, fazer nesses casos é se arrepender por todos os dias do resto de sua vida! Não todos; todos, mas aqueles que você se lembrar.

Bom, isso posto, como diria nosso advogado.... Quando lembro de algum arrependimento, tento não pensar nas consequências do ter feito ou não feito, errei e peço desculpas... mentalmente, sozinho, esperando em vão que o SER receba minhas mais sinceras e verdadeiras desculpas.

O passarinho que atropelei uma vez na estrada não tem mais como eu me desculpar, não nesse plano.

Nesse plano, lembrei do Paulinho que dei um bombao nele na sala de aula e até hoje não sei como não fui expulso do colégio... ainda dá pra eu me desculpar, tenho até o contato dele, mas não consigo.

As vezes me arrependo de ter pedido pra sair do Banco do Brasil, nessas horas tento não pensar muito pra não entrar em parafuso imaginando o tamanho do pé de 'SE' .

Não dá pra refazer arrumar, já foi, é passado só resta seguir em frente e pedir desculpas, quando der e se eu conseguir.

Esses dias mesmo, errei, errei feio... quer dizer na minha cabeça foi! Foi algo muito importante, pra mim, eu que classifiquei como importante, na real, pensando com calma e friamente não tinha importancia alguma!

Não sei se é vergonha, medo, arrependimento, falta de humildade - eu já fiz até teste e sei que não sou nem um pouco humilde - orgulho ferido, grau de importancia, no fundo não sei direito, mas falei que o sentimento era de vergonha, consegui pedir desculpas! Pedi ajuda pra resolver um negócio que eu tinha certeza que estava errado, mas nao tinha o que ser resolvido, estava tudo certo, EU QUE ERREI !...

Talvez fosse algo banal pra quem eu pedi ajuda, a pessoal não deve ter entrado em parafuso procurando a solução, pode ser que tenha anotado num papel pra ver depois ou mesmo que tivesse esquecido, mas pra mim era algo de grande importancia, pra MIM.

Sozinho não conseguiria ver que eu estava errado desde o inicio e que não havia problema algum, eram apenas vozes da minha cabeça!

Tenho que aprender que a importancia das coisas, fatos, sentimentos enfim, a tal da importancia varia de pessoa pra pessoa.

Digamos, para exemplificar, um amiguinho do Vinny veio aqui em casa e abriu minha caixa lacrada da primeira edição limitada, especial do Funko do Batman SteamPunk Cinza e Canhoto que guardo faz 20 anos como um objeto mágico e além desse absurdo de ter pegado; aberto, pra finalizar, o cachorro aqui de casa ainda teria dado umas mordidas no boneco.

Posso não ligar, ficar de boa, todavia e bem mais provavel é que posso ter vontade de matar o pequeno, seus ascendentes e amaldiçoar todos de sua arvore genealógica! E ninguem poderia me reprimir, porque a importancia do boneco é pra mim algo fora da escala, repito, pra MIM.

Vejo que não temos como nos colocar no lugar dos outros, por mais que a gente tente, não tem como! É só um boneco... sim, só um boneco!...

Pode ser que o Funko do Batman não tenha importancia alguma pra voce, seja algo bobo, infantil, banal, beirando o irracional, se bem que a maioria dos sentimentos é algo meio irracional, entao nao é uma boa escolha pro momento, mas deixa ai mesmo.. pra mim também é algo sem importanca, usei apenas um exemplo didatico para explicar meu ponto de vista, mas pro cara que idolatra, o boneco é algo sagrado!

Embora eu não consiga compreender direito o grau de importancia de certas coisas pros outros, todos tem isso, então, se por ventura menosprezei a importancia de algo pra você, e algo aqui no sentido literal da palavra, me desculpe, de verdade, é um erro que cometo e que estou tentando nao fazer mais.

Saber dar importancia pro que é realmente importante é o que importa!

Mas, o que importa?

quarta-feira, 11 de maio de 2022

Novatos no mainframe - Era pra ser um livro.

Notas de Mainframe do Buga: Meu Livro no GitBook

Entre tantas iniciativas e projetos que comecei e não terminei, encontrei este aqui: um compilado de anotações sobre mainframe, linguagens, bancos de dados e experiências que vivi ao longo da carreira. Resolvi compartilhar tudo no GitBook, para ajudar quem está começando ou quer se aprofundar nesse universo.

O que você encontra no livro

  • Linguagens de Programação: ASSEMBLER, COBOL, PL/1, C, REXX, EASYTRIEVE, JAVA, NATURAL, CLIST
  • Bancos de Dados: IMS, ADABAS, DB2, ORACLE
  • Dicas, curiosidades, comandos e exemplos práticos para o dia a dia no ambiente mainframe
  • Conteúdo atualizado periodicamente com novas experiências e aprendizados

Acesse gratuitamente

O conteúdo está disponível de forma aberta no GitBook. Basta acessar o link abaixo:

Notas de Mainframe do Buga no GitBook

quarta-feira, 24 de novembro de 2021

"linguagem de programação" Focus para Mainframe - Manuais

Manuais Clássicos de Mainframe e Analytics: Coleção Rara

Seguem os 6 manuais e o intro que eu tinha guardado aqui em casa.

Introdução

Muito antes de analytics virar modinha, a galera do mainframe já apavorava nessa matéria!

Baixar Introdução (PDF)

Livros para Download

Novidade do Mercado

Acabei de ver que a Tibco comprou a Information Builders.

sexta-feira, 22 de outubro de 2021

Olha o que achei esses dias! Um zine brasileiro da decada de 1990 sobre virus de computador!

Packs Virus Brasil: Acervo Histórico (1997-2001)

https://vault.0x705h.com/en/ezine/virus-brasil

Print do acervo Virus Brasil no vault 0x705h
Acervo digital Virus Brasil no vault 0x705h
Pack Name Reliz Number Released at
virbr0178.zip 1 13/05/1997
virbr02.zip 2 14/07/1999
virbr03.zip 3 14/07/1999
virbr04.zip 4 05/10/1999
virbr05.zip 5 01/01/2000
virbr06.zip 6 01/04/2000
virbr07.zip 7 30/07/2000
virbr0830.zip 8 20/02/2001

terça-feira, 10 de agosto de 2021

TSO ISRDDN MEMBER(xpto) - Achar onde um determinado carga esta!


Por vezes precisei procurar onde um maldito carga executado, CLIST, REXX ou que seja que era excutado direto via TSO estava .

O comando em epigrafe resolve o mistério!

Mainframe, mega dica boa



Atualizacao em 11.06.2025, via IA

Como usar o ISRDDN no Mainframe TSO/ISPF

O que é o ISRDDN?

O ISRDDN é uma ferramenta diagnóstica do z/OS, fundamental para quem trabalha com TSO/ISPF no mainframe. Ela permite listar todos os DDNAMEs (datasets, bibliotecas, arquivos) alocados na sua sessão TSO, facilitando a localização de módulos, cargas e bibliotecas em uso no momento.

Principais funcionalidades

  • Lista todos os DDNAMEs e datasets alocados na sessão TSO/ISPF.
  • Mostra em quais bibliotecas estão os módulos executáveis (load modules).
  • Ajuda a identificar duplicidades, conflitos e bibliotecas vazias.
  • Permite examinar, editar, navegar e executar comandos sobre os datasets listados.
  • Exibe a ordem de busca de módulos (STEPLIB, ISPLLIB, LINKLIST, LPA, etc.).

Como acessar o ISRDDN

  1. No ISPF, digite TSO ISRDDN ou DDLIST na linha de comando e pressione Enter.
  2. Será exibida uma tela com todos os DDNAMEs e datasets alocados na sua sessão.
  3. Você pode pesquisar, navegar, editar ou examinar qualquer dataset diretamente dessa lista.

Exemplo de uso prático

  • Descobrir de onde um programa está sendo carregado: Procure pelo nome do módulo nas bibliotecas LOAD listadas (STEPLIB, ISPLLIB, LINKLIST, etc.).
  • Verificar se uma atualização está ativa: Veja se o módulo atualizado está na biblioteca correta e em uso.
  • Diagnóstico de problemas: Identifique bibliotecas duplicadas, vazias ou conflitos de datasets.
  • Análise de ambiente: Veja todas as bibliotecas que sua sessão está usando, incluindo as do sistema e pessoais.

Recursos avançados

  • Visualizar ENQs (locks) e contendas.
  • Navegar na memória (útil para suporte avançado).
  • Adicionar bibliotecas do sistema à visualização para checar se um módulo está em LPA ou LINKLIST.

Resumo

O ISRDDN é uma ferramenta essencial para suporte, análise e troubleshooting em ambientes mainframe. Com ele, você descobre exatamente de onde está vindo qualquer módulo ou carga em uso na sua sessão, facilitando o diagnóstico e a administração do ambiente z/OS.

terça-feira, 15 de junho de 2021

Recuperar senha salva no MobaXTerm - Password - Putty - Linux

Como recuperar senha salva no MobaXterm (sem comprar a versão paga)

Eu comecei a usar o linux há bem pouco tempo, desde 2019, o programinha que o pessoal usa pra acessar os servidores e fazer magicas... e que acabei entrando na onda é o:

Logotipo do MobaXterm

Figura 1: Logotipo do MobaXterm

A versão free só deixa gravar uma dúzia de servidores (com usuário e senha salvos) e aí que deu a zica... qual que é a senha que salvou no Moba e que ele insere automaticamente na hora de logar?

Fui nas opções e achei lá um montão de usuário e senha, cliquei em "show passwords" e não rolou, a versão free só salva não deixa você ver a senha! É cada uma!

Bom, enfim, segue a captura da tela informando que eu tenho que comprar a versão e bla bla bla, entrei no site, mas 69 dólares achei meio caro, o putty é de graça e eu poderia muito bem usar ele... não!

Tela da versão free do MobaXterm sem mostrar senhas

Figura 2: Versão "free", digo, personal edition não tem algumas funcionalidades

Bom, aí lá fui eu fuçar na net pra achar como resolver esse impasse, até que foi tranquilo.

Achei esse projeto aqui no github:

https://github.com/HyperSine/how-does-MobaXterm-encrypt-password

E tinha que instalar o tal do crytpo qualquer coisa:

https://pycryptodome.readthedocs.io/en/latest/src/installation.html#windows-from-sources-python-3-3-and-3-4

Como a parada de instalar softwares na máquina da firma hoje em dia tá complicado, fui pela rota B, de instalar a parada pelo Visual Studio Code, afinal IDE de desenvolvimento pode instalar na maioria dos "shops".

Nem sei como chama, mas instalei a extensão/plugin/add-on, enfim, pra gerenciar os pacotes de bibliotecas Python... Faz tempo que eu não programo e não via uma IDE toda coloridinha, acho que tinha visto em algum treinamento da IBM mostrando como conectar no mainframe pelo VScode, ver dataset, executar job, editar/escrever programas, mas enfim...

Era isso mesmo, olha o Zowe aqui no meu VSCode:

VSCode com plugin Zowe para mainframe

Figura 3: Meu VSCode com o "plugin" pra instalar mainframe

Junto com o pip manager, o python já tinha instalado no computador, sei lá porque, como ou quando.

PipManager - Extensão Visual Studio Code

Figura 4: PipManager - Extensão Visual Studio Code

Os programas seguem abaixo:

MobaXtermCipher.py - Downoad Link

ShowMobaXterm.py - Baixe no GitHub

Importante: Lembre-se de abrir o registro do Windows e pegar as entradas com a credencial e a senha ou tao no arquivo MobaXterm.ini

sábado, 24 de abril de 2021

Marcos e Comemorações - um post do facebook

Resumo: Buga conta a história de um whisky Johnnie Walker Blue guardado para ocasiões especiais, lista marcos pessoais e reflete sobre celebrar o cotidiano.

O Whisky que Nunca Abri: Uma Reflexão sobre Celebrar o Cotidiano

A Garrafa de Johnnie Walker

Comprei um whisky há muitos anos, acho que é um dos artigos que me acompanha há mais tempo, mais antigo que ele só a minha caixa de memórias e fotos reveladas mas essas estão na casa de mamãe Eliana.

O Jhonny Walker chegou há muito tempo, o pai do Marcelo que comprou em alguma viagem dele pro exterior, não lembro o porquê que pedi pro pai dele comprar e trazer, sei que paguei lá uns tantos dólares pela garrafa e fiquei com o pensamento de abri-la em momento futuro, em uma ocasião especial, um março, algo do tipo, para celebrar mesmo.

A fábrica de skates produz a primeira rodinha e o primeiro shape, nem lembrei do scotch ou se lembrei deixei pra próxima.

Marcos Pessoais sem o Whisky

Eis que vou morar com a Ju e não abri a garrafa, me formei e não abri, passei no vestibular e no mestrado aqui na Unicamp e não abri...

Fui padrinho do casamento do Allan e não tomei o uísque.

Terminei MBA na FGV,

Mudamos para Brasília e não abri na nossa despedida, compramos nosso apartamento e não comemorei tomando o whisky.

Fomos capa do jornal impresso Correio Brasiliense, acho que no aniversário de 50 anos da cidade... Tenho o jornal emoldurado, mas não abri a caixa do whisky.

A Ju passou no concurso da secretaria de Saúde do GDF...

Fui padrinho no casamento do Andre e da Carol.

Compramos nosso primeiro e único carro zero Km,

Meu pai conseguiu emprego na prefeitura depois de um bom tempo sem trampo, não comemorei.

Desmaiei no altar do casamento da Ma e do Du... Fomos padrinhos, o uísque continuou na caixa.

O Vinny nasceu,

Passei na UnB,

Os Pork's vão pra Brasília conhecer o Vinícius, nem lembrei de abrir o whisky.

Meu irmão teve uma parada cardio respiratória e não comemorei sua recuperação.

Minha irmã formou, meu irmão formou.

Fui promovido no serviço, ajudei a criar e fazer funcionar o cartão Amex no Banco do Brasil... e o cartão ELO, viajei pros States com o presidente do Banco do Brasil autorizando a viagem com publicação no diário oficial da união, ganhei um passaporte "oficial", baita marco na carreira... E o uísque nada, ali, na caixa, junto com outras bebidas no bar na cozinha.

Voltamos pra Campinas e não tomei o whisky na nossa despedida de Brasília.

Vivi um ano inteiro indo e vindo de Campinas pra São Paulo todo dia e não comemorei que conseguia ver minha família com frequência.

Fiz um treinamento inesquecível, me tornei educador corporativo, virei professor... de Cobol!

Pedi pra sair do Banco do Brasil e não tomei o whisky com meus amigos na minha despedida.

Mudo meu nome, crio o clã Buga... E ainda esperando um marco, um grande evento para comemorar com o uísque.

Termino uma pós graduação, passo no vestibular da Fatec para cursar computação...

A Ju toma umas 10 bolsas de plasma, a Helena nasce apagada... Tudo certo no final, o Jhonny Walker continua em sua caixa.

Meu pai realiza o sonho de ter um V8 de novo, veio me mostrar quando comprou, não comemorei.

Saio da IBM e vou trabalhar na CI&T, baita firma, negócio que a gente vê nas matérias de televisão, não comemorei...

A Ju consegue depois de muitas tentativas um emprego tão querido na indústria farmacêutica!

Volto pra IBM porque minha praia é mainframe e ia almoçar de novo com a Ju - igual nos tempos de Brasília!

Passo no vestibular da Unicamp...

Vou morar em São Paulo de dia de semana com meu pai... não comemorei.

Começou a pandemia e volto a morar aqui em casa, tava duro longe das crianças, da Ju, da Sheeva e da Sophia, sequer lembrei do uísque.

A caixa do Jhonny Walker me acompanhou no AP do seu Madruga, depois no 44, lá na Hermantino Coelho, na Jasmim, foi pra Formosa, pra 716 norte, pra Águas Claras, voltou aqui pra Barão Geraldo e eu esperando um grande marco pra abrir e comemorar!

Lição Final

Com certeza esqueci grandes marcos e acontecimentos que mereciam ser celebrados com esse scotch... Mas na real eu tinha que ter tomado era mesmo em um churrasco qualquer rodeado dos meus amigos e da minha família.

Não guarde os talheres e louças especiais para ocasiões especiais!

Todo dia é especial!

Ah, e o whisky é muito bom. Mas não tenho paladar, sou mais o licor de menta mesmo!

Wisky johnie walker blue label
Figura 1: Johnie Walker Azul

segunda-feira, 25 de janeiro de 2021

Instalando jogos no Nintendo Switch

Segue o vídeo do carinha que fez o trampo.

0:00 Fala amigo bom dia tudo bem É o seguinte 0:02 vou fazer um vídeo bem rapidinho aqui tá 0:04 porque eu não faço instalação de jogos 0:06 para cliente tá eu ensino tá porque cara 0:08 eu não tenho tempo tenho muito 0:10 equipamento para fazer então não tô 0:12 acostumado a instalar jogos mas eu vou 0:13 instalar um jogo aqui para poder te 0:15 ensinar tá é bem simples e fácil ã você 0:18 vai baixar o jogo lá no torrent no lugar 0:20 onde você preferir lá home tá você vai 0:23 entrar nesse programinha aqui no dbi tá 0:25 com o cabo conectado no computador 0:28 tá aí o programinha vai abrir dessa 0:31 forma aqui tá abrindo dessa forma aqui 0:34 você vai descer até para ele poder aqui 0:38 ó room MTP responder tá você vai apertar 0:42 o a ele vai se conectar e abrir essas 0:45 pastas aqui automaticamente tá abrindo 0:48 essas pastas aqui você vai aqui dentro 0:51 de SD Card tá dentro de SD Card você vai 0:56 arrastar o jogo que você quer instalar 0:59 então caso aqui deixa eu diminuir a aba 1:02 aqui isso você vai arrastar o joguinho 1:06 para cá tá arrastou o joguinho para cá 1:10 ele vai fazer a cópia do jogo tá aqui 1:13 demora um pouquinho para copiar vou 1:14 interromper o vídeo até finalizar a 1:16 cópia

quinta-feira, 3 de dezembro de 2020

Como NÃO Passei na Certificação de fundamentos de nuvem da IBM ## C1000-083 Foundations of IBM Cloud V2

Relato da Prova de Certificação IBM Cloud – Quase!

Ainda to me perguntando, nao sou muito bom de decorar as coisas, talvez isso tenha contribuido pro fato de eu ter errado 2 questoes a mais que o permitido!!!!

Só nao fiquei muito mais decepcionado com meu desempenho porque recebi um voucher da IBM pra fazer a prova na base da camaradagem, pro Brasil alguem pagar do bolso uma certificacao de 200 doletas (é quase preço tabelado, das que ja tive interesse pra fazer é esse o valor) é muito caro, e o retorno/reconhecimento/ajudar na carreira/o que te falarem de baboseiras, na real é bem baixo!

Resultado da prova IBM Cloud - Quase

Figura 1 - Quase quase mesmo... 68 sendo o corte 71, duas questões!

Computing Options e Storage - IBM Cloud

Figura 2 - Computing Options e Storage -- a maldita decoreba, tinha que chamar tudo igual essas coisas nas nuvens todas!

Fiz o treinamento da própria IBM, o do Coursera, estudei, fiz os labs, muitos testes, o que faltou?... Sinceramente não sei...

Bom, deixa eu colocar aqui meu material de estudo afinal, vai que um dia eu presto a prova de novo?!!?!?!

https://learn.ibm.com/course/view.php?id=7739 --> Curso da própria IBM, bem prolixo e sem muita sequência lógica

Certificado curso preparatório IBM Cloud

Figura 3 - Curso preparatório

Fiz também IBMDeveloperSkillsNetwork: CC0101EN - Introduction to Cloud

https://cognitiveclass.ai/courses/introduction-to-cloud

Certificado Introduction to Cloud

Figura 4 - Curso que tem no Coursera e descobri depois que tem na própria IBM, nem tinha dado o ok de finalizado, fiz agora e já tá aí o certificado!

IBMDeveloperSkillsNetwork: CC0103EN - IBM Cloud Essentials - V3

https://courses.cognitiveclass.ai/courses/course-v1:IBMDeveloperSkillsNetwork+CC0103EN+2020T4/course/

Certificado IBM Cloud Essentials V3

Figura 5 - Curso que tem no Coursera e descobri depois que tem na própria IBM

Bom, como não uso mais caderno direito nem folha de anotações, segue "meus estudos":

https://docs.google.com/document/d/1uKSM0KqDMlvxNLCfJ_AHOfuiSQQDSu6Dn49R126e2AY/edit?usp=sharing

E olha... foi por bem pouco, 2 fucking questions como diriam os ingleses!...

segunda-feira, 24 de agosto de 2020

20 anos de Banco do Brasil, uma despedida dolorosa pro Buga

20 anos de Banco do Brasil: trajetória, despedida e reflexões

 Esse mês faria 20 anos de Banco do Brasil, faria, porque em Janeiro fui meio que obrigado a pedir demissão, meio porque a outra opção seria demissão por justa causa devido abandono de emprego. 

Figura 1 - Volta agora, peça demissão ou será demitido por justa causa

Senti na pele que para a maioria das empresas somos apenas um número, mais nada! 

Não tive uma das mais brilhantes trajetórias profissionais, entrei no banco ainda moleque, cursava o 2º ano de Engenharia Química aqui na Unicamp, em período integral, trabalhava 6 horas na agência Barão de Itapura, das 12:00 às 18:15, logo de inicio trabalhei no PAB da Telesp, depois fecharam o PAB e fui pra agencia propriamente dita, as vezes ia pro pab do CPQD do lado de casa, mas sempre eu conseguia assistir as aulas no período da manhã e as do noturno, tomava umas cervejas quase que semanalmente com o pessoal de lá, seja no posto, na cachaçaria, no Farol do Pirata, na casa do Vidson, na casa do Capela, lá em Sousas no Benito, no meu apartamento aqui em Barão, lá em Valinhos na casa do Japonês e em tantos outros lugares legais e alguns nem tanto, hoje a memoria já começa a pecar, preciso reaviva-las encontrado o pessoal. 

A turminha lá da Barão de Itapura era bem legal, alguns tenho contato até hoje, o filho do Zen fez medicina na Unicamp algumas turmas depois da Ju, sempre encontro ele em eventos do pessoal da medicina, moleque gente fina, igual o pai! Outros viraram amigos pra vida toda, alguns sumiram e nunca mais tive notícias, o Fabricio tinha voltado pra Manaus, achei que nunca mais o veria, encontrei ele uma das vezes que fui pra floresta amazonica e alguns anos depois ele se mudou pra Brasilia e nos trombamos algumas vezes por lá,.. enfim é o curso natural da vida, pessoas vem e vão... 

Eu me formaria quase sem nenhum atraso, nessa época a gente não pensa muito no futuro, ainda mais num futuro profissional, eu vendia meu tempo pro banco e ele me pagava um ordenado que era muito bem vindo.... Ao me aproximar do final da faculdade eu tinha que fazer estágio para me formar, os estágios, não lembro ao certo, mas pagavam por volta de 700 reais, eu lembro que meu salário era quase 3 vezes mais que isso, e voce se acostuma muito fácil com gastar quanto você ganha, na verdade sempre faltava algum no final do mês, na ponta do lápis não ia dar.

Fiz estágio só pra poder formar mesmo, fiquei uns meses indo pra Acme, firma do pai do Amaral de rodas de empilhadeira e acabei saindo de lá com a brilhante ideia de montar uma fábrica de rodinhas de skate, mas isso é outra história,.. mudei de agência quando o Wagner deixou de ser o gerente geral e foi virar superintendente, nunca mais tinha tido noticias dele, esses dias recebi um informe aos acionistas, virou diretor, não sei do que... enfim, meu santo nao bateu com o gerente novo, eu havia separado da Vera e trabalhar junto nao estava nem um pouco legal, o Vitão tinha saido do banco, o Christian também, o Andre tinha ido pra Europa...enfim, tava na hora de mudar, mas nao tinha um processo para troca de lugar de trabalho em vigencia no banco, cheguei a prestar concurso de novo pra tentar trocar de agencia, apareceu uma vaga antes de chegar o resultado do concurso... 

http://www37.bb.com.br/portalbb/resultadoConcursos/resultadoconcursos/arh0_lista.bbx?cid=169

Figura 2 - Volta agora, peça demissão ou será demitido por justa causa

Embarquei num projeto piloto de agencias nivel V, disruptivo pra época, uma agencia sem caixas! Fiquei um tempo na superintencia trabalhando com a Graça pra abrirmos a agencia, era no Shopping Dom Pedro, do lado de casa. Era eu de caixa, a Graça, o Marcos, a Chris (nunca mais tive noticias) e a Carla, turma excepcional também! Nesse meio tempo caiu a ficha que eu nao ia trabalhar de engenheiro mesmo, o salario do trainee ou do engenheiro recem formado já levava fumaça do meu trabalho no banco, ainda mais que a agencia era minuscula e quando a Graça saia tinha substituição, teve um ano que eu fiquei de gerente da agencia no mes do decimo terceiro que digo pra voces, nunca tinha visto tanto dinheiro na minha conta, no final do ano na segunda parcela do decimo terceiro, tive que fazer emprestimo pois ao inves de receber salario, tive um desconto em folha dos bons! Retomando a cronologia... fui atras de seleções internas para tentar virar gerente, nunca fui fã do TAO, sistema de "talentos e oportunidades" tinham falhas e mesmo voce estando bem classificado o que vale sempre é a entrevista e nessas, nunca, nunca me dei bem, sou um cara muito eu e não consigo deixar passar ou interpretar um papel. Eu escutava, poxa Buga, ao menos nao vai de toca e de tenis pra entrevista, pare de perguntar se a entrevista é séria ou se já tem alguem escolhido pra vaga! Não gosto, nunca gostei, nao encaro esse tipo de teatro! 

Não lembro ao certo o como ou porque, deve ser coisa do TAO... acabei sendo aprovado para cursar um MBA patrocinado pelo banco na FGV para executivos, show de bola, vamos que vamos, já que eu ficaria no banco mesmo, vamos investir... nesse meio tempo eu estava com a fabrica de rodinhas rodando, com bolsa de ingles do banco, cursando Quimica com a irmã do Boy e fazendo mestrado com o Paoli em plasticos degradáveis, pra variar não deu pra largar o banco ṕra receber bolsa de mestrado, declinei a bolsa e o mestrado estava rodando sem patrocinio... em teoria eu não poderia receber bolsa se eu tivesse um emprego, regras sao regras, vai entender!...

Sei que um dia na agencia de noticias apareceu um "processo seletivo" pra trabalhar na Diretoria de Tecnologia, nao tinha pre requisito muito claro, me inscrevi no TAO e acabei sendo convocado pra entrevista, sabe-se la porque fui fazer em Curitiba, aproveitei dei uma passada lá em São Bento do Sul pra visitar o Jean e fechei a compra da fabrica de shapes dele! Outra historia das boas! O processo seletivo foi muito interessante, lembro bem ainda, acho que pelo ineditismo da situação e pela transparencia no processo, pela manha um bate papo com 3 entrevistadores e 6 candidatos, e a tarde uma conversa tecnica sobre assuntos de tecnologia, eu até então de tecnologia só sabia programar em assembler de micro, foi um show de horrores, não sabia responder nada, mas sempre sobrava algo de lógica e bom senso que dava pra dar uns pitacos! Eu depois da terceira pergunta que passei, pedi desculpas por estar ali desperdiçando o tempo do pessoal, mas falaram que nao tinha problema e vamos em frente, no final do dia tivemos o feedback, lembro bem chamaram cada candidato individualmente e eu fui o ultimo, acho que aquele dia, só o Idelvan passou, o Evaristo nem lembrava dele, mas quando ele chegou lá por Brasilia a memoria ativou, pra ele nao tinha sido daquela vez, mas pŕa mim foi e foi muito doido, entrei na sala, a entrevistadora me descascou, que minha postura não é adequada, que parece que eu estava lá de brincadeira, que nao era nem pra eu ter me inscrito se não tinha formação em tecnologia e bla bla bla, ali rolou aquela lagrima velada e a engolida seca, agradeci e estava pra me levantar da cadeira e o Osiris falou, espera, não acabou, pensei caralho, vai me por mais pŕa baixo ainda, mas não ele falou com um ar de "vou te dar o beneficio da dúvida", que embora eles 3 concordassem com o que - cara, não lembro o nome da japa, vou ter que perguntar pro michel - ela disse, eles acharam que eu tinha grande potencial e que seria dado um treinamento a todos que fossem ṕra Brasilia trabalhar na Diretoria de Tecnologia (DITEC) pois quase nada do que se ensina na faculdade era utilizado por lá. Parabéns Buga, voce esta aprovado, quando finalizarmos o processo entramos em contato.

Nesse meio tempo, acabei saindo da agencia do Dom Pedro e voltado pra Barão de Itapura, tinham inventado no TAO um sistema de remoção automatica e lá fui eu trabalhar num PAB dentro do elefante branco CTI Renato Archer lá na Dom Pedro, num belo dia a Paula me liga perguntando se eu ainda estava a fim de ir pra Brasilia, já devia ter passado um ano da entrevista em Curitiba, não tinha desencanado, mas estava com poucas esperanças... respondi que precisava de uns dias pra pensar, conversei com minha mãe, com o Allan, com meu pai e com a Ju e ficamos assim, o seu Irá ia cuidar da fabrica, a Ju ia terminar a residencia e eu em Janeiro ia pra Brasilia trabalhar na Ditec!

A Ju descolou um republica no Cruzeiro de um menino da Unb pra eu morar e lá fomos nós de carro levando tudo que coube no Uninho e que eu fosse precisar nos proximos meses, Chegamos em Brasilia num dia chuvoso, cai num buraco, entortou a roda, tive que trocar o pneu na chuva, nao tinha waze ainda, google maps idem, na real nem lembro como que conseguimos chegar no apartamento do cruzeiro. Sei que não fui uma bela impressão que tive da cidade nesse meu primeiro contato.

No treinamento conheci mais um monte de colegas que tinham acabado de largar tudo pra trás e assim como eu se aventurado no planalto central, eu diferente dos demais, tinha caido de paraquedas, afinal não tinha formação ou conhecimento de informatica. O treinamento foi longo e bem completo, sai de lá com muitos amigos - que nos acompanharam todos os anos que tivemos em Brasilia - e como um desenvolvedor mainframe!... Sabia JCL, Cobol, DB2, Natural, sabia usar o Roscoe e apertar F1 se tivesse alguma duvida no TSO, alguns instrutores eram muito bons, outros nem tanto, tiveram provas bem difíceis, programas elaborados, testes, palestras, apresentações, posso dizer que foi um belo dum aprendizado. 

Saindo do treinamento fui parar na equipe do autorizador, fiquei com medo, me disseram que era o coração do sistema, naquele ponto a gente já tinha um conhecimento do que era o sistema VIP pois ledo engano quase todos do curso iriamos trabalhar com cartão e assistimos algumas palestras sobre o sistema, nunca me imaginei com tanta responsabilidade, basicamente os módulos que eu trabalharia são os responsáveis por aprovar ou não uma compŕa com o cartão de qualquer cliente do Banco do Brasil.

O que mais devo ter feito na Ditec foram cursos, cara, como eu estudei, aprendi como que funcionava o sistema de pagamentos com cartões, fiquei craque na ISO8583, aprendi como funciona o chip do cartao, criptografia, assembler de mainframe, GRI, CICS, DB2, VSAM e mais uma salada de letrinhas, aprendi a usar os simuladores de transações das bandeiras (bandeiras são a Visa, Mastercard) quando entrei tinha só essas duas, depois fizemos o sistema processar Amex que nem tem mais, algum tempo depois surgiram com a bandeira Elo, foram muitos anos de aprendizado e trabalho duro.

Tive promoção seguida de promoção, não acredito que só por mérito, estava no lugar certo na hora certa, e o santo do chefe Mané bateu legal com o meu, tinha gente que nao curtia ele não, eu achava um cara justo, as vezes meio escroto, mas dava pra levar numa boa... talvez algumas madrugadas com o Luizinho junto vendo a dedicação da equipe, enfim, a gente era muito phoda e a galera de cima sabia disso e nos recompensou, na equipe do autorizador depois de 2 anos que eu estava lá, todos nós já estavamos com cargo de analista senior. 

Figura 3 - Convite comemoração promoção/aniversário do Buga 

Iamos pra Sao Paulo participar de treinamentos com as bandeiras, reunioes na Visanet e na Redecard, testes na TecBan, cheguei a ir pros Estados Unidos com o Perez, ali foi o ápice da minha carreira e a certeza que quando o Cabelo aposentasse eu ficaria com a vaga de consultor dele, afinal pra gerente eu nunca tive o "perfil". 

Me especializei de um tanto que ainda hoje consigo lembrar de trechos do código dos programas OFOVPIN (que um dia achei que iria reescreve-lo), das chamadas com start de transacao com reqid para derrubar e seguir depois de 1 segundo (será que o CICS já baixou esse tempo, preciso estudar isso) se nao tivemos resposta, do OFOVCTL e a trilha 2 compactada que era um parto pra abrir e processar o CVV da trilha, do OFOMCTL... e seu clone limpinho que fizemos pra processar Amex OFOACTL e depois pra processar elo, o OFOECTL, muito criativos nós eramos para os nomes! Lembro de campos nos books FMLxx, das telas do OFCJ, de mapas BMS feitos para parecer identicos a um mapa feito no natural, dos experimentos com programas em C que quse ninguem usava, do book GRMKFAS, muito firmeza pra ajudar nosso trabalho com novos programas e log automatico de erros ou mesmo as subrotinas que pediamos pra equipe do Nakanishi desenvolver pra gente. 

Creio que hoje no Brasil não existam nem 30 profissionais que detenham conhecimento similar ao meu no Vision Plus que sejam especializados no FAS, mas isso não significa nada, para a empresa, como já disse, voce é apenas um número mais nada.

A perda do Naffer foi um grande baque, era um profissional fantastico, muito do que aprendi veio dele, sem falar que ele sempre me acompanhava nas madrugadas de implantações. 

Figura 4 - Tinha dia que a gente trabalhava bastante mesmo!

O Vinicius nasceu, falei que meu ritmo iria diminuir, logo depois o Perez aposentou e com ele a vaga de Analista Master / Consultor foi junto, fui perdendo um pouco do entusiasmo, do tesão pela coisa, perdendo a garra, continuava dando treinamentos, ensinando o que eu sabia pro colegas, conheci praticamente a Ditec toda com essa historia de multiplicador, isso eu ainda gostava de fazer, nao tinha mais a cenoura lá na frente pra ir buscar e isso me incomodava, estava prestes a ter mais uma daquelas reviravoltas na vida!...  

Aparece na agencia de noticias processo seletivo pra trabalhar na tecnologia em Sáo Paulo, eu já tinha pedido ao longo dos anos pra voltar pra sampa, mas a galera sempre me ajudando com a cenoura la na frente e fomos ficando, já tinha ido pra Sao Paulo algumas vezes pra ensinar Cobol Cics com Container pro pessoal e pensado que um dia poderia ir trabalhar lá..,agora nao ia ter mais jeito, a Ju nunca gostou mesmo de Brasilia, meu tesão tinha diminuido um montão, me inscrevi pra seleção, mesmo cargo que eu tinha mas pra trampar em sampa, fiz o processo, passei, em Dezembro estavamos de volta a Campinas e em Janeiro comecei uma das fases que mais me fodi na vida...

O trampo era de boas, pessoas sensacionais, sem muitos desafios, sem plantao, sem trabalhar de madrugada, sem a Dicar ligando pra analisar alguma coisa urgente, sem treinamentos nas bandeiras, mas com uma pegada diferente, acharam que eu tinha pinta pra educador corporativo, era tipo um premio de consolação por nao ter sido promovido la em Brasilia e quando eu desse treinamentos minha remuneração seria compativel com a do cargo de consultor... no ano que passei em São Paulo aprimorei os treinamentos que eu dava, fiz inumeros treinamentos e virei o tal do Educador Corporativo, apice 2 da carreira, daria pra ficar lá até aposentar, fazia o trampo direitinho, chegava no horario, o pessoal foi bem acolhedor, mas o estilo era outro, nunca fui num happy hour com a equipe de São Paulo, num churrasco, o pessoal era colega de trabalho, não amigo, igual os que fiz na época da agencia e lá na Ditec, estava complicado minha cabeça, nao ficava o tempo que eu queria ficar com o Vinny, o tempo perdido no fretado e no Cometa me tiravam do sério, não aguentei o tranco, achei que ia ser tranquilo morar em campinas e trabalhar em sao paulo, mas nao dei conta não, depois de um ano, fiquei tristão, deprimi e vi que precisava de um tempo. O Paulo Vaz entendeu completamente meu pedido de afastamento do banco e um ano depois da minha chegada estava eu de licença interesse nao remunerada do Banco do Brasil.

Tentei voltar algumas vezes desde que sai, mas nunca deu certo.... Em Janeiro de 2020, ao inves de eu tentar voltar, o banco resolveu que eu voltaria, mas não pra trabalhar com tecnologia, onde passei 10 anos e conheço o oficio e que aprimorei bastante os conhecimentos nos ultimos anos... era para trabalhar de escritutario em uma agencia em São Paulo, como já disse nunca tive uma carreira, fui na onda, mas voltar pra estaca zero depois de 20 anos nao ia dar, se fosse aqui por Campinas talvez tivesse voltado, afinal pra ganhar 4 conto por mes fazendo uns apertos até que daria, mas pra sampa e eu lembrava bem do tempo que fiz a loucura de ir e voltar todo dia sem chance.

Na maioria do tempo que fiquei no banco me diverti a beça, aprendi muito mesmo, conheci pessoas fantasticas, tive alguns dessabores, mas não acho que minha "carreira" deveria terminar assim.

Figura 5 - Crachas do Buga no BB

E-mail que enviei depois que tentei conversar com alguem de gestao de pessoas, tentando alguma alternativas, mas foi em vão, afinal era eu, apenas um numero, mais nada.

Minha história no BB não deveria terminar assim...

Saudações,

Meu nome é Buga e escrevo esse e-mail com lágrimas nos olhos.

Entrei no BB em 2001 e estou em licença interesse desde 2015. Certa vez fiquei desempregado e tentei retornar ao BB. Conseguimos o "de acordo" das pessoas necessárias, mas infelizmente ocorreram mudanças no banco e não foi possível.

Eis que de repente recebo uma convocação para voltar. Infelizmente nas condições propostas não será possível: morar em outra cidade, começar tudo de novo, jogar fora toda minha experiência adquirida em TI tanto no BB como "no mercado", sem mencionar que as contas não fechariam e a minha família seria resistente a mais uma mudança.

Sou grato pelos anos que passei no BB e espero que as políticas e normativos sejam revistos para que a empresa não perca outros funcionários que investiram tanto na formação e que conhecem alguns sistemas, produtos e serviços como poucos.

Não pretendia escrever sobre minha história no Banco do Brasil ou depois dele, mas já escutei que minha saída do Banco é uma situação em que todos perdem, e no fundo eu acredito que isso seja verdade.

Desde que fui para a DITEC em 2006 sempre trabalhei no autorizador do cartão de crédito (cujo uso crescia rapidamente), sistema fascinante! Trabalhávamos muito, mas éramos a cara do BB para cliente. Perdi a conta das madrugadas, finais de semana, feriados e datas comemorativas que ficavamos tensos trabalhando para que tudo desse certo. Participei de projetos grandiosos e sempre me realizei quando via o resultado final!... Saudades do pessoal e por vezes, por que não, do proprio sistema, seja ele o GRM, o VisionPlus ou mesmo o PPG.

Ainda sobre minha formação: o TAO ainda deve existir e uma das poucas coisas que deve ter mudado no meu "curriculo" é que deixei de ser educador corporativo (adorei o treinamento, um dos mais intensos que já participei) provavelmente a regra/normativo não deve ter mudado e como não atuei ensinando mais ninguém a desenvolver em Cobol no BB nos ultimos 2 anos, precisaria de reciclagem.

Nos anos fora do BB não parei de estudar. Fiz uma pós graduação em desenvolvimento de sistemas mainframe com o pessoal do extinto HSBC lá de Curitiba, e uma dúzia (sem exagero) de certificações em TI das mais variadas (meu curriculo vai em anexo) desde especificação de requisitos - que esta fora de moda com as Metodologias Ágeis - passando por certificação Scrum, Lean, de testes e até uma aventura pelo mundo da nuvem que me deu o titulo de "Google certified Professional Cloud Architect" o qual para alguém que sempre trabalhou e se especializou em mainframes me dá orgulho.

Como o Mainframe não podia ser deixado de lado no meu período fora do BB tive duas passagens pela IBM, aprendi bastante coisa nova sobre mainframes, aproveitei e me certifiquei como desenvolvedor CICS e DB2 além de umas 2 dúzias de badges de treinamentos diversos (sem exagero 2).

Em relação ao trabalho fora, além da IBM que já citei, trabalhei na Stefanini como consultor mainframe na fábrica de software, onde dava treinamentos para estagiários que estavam adentrando o mundo do mainframe.... Tive também uma experiência magnifica de transformação digital junto a CI&T que tinha como mote ensinar outras empresas a trabalhar com as metodologias ágeis.

Obrigado pelo tempo e atenção dispensada, espero de verdade que em algum momento nos processos do Banco deixemos de ser apenas uma "matrícula inativa" e que tenhamos nossa historia levada em consideração.

Não era de minha intenção a saída definitiva do banco nesse momento e foi muito desagradável receber um e-mail dizendo simplesmente que eu "posso pedir minha demissão na minha agência de relacionamento."

Me afastei do BB na época por motivos familiares de adaptação e não por não gostar do meu trabalho. Gostaria sinceramente que esse tipo de resposta que recebi dos contatos que tive com o pessoal da DIPES/GEPES não fossem enviadas para mais ninguém...

Fui,
Buga

terça-feira, 18 de agosto de 2020

Certificação - Kanban Foundation (KIKF) - Kanban Institute

Certificação Kanban Certiprof – Relato e Materiais

Não foi difícil, uma prova média, mas o material de estudo não é completo e não abrange todas as perguntas da prova. Fiz pela Certiprof na faixa, talvez só com o material não dê pra passar de primeira.

Materiais de estudo

Manual Kanban do Scrum.org:

Baixar Manual Kanban do Scrum.org (PDF)

Slides Treinamento CertProfi:

Baixar Slides Treinamento CertProfi (PDF)

Certificado Buga - Kanban

Figura 1 - Certificado KIKF - Buga

sexta-feira, 7 de agosto de 2020

Manual do proprietário Rossi - Condominio Casas de Gaia, Barão Geraldo, Campinas - SP

Desenho capa manual proprietario Casas de Gaia
Figura 1: Capa Manual Proprietario Casas de Gaia

Download do conteudo do DVD do proprietário

Manual do Proprietário – Casas de Gaia (Rossi e GNO)

Este post traz um resumo do Manual do Proprietário do condomínio Casas de Gaia, entregue pela Rossi e GNO. O manual é essencial para quem acabou de receber as chaves ou deseja entender melhor os cuidados, garantias e manutenção do imóvel.

Introdução

O manual orienta sobre o uso, conservação e manutenção do imóvel, direitos e deveres do proprietário, procedimentos em caso de reformas, e como garantir a durabilidade e segurança da unidade. A responsabilidade pela manutenção começa no momento do recebimento das chaves.

Principais Tópicos do Manual

  • Alvenaria Estrutural: Não remova ou altere paredes estruturais, nem faça rasgos para embutir tubulações. Qualquer modificação pode comprometer a estabilidade e resultar em perda de garantia.
  • Cobertura – Telhado: Telhas cerâmicas do tipo americana. Recomenda-se inspeção frequente para evitar infiltrações e garantir a conservação do telhado.
  • Esquadrias de Madeira e Alumínio: Dicas de limpeza, manutenção e cuidados para evitar danos e perda de garantia.
  • Vidros: Limpeza com água e sabão neutro. Evite impactos, produtos abrasivos e marcas superficiais.
  • Impermeabilização: Atenção especial em áreas molhadas. Evite perfurações em pisos e paredes impermeabilizadas.
  • Revestimentos: Cuidados com cerâmicas, mármores, granitos, forros de gesso e pintura. Use produtos adequados para limpeza e manutenção.
  • Instalações Hidráulicas e Gás: Rede de água fria/quente, esgoto, gás GLP. Recomenda-se inspeção periódica, uso de registros e cuidados para evitar entupimentos e vazamentos.
  • Instalações Elétricas: Quadro de distribuição, disjuntores, tomadas, circuitos e dicas de segurança. Não troque disjuntores por outros de maior amperagem.
  • Equipamentos de Combate a Incêndio: Extintores instalados conforme normas. Siga as instruções e mantenha os equipamentos nos locais determinados.
  • Situações Especiais: Procedimentos em caso de incêndio, vazamentos de gás e água, e modificações no imóvel.
  • Garantias: Relação de prazos de garantia para cada item (esquadrias, instalações, revestimentos, estrutura, etc). A garantia pode ser perdida por mau uso, reformas não autorizadas ou falta de manutenção preventiva.
  • Fornecedores e Prestadores de Serviços: Lista de empresas responsáveis por projetos, execução e materiais utilizados na obra.
  • Memorial Descritivo: Detalhamento dos materiais, acabamentos, pisos, revestimentos, louças, metais, portas e esquadrias de cada ambiente do imóvel.
  • Anexos Técnicos e Plantas: Desenhos, esquemas hidráulicos, elétricos e instruções para fixação de objetos em paredes de drywall.

Dicas Práticas do Manual

  • Leia atentamente o manual e mantenha-o à mão para consultas futuras.
  • Respeite os prazos e recomendações de manutenção preventiva para não perder a garantia.
  • Consulte sempre profissionais qualificados antes de realizar reformas ou instalações.
  • Em caso de dúvidas ou problemas cobertos por garantia, acione o SAC da construtora.
  • Repasse o manual ao novo proprietário ou inquilino em caso de venda ou locação.

Links úteis