Dois anos atrás comecei num emprego novo, mas esse texto nao é sobre isso!

Meu primeiro emprego e trajetória no Banco do Brasil

Meu primeiro emprego e acho que deva ser o mais duradouro da minha vida foi no Banco do Brasil.

Até 2005 eu trabalhei em agências bancarias majoritariamente como caixa, atuando na retaguarda do atendimento, quase nunca atendia clientes, trabalho rotineiro, repetitivo, operacional puro, sem grandes variações das tarefas, eu adorava! Meu horario de trabalho foi diferenciado por muito tempo, conseguia fazer a faculdade de manha, trabalhava a tarde e de noite voltava pra faculdade. Teve um ano que deu ruim esse esquema porque teve apagão de energia eletrica e resolveram que os bancos iam abrir as 9 da manha, ai dancei, nao teve jeito, a agencia ia fechar as 5 e eu tinha que entrar no máximo as 11, deixei de fazer algumas matérias que estavam no gatilho naqueles 2 semestres. Tirando esse periodo do apagão, no geral foi esse o esquema durante a faculdade.

Eu morava com o Boy desde que entramos na faculdade em 98, mas a gente colava direto no ap do Poin, do Guidi e do Matheus porque lá ficava o video cassete, o computador e posteriormente o DVD que lembro como se fosse ontem o dia que fomos comprar ele no Carrefour da Dom Pedro, paguei com carnê! Grana sempre foi bem regrada, minha mae ajudava com o aluguel e o condominio (eu acho, nem lembro mais direito, ela pagava direto pra mae do Boy), seu Irá longe disso, desde que me lembro por gente finanças nunca foi o forte dele, depois de velho uma vez conversando com ele, ele acha que nunca na vida gastou menos do que ganhava, seu Irá aparecia de vez em quando sempre pedindo uns cheques pra rolar alguma divida e pra eu comprar um carrinho financiado no meu nome pra ele, que ele ia pagar e tals, igual os cheques que nao iam voltar, mas enfim eu ficaquei fugindo do oficial de justiça por algum tempo... sapeca queria tomar de volta pro banco só porque seila pagou só as 3 primeiras parcelas, esse aqui deu pano pra manga e no final das contas minha mae que me salvou dessa, tipo acordo com advogado e tudo certo, foi por pouco que nao me mandaram embora do banco nessa época, afinal de contas era justa causa funcionario com descontrole de financas com cheque devolvido, nome no CCF, SPC, Serasa, dureza, bom que nessa época era tanta coisa acontecendo junto que nem dava muito tempo pra pensar na zona que ficou minha vida financeira por alguns anos.

Sei que em 2002-2003 a gente mudou de apartamento e foi morar junto com o Tadashi e o Marcelo ali no Primavera, nessa época minha mãe parou de ajudar com as contas. Mas tenho que deixar registrado que ela sempre falou pra eu largar o banco e fazer estagio, depois pra fazer trainee, de largar por largar e tentar trabalhar com outra coisa, mas nunca deu certo, sempre que tava nos finalmentes rolava um, veja bem... coisas da vida.... Em janeiro de 2004 fui morar com a Ju, voltando pros estudos....eu me formei em Engenharia Química aqui na Unicamp no meio do ano, não posso afirmar que nunca trabalhei na área, afinal de contas fiz estagio na ACME, montamos uma fabrica de rodinhas de skate do zero, compramos uma de shapes... então um pouco de experiência posso dizer que tive, mas foi bem pouco.

Bom, a vida era bem corrida nessa época, lembro que eu estava tocando a fabrica, fazendo MBA, ingles, mestrado e graduação tudo junto, o ano era 2005.

O emprego no banco sempre me pagou o suficiente pra eu nao conseguir sair dele!

Quando fui atrás de estágio bateu o desespero, sem estagio nao me formava e com estagio as contas nao fechariam.... A solução foi arrumar um bem bolado nas ferias e finais de semana, pro bono, com objetivo claro de estagiar as horas necessarias para cumprir os requisitos da faculdade, o estágio foi bem da hora, aprendi um mundo novo, o mundo do poliuretano e devo dizer foi nele que tive a ideia pra montar a fabrica de rodinhas pouco tempo depois.

Os programas de trainee eram bem interessantes, mas sou totalmente avesso a processos seletivos, tenho sérias limitações, lembro de ficar extremamente ansioso, tinha tremores, falta de ar, as mãos suavam, gaguejava, era um show de horror pra mim, simplesmente nao consigo participar de dinamicas de grupo e todo o teatro envolvido, lembro de ter comentado isso no discurso da formatura. Cheguei a ir embora no meio de uma dinamica de grupo que um ser ia ser o tubarao e os outros nadariam no chao fugindo dele...Enfim, cheguei a participar de alguns processo de trainee, mas em virtude do exposto acima, dificilmente passaria, e mesmo se tivesse dado bom, talvez nao desse pra encarar 'largar o banco', o salario no banco e o do trainee, com rarissimas exceçoes eram iguais, sem falar que a fábrica ja estava rodando e um trabalho em tempo integral ia complicar bastante o fino ajuste das engrenagens da minha vida.

Quando fui fazer mestrado ai foi desesperador, a bolsa era algo em torno de 1/5 do meu salario, abdiquei da bolsa e continuei trabalhando no banco, resignado.

Ai no final de 2005 uma reviravolta.

Eu tinha feito um processo seletivo, viajei até curitiba pra participar (aproveitei e visitei o Jean na ocasiao), pra ir trabalhar com computação, la em Brasilia na diretoria de tecnologia, nesse processo era tipo pra habilitar a gente pra poder ir, se tivesse vaga e quando tivesse chamariam a gente, nao demorou nem 1 ano, a Paula ligou falando que eu ia e fiquei tao pasmo que sequer peguei os dados dela pra retornar com duvidas e tals, foi só aguardar e um dia chegou a convocação.

A Ju ainda tava fazendo residencia, eu tava fazendo a graduacao em quimica, o mestrado em degradação de polimeros, o MBA na FGV de executivo em financas pelo banco e a fabrica quase engrenando, tudo indicava que eu continuaria estudando, tocando a fabrica e esperando um dia poder 'largar' o banco e ficar só com a fabrica ou mesmo virar professor, seila, nao tinha um plano, tava seguindo na inercia do que foi acontecendo.

Resumindo objetivamente o que aconteceu, a Ju descolou uma republica pra eu morar lá no Cruzeiro até ela terminar a residencia e ir pra la morar junto comigo. Me mudei com o Uninho abarrufado de coisas, a Ju foi meses depois com a mudança de caminhao que acabamos deixando num guarda moveis, que me protestou uns boletos na louca e quase me fez perder o trampo, mas assim que descobri os caras resolveram. Voltando, compramos um AP sem ver, antes mesmo de ir pra Brasilia, só tinha umas fotos no site da cooperativa e vamos lá, vai dar, vendemos o Palio e demos a entrada. Era pra entregar seila em maio mas atrasou coisa de um ano, um ano e meio, a Ju arrumou emprego em formosa, mudamos pra lá, de formosa pra brasilia era coisa de 70km, demorava uma hora pra ir pro serviço e umas 2 pra voltar. Era bem corrido, mas tava valendo. As vezes eu ia de carro, poucas, na maioria das vezes era de onibus mesmo, que o banco até ressarcia, sabe-se la como mas pagava. tinha mototaxi por la, anos luz a frente do seu tempo, agora 2025 que ta bombando os uber moto e o 99 moto.

Bom, ai nesse meio do caminho acabei deixando mao da quimica, da fabrica, de virar professor, da engenharia e acabei virando domador de dinossauros, quer dizer, eu virei um programador Cobol!... Trabalho esse que me acompanhou por mais de uma década, até que fui trabalhar no Original e nunca mais programei nada e virei meio que um analista de negocios, funcional, seila que raio de nome que tinha, o que eu fazia era deixar o sistema de compras e saques com cartao funcionando!

E foi isso ai.

Mudar sem sair do lugar, nunca fui de usar as asas, sou mais de aprofundar a raiz.

Lá nos idos de 1997 eu resolvi que estudaria na faculdade química, queria mesmo, eu acho, era fazer química, trabalhar em laboratório, fazer experimentos... mas não rolou, lembro claramente de minha mãe se opondo a eu estudar química, onde já se viu?! Trabalhar em laboratório ou numa fábrica e morrer de câncer ou na melhor das hipóteses virar professor! Jamais segundo ela! Meu pai não dá pitacos, muito menos nessa área, tanto que não se opôs quando meu irmão quis fazer faculdade de games alguns anos mais tarde e games nem era nada perto do que é hoje, teria dado muito certo, mas a mamãe dele, assim como a minha, também vetou.

Bom, voltando, como não deu pra eu estudar química, vamos achar uma alternativa, fui de engenharia química, na inocência de que aprenderia um pouco de química e ainda teria o título de engenheiro pra deixar minha mamãe orgulhosa, de ter um engenheiro na família!

Eu não sabia direito o que um engenheiro químico fazia, hoje 30 anos depois meio que continuo sem saber, na real, acho que ninguém sabe ao certo.

Vestibular e escolhas

Mas lá fui eu, o Enem não existia, a gente tinha que fazer um montão de vestibular, era bem exaustivo, mas eu gostava, no segundo ano, já tinha feito prova de treineiro na Fuvest e na Unicamp e tinha ido bem, fiz uns 6 meses de cursinho no Etapa lá da Ana Rosa num horário bem nada a ver, mas que casou certinho com minhas necessidades, era tipo das 4 às 9, o colégio era 'integral full' no terceiro ano, das 7 às 3 então dava certinho pra eu pegar o metrô no Belém e ir. Chegava em casa moído e no dia seguinte bora pra rotina de novo. Ah, de sábado tinha aula extra pra quem ia prestar ITA, grande decepção, na primeira prova tirei 4,8 e já estava eliminado, mas não tinha como saber e fiz tudo os outros dias de prova. Mas a publicação não era pra ser sobre vestibular, e sim sobre o mudar.

Bom, saíram os resultados na USP, não lembro direito como que funcionava a escolha das engenharias na Fuvest, mas sei que passei pra fazer engenharia civil, antes disso eu tinha me matriculado em Lorena, eu não, minha mãe fez essa pra mim, nem lembro como, mas ela foi lá e me matriculou, mas como era longe e acabei tropeçando na USP, bora de engenharia civil mesmo, aí um mês depois nem isso saiu a primeira lista da Unicamp e tava lá de engenharia química, bom, fui! Agradecimentos aqui pra Camilla Passarella Lazzarato, que estudava comigo no Agostiniano e também passou na Unicamp pra fazer Engenharia de Alimentos, mãe dela excepcional, ser humano diferenciado, me tratou super bem, me deu suporte num dia que foi bem doido mesmo, enfim, a Camilla encontrei com ela algumas vezes na faculdade, depois nem notícias, acho que tá nos EUA casada e com filho, vivendo o American Dream. Na parte da USP agradecimento ao Vinicius Kasabkojian, camarada do inglês que me deu carona nas 3 semanas que estive por lá, idem a Camilla, sem notícias há décadas.

Bom, post pausado no desenvolvimento porque fui pesquisar sobre os agradecidos e não são usuários ativos de redes sociais, então não deu pra atualizar, mas mandei umas mensagens que, quase certo, não serão respondidas.

Engenharia Química e tentativas na Química

Voltando ao cerne, acabei que cursei Engenharia Química na Unicamp, turma de 1998, me formei no longínquo agosto de 2004. Rolou uma vez só um encontro grande dos colegas, acho uma pena não ter encontros habituais, galera era gente fina, tem uns que ainda vejo, mas não na frequência que eu queria, vida de adulto é complicada.

Nesse mesmo ano, fiz prova pra ingressar no mestrado da química e também fiz vestibular pra cursar química, afinal continuava com vontade de ser químico.

Resumo, em 2005 tava eu fazendo matérias do mestrado e da graduação (essa com um mega hiper bug na Matrix, que eu tava na sala da irmã do Boy), o projeto do mestrado era bem bom, tipo de fotodegradação polimérica, tava muito incipiente ainda, mas hoje são as sacolinhas de mercado que desmancham em menos de mês.

Reviravoltas profissionais

Em 2006 a vida deu uma reviravolta, em 2005 apareceu uma 'publicação' na 'agenda de notícias' do trampo que estavam precisando de gente pra trabalhar lá em Brasília com computação e que ia abrir um processo seletivo, li as regras tudo e em nenhum lugar falava que precisava ser formado em computação ou algo assim, enfim, fiz o processo, em Curitiba, aproveitei e visitei o Jean, creio que foi a última vez que o vi, tentei achar aqui ele nas redes, mas nem isso, galera com nome 'normal' não dá pra achar, cidadezinha gostosa lá viu, São Bento do Sul. Foi o dia todo de entrevistas, eu e mais 5, passaram eu e um outro figura só, Japonesa do demônio, deixou claro que não era pra eu ir, mas os outros 2 gerentes apostaram as fichas em mim, não decepcionei! Ah, dos que não passaram, o Everisto apareceu lá na Ditec uns anos depois e acabou voltando pra casa um pouco antes de mim.

Conversei com o De Paoli, meu orientador do mestrado pra ver se conseguia continuar o mestrado lá por Brasília, não rolou e lá na UNB não achei, na verdade nem fui atrás direito, mas o mestrado ficou pra depois... a graduação em química não dava pra transferir, então fui fazer vestibular, não passei, é aquelas prova do demônio do CESPE de uma errada anula uma certa, eu com 26 anos não tinha como não chutar, resultado, minha nota não valeu nem pra lerem a redação, desencanei da química.

BB, mainframe e novas formações

No BB passei por um 'curso de formação' para aprender a trabalhar com o desconhecido COBOL e o incrível mainframe, nem quem tinha feito curso de computador na faculdade saberia trabalhar sem ter feito o treinamento, fui alocado pra trabalhar no autorizador de cartão e o resto é história.

Acho que em 2011, não lembro ao certo e não vejo necessidade de pesquisar pra ser certeiro, o Michel que tava fazendo alguma outra graduação lá na UNB, acho que a primeira dele era computação e ele tava fazendo administração, acho que era isso sim, fui até na formatura dele, carinha gente fina, curtia bastante ele, falo com ele bem menos do que deveria, virou bolsonarista de carteirinha! Nem deve ter tomado vacina do Covid... deixa eu perguntar, perguntei!

Complementando, teve vestibular de vagas remanescentes pra quem tivesse diploma de ensino superior, fui lá e fiz, gostei bastante da prova, fazia uns bons anos que eu não fazia nenhuma, era escrita, teve até um exercício com integral e eu acertei! Tava enferrujado, mas deu bom. Em 2012 retomei meu projeto de me formar em química, a Ju tava junto em todas essas doideiras, lembro da gente indo fazer a matrícula com o Vinny no colo!

Primeiro semestre foi bem diferente, como eu já tinha um zilhão das matérias básicas de exatas já cursadas, fui só de humanas... pedi equivalência, nessa o Tadashi ajudou lá de Campinas em pedir pra Unicamp as ementas e meu histórico completo que precisavam na UNB impressos! É, os tempos eram cruéis e difíceis, burocracia ainda era em papel... agradecimento aqui ao japonês também, nessa época ele ainda não tinha formado, faltava um nadica, mas ainda não tava formado.

O segundo semestre foi igual ao primeiro porque não tinham finalizado o processo de equivalência, lembro até de ter reclamado na ouvidoria da faculdade e mesmo assim nada, só saiu as equivalências no terceiro semestre, mas aí já era tarde, no final de 2013 retornamos pra 'casa'.

Novas tentativas e pandemia

Em 2016, já licenciado do BB, resolvi fazer faculdade de TI, afinal de contas já havia uma década que eu trabalhava com computação e não tinha um certificado/diploma que fosse, minto, tinha um de mainframe da IBM que fiz lá em Brasília quase que junto do Bulats de inglês. Como diz minha sogra, nada melhor pro Buga voltar a fazer faculdade do que o nascimento de um filho!

Lá fui eu fazer "Gestão da Tecnologia da Informação" na Fatec ali do lado do cemitério.... Curso interessante, curti, outro bug na Matrix, tava na mesma sala da menina que, esqueci o nome, mas já já eu lembro, anos mais tarde tava lá numa sala de reuniões do Itaú. Bom, comecei a ter que ir pra Sampa pra trabalhar no Itaú, a faculdade ficou pra depois. No final de 2018, resolvi que ia terminar química, fiz o vestibular na Unicamp e tô lá matriculado em 2019, em licenciatura em química. Nesse meio tempo aí teve uma prova da Unicamp de vagas remanescente mas não passei na segunda fase de provas específicas, tinha uma prova de fim de curso de física 3, quase entreguei em branco, triste, não passei... bom, tá lá eu felizão, fazendo matérias de humanas, Vinny andando de patinete da Yellow na Unicamp, tudo indo bem, dessa vez eu formo, que nada! Bora trabalhar em Sampa de novo, agora fixo e até quando eu aguentar, isso era junho de 2019, fiz só 1 semestre de química nesse meu retorno, falta tão pouco... um dia, um dia termino! Na real eu mandei mal, porque se tivesse ido atrás, quer dizer, deixa pra lá, o "pé de se" não faz parte do universo que vos escrevo.

Bom, aí veio a pandemia e no final de sei lá que ano, fiz a prova da Petrobras de engenharia química, deve ter uma meia dúzia a dúzia cheia de contemporâneos da Unicamp que estão por lá, da minha turma são especificamente 4, que pedi ajuda antes de entrar pra ver se dava pra ter uma certeza que eu viria aqui pra refinaria de Paulínia, mas descobri depois que não tem como ter ideia de como funciona a firma, é muito engessada, bem mais que o BB, mas fui lá eu, fiz a prova e vishi, deixa pra lá que não deu, não estudei, conferi o gabarito e deu metade da prova mais um pouquinho, foi legal ter feito, mas passar no concurso não ia rolar.

Retorno à engenharia e raízes

Aí em novembro de 2022 chega um e-mail e 3 dias depois um telegrama me convocando pra assumir a vaga do concurso, não entendi nada, foi uma decisão daquelas, mas que tinha que ser tomada e caiu na hora certa, sendo que hora certa é qualquer hora, sempre! Natalia, a mina da faculdade e do Itaú chama Natalia, da época do Itaú acho que só tenho contato com o Jheimes que encontro esporadicamente sem combinar umas 2 vezes por aí e a galera da Stefanini, a grande maioria nem notícias tenho mais.

Bom, lá fui eu trabalhar com engenharia química 20 anos depois de formado, assim como no BB quando cheguei em Brasília, na Petrobras também teve curso de formação pra aprender a trabalhar, fiquei morando no Rio de Janeiro quase 1 ano e sem saber qual seria meu futuro, só sabia que se não viesse trabalhar aqui em Paulínia não ia ter jeito de trabalhar na Petrobras, aí no meio pro final do curso, lançaram um projeto piloto pra trabalho remoto integral, li as regras e tava tudo ok pra eu pedir, assim que terminou o curso eu ingressei no trabalho e em janeiro de 2024 eu já estava 'de volta' pra casa.

Hoje, fevereiro 2025, não sei se vou um dia terminar a química, não tem muito porque, dificilmente trabalharei com química, e muito menos serei professor, então vida que segue, tem umas coisas que a gente quer que nem sabe direito o porque.

É isso, tô de volta pra casa.

Retrospectiva 2024

Família

- Tretas de sempre com a mamãe Eliana, tão menos frequentes e de menor tensão, mas invariavelmente ocorrem. Teve uma vez que fui lá pra casa dela e nem consegui entrar, coloquei uma gaiola na escada e fui pegar as outras mas não deu, fui embora, afinal como que pode eu ter ido pra lá sem levar as crianças junto comigo?

- Vovó Cristina desde que voltei do Rio ficou bem afastada, de setembro/outubro pra frente passou a ficar mais próxima das crianças, quer dizer, da Helena. Estamos nos virando bem sem ela dando aquele auxílio no dia a dia, na rotina da família, tá mais de vó mesmo.

- Família do Ipiranga ficou meio longe esse ano, nos falamos esporadicamente e nos vemos nos aniversários das crianças e na festa junina da escola.

- Tia Stephanie veio pra cá algumas vezes, as crianças se divertem, mas não tem aquele vínculo gostoso de tio, mais ou menos igual o tio Dante.

- Ribeiro vem mais ou menos uma vez por mês aqui em casa pra colocar a conversa em dia, ver as crianças e tomar um café.

- Ju ficou mais de boa esse ano, mesmo estando em transformação e sem saber direito o que fazer comigo depois que pegamos meu laudo de deficiente mental.

- Vinny tá osso, começa a não respeitar, não ajuda, fica xuxando a Helena sem parar, tomara que seja algo transitório, tá precisando fazer mais amizades. Fizemos o foguete de ar comprimido e a base, foi um belo trabalho, pena que a galera trambica no resultado da competição. Esse ano no Sirius foi legal, mas tava um clima chuvoso que atrapalhou um tanto, Vinny deu entrevista, mas nunca achei se publicaram. Fez umas olimpíadas de conhecimentos e curtiu bastante!

- Helena tá de boas, fez bastante amizade no prédio e na turma da escola. Passa pano pra quase todo mundo e às vezes que tá fazendo birra ou chorando consegue responder que não consegue parar e às vezes nem sabe o motivo direito.

Saúde

- Depressão das brabas

- Engordei 15 kilos

- Peguei pressão alta, descobri indo doar sangue e não podendo.

- Bronquite atacou feio em dezembro, teve uma outra vez ou duas que fui parar no centro médico pra medicarem.

- Diabetes controlada com o remédio faz uns anos já.

- Operei de uma hérnia na pança que apareceu 'do nada', só porque dei uma engordadinha básica. Operei também do nariz e arranquei uma bolota de banha que eu tinha nas costas.

Preciso me cuidar! Zero exercícios.

Trampo

- Sou Engenheiro de Processamento de Petróleo Junior, meio desanimado, aprendendo o ofício em passos de bebê, falta um tutor, um acompanhamento, não sirvo pra me virar sozinho, sem falar que nunca trabalhei na área... fácil não tá, mas tô de teletrabalho integral, o salário não é lá essas coisas mas tá valendo! Fiz zero novos amigos no serviço esse ano.

- De minha vida pregressa só saudades de trabalhar com algo que eu dominava e me instigava saber mais sobre o assunto, zona de conforto me faz um bem danado e não tenho mais isso.

Dinheiro

- Tem suas loucuras que acontecem, compramos o apartamento 11 pra ficar do ladinho da escola e aumentou um 'tiquito' os gastos mensais da família com 2 casas na mesma cidade. Não que a gente não tenha "2 casas" desde sei lá 2019, só que era diferente, tinha desculpa de ser gasto do serviço e tals, agora é tudo na rubrica de gasto gasto mesmo.

- Desinvestimento bruto na parca carteira de ações e demais investimentos, ano não bom pra renda variável, tipo estamos com metade do valor inicialmente comprado de papéis... e alguns deles nunca mais vão chegar sequer perto do valor que pagamos.

- Viagem de fim de ano deu uma boa assustada, quando compramos as passagens em janeiro, o dólar estava a 4,85 lá nos EUA no cartão de crédito chegou a 5,70 com IOF e a taxa que o banco coloca em cima da cotação.

Justiça

- Processo de correção dos FGTSs, nem sei se foi esse ano, mas foi pro vinagre, julgaram que do jeito que remuneram tá ok e azar, transitados em julgados, fim.

- Pagamento a maior dos INSSs, da Ju deu ok e receita devolveu os valores pagos a mais, o meu, processo igualzinho, cópia e cola, tá lá tramitando ainda, sem sentença proferida.

- Trabalhista Banco Original, duas vezes fui lá na Barra Funda e nada, juiz tava a fim de descolar um acordo, mas sem chances. Na primeira o Maicon e o Franco não conseguiram ir porque teve algum BO lá no BMG e eles estavam em Minas e na segunda a Aline perdeu a hora, ficou uma nova pra março de 2025.

- Trabalhista Banco do Brasil, execução da redução salarial, essa fiquei sabendo num churrasco de 20 anos de DITEC lá em Brasília na casa do Igor e entramos com a ação de execução no fim do ano, em andamento.

- Gol que me cancelou 4 passagens porque o sistema deles é estúpido e não soube lidar com a mudança dos aeroportos lá do Rio do Santos Dumont pro Galeão, nossa que ódio! Era muito de boas ali no Santos Dumont, bom, como agora vou esporadicamente tá valendo, mas não faz sentido o que fizeram, sem falar que a tal da barca pelo que li esses dias não saiu do mundo das ideias. Enfim, juiz já julgou que tá ok meu pedido, mas a Gol recorreu só por recorrer e tô no aguardo.

- Cobasi dos Hamsters procriadores, teve audiência mas nada de acordo, esperando os próximos passos.

Amigos

- Acho que não fiz nenhum amigo novo esse ano que passou, também depois da overdose de 2023 tá bom demais.

- Acabei que não vi quase ninguém, teve no final do ano casamento do Rodolpho que reencontrei o Bruno e o Botti, trombei bastante o Boy, o Tadashi, o Fred e o Marcelo... teve um encontro Porks no começo do ano aqui em casa, fui pra praia e vi o Flávio, no carnaval o Bruno e o Rodolpho passaram aqui em casa, o Luis Felipe passou um dia de noite e fizemos um churrasquinho, ah, e o Tonin passou aqui out of the blue só pra tirar uma selfie! Encontrei o Hyam Nicacio, que não via há mais de década, veio aqui em casa, noite muito agradável, depois ainda conseguimos tomar uma no bar do Coxinha com a Dessa que também fazia uns bons anos que não via, todos bem na medida do possível. Consegui almoçar com o Franco, Maicon, Rene e o Cesão depois da audiência lá em Sampa. Encontrei o Julio umas 3-4 vezes, acho que a mesma quantidade de vezes que devo ter visto o Cae no ano, troquei umas ideias com o Paraguay e o Bob, mas quase sempre coisas do trampo.... Dei uma passada no Christian em Jaguariúna, tava uma chuva daquelas, foi só protocolar, nem trocamos muita ideia, ah, teve um churrasquinho com a galera da Stefanini na chácara da Dani também lá em Jaguariúna, teve um Outback com o Caio o mano Rewth, Odair e Alex, fui pra Brasília no encontro da galera da DITEC, reencontrei muita gente mesmo, grandes memórias, mas no fundo, fiquei com aquele sentimento de não pertenço mais aqui, e olha que era um sentimento que senti bem poucas vezes na vida, a de pertencer a um grupo, ali em casa nos churrascos na varanda eu me sentia parte da turma, de verdade... bom, acho que foi isso.

Viagens

- Fomos pra Barra Bonita na Páscoa fazer uma trilha de jipe, traumático pras crianças e pra Ju, não vai rolar mais, mas foi interessante o rolê.

- Praia em Ilha Comprida no começo do ano.

- Disney em dezembro todo.

- Parcas idas a São Paulo.

- Encontro em Ribeirão dos dentistas.

- Ju viajou horrores a trabalho.

- Fui pro Rio umas 3 vezes esse ano só, depois do carnaval não fui mais, tô devendo.

- Brasília, sozinho pro encontro da Ditec.

Estudos

- Nada, nem um Duolingozinho, mas fiz o ENEM pra ver qualé que era!

Filmes, Livros, Shows, Peças Teatrais

- Nada digno de nota, ah minto, não gostei dos 100 Anos de Solidão, tipo escroto na parte sexual da história, precisava disso não, lembro de ter lido algo parecido na adolescência tipo Capitães da Areia, mas sei lá, meio forte, curti não. O filme do cara do Feliz Ano Velho é legal, verídico, mas não achei nada de mais, vale o mote... 'alguma coisa ele fez'.

- Show, acho que não vi nenhum esse ano, teatro acho que idem.

---

Se lembrar de mais caixinhas da vida eu coloco aqui.

Diario das Ferias de 2024 - 06.12.2024 - Dia 6 - Viernes

Viagem para Orlando: aeroporto, voo e primeiras impressões

Deixei a família no aeroporto e fui pro estacionamento deixar o jipe.

Pequeno probleminha com a escolha do assento, seila o que que deu que o sistema resolveu mudar os assentos de uma das reservas, fizemos em duas, mas deu tudo certo.

Voo tranquilão, fui ver de conhecer o lounge azul, mas era só pra eu e 1 acompanhante ou pagava 300 cruzeiros pra entrar todo mundo, não foi dessa vez.

Lembrei de um amigo do trampo e como de costume, se lembro, entro em contato!

John mandou vídeo dele fazendo peripécias com caneta, vi ontem e hoje não abriu de jeito nenhum pra eu mostrar pro Vinny.

Li um tantão do livro lá dos Buendia em Macondo.

Aeroporto de Orlando fez terminal novo, desembarcamos nele. Imigração tranquila, pegar carro deu medo porque não ia caber as malas, mas aí apareceu uma devolução e cá estamos de Tucson.

Olha, não sei o que os americanos fizeram nos últimos 5 anos, mas não lembro os preços das coisas no valor que estao! Tipo subiu bem, coisa de inflamação mesmo. Sem falar na cotação histórica de 6 cruzeiros por uma verdinha.

Diario das Ferias de 2024 - 04.12.2024 - Dia 5 - Jueves

Diário de um dia: escola, festa, preparativos e viagem

Vinny resolveu que não ia na escola, Helena foi cheia de cartões de fim de ano prós amigos.

Últimos preparativos pra viagem.

Insônia braba meu amigo!

Deixei a Wendy na Priscila e comprei um pacote de ração a mais pra garantir, afinal não faço ideia quanto ela come num mês.

A tarde Helena teve festinha no japonês, lá no m5fun, era do Vitor, e eram 3 horas de festa, algo novo no cenário de festas infantis, ainda mais em se tratando de uma quinta feira, ainda bem que a moça da recepção avisou que era pra pegar as 4 porque se fosse esperar eu ler/interpretar corretamente o convite não ia rolar, tá no automático festinha de criança das 13 as 17.

Jantamos no shopping, fomos pegar os livros das crianças pro ano que vem.

Escola muito doida, Vinny tá indo pra oitava série, com 13 anos e vai ler o Fahrenheit 451.

Malas fechadas e bora pra viagem!

Diario das Ferias de 2024 - 03.12.2024 - Dia 4 - Martes

Dia chuvoso, rotina em família e preparativos para viagem

Chovendo desde a madrugada, levei as crianças pra escola de jipe, fiz almoço, fui pega-los de jipe porque tava chovendo, mas nao tinha vaga na rua, parei la em cima no infantil, fui com a wendy, acabou que demos uma passeadinha boa, enfim, almoçei com a Helena no Sandro, Vinny nao quis ai fiz um strogonoff. Achei o kindle, devo leva-lo na viagem. Arrumei as paradas pra entrar com o processo da Ju no GDF que o sindicato avisou a gente esses dias. Peguei pra ver a correcao do enem, mas nao achei nenhum que me interessou, tentei ver uns 3, mas nao curti o formato.
De tarde a Cris passou aqui e foi com as crianças no cinema ver Moana 2.
Ju chegou de noite ja tinha parado de chover. Ultimos preparativos pra ir ver o mickey. Dureza achar estacionamento com preço razoavel pra 30 dias ali pelo aeroporto.
Vi um montao de partoba, apresentado ao jornal da oeste e uma copia do pingo nos i's, nada de mais, porem deixam claro o posicionamento ideologico, interessante e raro.
Fiz uns hamburguers e nuggets pra janta das crianças e fiquei sonolento o dia todo, ta dureza a insonia.

Diario das Ferias de 2024 - 02.12.2024 - Dia 3 - Lunes

Diário de um dia comum: família, rotina e dólar alto

Ju foi pra São Paulo, demorou 4 fucking hours da hora que saiu de casa até chegar no CJ!

Fui na padaria comprei pao e bolo, Vinny nao foi de café da manha, eu e a Helena ficamos no pao.

Dei um talento nas impressoes do que tava faltando das paradas da viagem, sim, sou das antigas e curto o bom e velho papel!

Almoço foi operacional, fritei uns bifes e comemos com arroz.

A gente ia lavar o carro e caiu um pé d'agua daqueles, adiou um pouco a operacao, mas saiu, familia toda ajudando, até a Wendy resolveu ajudar na integração da familia dando uma fugida basica pelo portao do lado que ficara esquecido aberto em alguma ida e vinda pra pegar itens pra limpeza do jipe.

Ficou limpissimo!

Conversei rapidinho com a Fe Passos que eu tava precisando falar com ela fazia uns dias já, dureza ser boi de piranha, bode expiatorio e qualquer outra alcunha, sei bem o que ela esta passando, mas não consigo nem sei como ajudar. 

Helena pediu pra fazer bolo de cenoura, escreveu a receita de cabeça do que ela lembrava, veio me mostrar, corrigimos algumas medidas e um pouquinho do portugues, pedi pra ela separar os ingredientes e rapidinho ela veio me avisar que ja tava tudo pronto pra gente botar a mao na massa! 

Ficou bom!

Fui testar uns dolares e olha, a parada ta complicada... minha mae pediu um cartao porto com iof zerada, só que o dolar que hoje ta em 6.06 (decimal point is comma) cobraram 6,39, no BB saiu por 6,29 + 4.38% de iof ficou incriveis 6.60! É, como quem converte nao se diverte, vamos de conta BB Americas mesmo, Wise e a Nomad que parece ser o mais viavel.

Descobri que o chefe Everton é maluco fanatico pelo Botafogo, agora posso dizer que tenho um camarada que ja foi viajar pra fora pra ver jogo do time, o Thyago Luiz nao conta que lembro dele sempre fazendo isso!

Jantamos em barão e viemos dormir no apartamento que afinal de contas, as crianças ainda estao em aulas!

Ah, comprei ingressos pra Nasa na 'cyber monday', belo desconto!

Insonia forte essa noite!

Diario das Ferias de 2024 - 01.12.2024 - Dia 2 - Domingo

Bate-volta em São Paulo, Katsu Curry e stand up

Hoje foi dia de bate volta em sao paulo, ia deixar os hamsters com minha mae, mas deu branco e não rolou.

Acabei que jantei sozinho em barão um Katsu Curry do

da radial que comprei pra almoçar na patriarca e que tinha esquecido por completo a Ju foi sair com o golzinho com o Vinny pra pegar a Helena na casa da Helo, viu me avisou e foi uma boa janta, curto esse prato.

Fui e voltei pela bandeirantes, tudo tranquilo, transito na marginal de leve só na ida pra ZL.

De noite tinha teatro, fui ver o stand up do cara do kibe loco de policial, interessante, mas uma hora e meia é tempo demais pro formato. Fiquei pertinho mesmo, nao que eu enxergue muita coisa de perto, mas tava ali na cara do gol. Legalzinho a apresentacao, uma risada ou outra, mas mais do mesmo, enfim, ja era o esperado.

Cheguei em casa, tava meio caos porque a Ju tinha acabado de matar uma aranha daquelas gigantes que vira e mexe aparecem em casa, marcar dedetizacao e jardineiro! Deixa eu ja colocar na lista, feito!

Diario das Ferias de 2024 - 30.11.2024 - Dia 1 - Sabado

Primeiro dia das férias: audiências, amigos e burocracias

Por mim, férias deveriam sempre começar as quartas feiras!

Bom, hoje foi o primeiro dia das férias, sabado dia 30 de novembro de 2024, a semana tinha sido bem caótica, tive audiencia em sao paulo no forum da barra funda, foi legla que pude almoçar com amigos que não via há mais de ano! Mas foi cansativo a correria, sem falar que tive outra audiencia, essa virtual, na quinta e apresentei umas laminas sobre integridade na reuniao geral da firma.

La vamos nós, bom, dei uma passada no poupatempo pra entregar o papel de transferencia do jipe da Ju pra mim, que no mesmo dia que eu comecei o processo descobri que era só fazer direto pelo celular em poucos minutos, que ódio! E odio 2, porque uma vez iniciado o 'processo antigo' pra cancelar só indo no detran, enfim, entreguei o tal do papel e deve sair a restrição do documento em alguns dias.

Figura 1: Protocolo Detran

Na sequencia, encontrei alguns amigos pra almoçar no outback, o mano Rewth e o Caio eu nao via há quase uma década, o OC e o Alex vi deve fazer uns 2 meses na casa da Dani que fizemos um churrasquinho pra matar a saudades e colocar o papo em dia. Não foi um outback classico igual teve algumas ocasioes no Rio de Janeiro, mas foi interessante!

Figura 2: Almoço no Outback

Voltando pra casa passei no atacado que abriu no lugar do Macro, chama Giga, mais do mesmo.

Jantamos em casa e eu nem lembro o que que foi, tambem ja faz 3 dias, hoje é terça dia 03.12.2024.

A burocracia simplificada para isenção do IPVA no estado de São Paulo

Minha Jornada por Isenção PCD: IPVA, Carro Zero e Avaliação Biopsicossocial

Esse é um daqueles momentos que você se pergunta porque que não fui atrás disso antes!

Introdução: Meus Direitos como PCD

Bom, eu sou deficiente desde que a Dilma sancionou no finalzinho de 2012 a lei 12764 e virei deficiente múltiplo em 2021 quando o Bozo sancionou a lei 14126.

Enfim, isso posto, daria pra eu pedir isenção de compra de carro zero, IPVA, estacionamento PCD, dispensa de rodízio em SP, entre outros direitos relativos a minha pessoa com deficiência.

• Isenção de compra de carro zero
• Isenção de IPVA
• Estacionamento PCD
• Dispensa de rodízio em São Paulo

---

Atualização: 29/11/2024

O 'ESTADO' não me considerou digno da isenção!

Legal o processo ser simples, rápido, não burocrático, mas... não deu!

---

Atualização: 16/06/2025

Eu moro em São Paulo e nunca tinha ido atrás de comprar carro zero ou mesmo de ter desconto no IPVA, aí ano passado eu achei que daria pra perder uns dias com isso e fui atrás da isenção do meu possante, ano 2012.

Que nem era meu, era da minha acompanhante terapêutica que me acompanha há mais de 20 anos e que não gosta muito dessa alcunha, prefere esposa mesmo... mas enfim, era pré-requisito o carro ser meu.

Lá se foi mais um tempo e dinheiro pra transferir o carro, fez vistoria no carro, ir no cartório (eu e esposa, juntos) e depois no Detran pra liberarem o documento (tipo dar um enter no sistema e o docuemnto do carro aparecer no aplicativo do Detran), e na semana seguinte a que fiz a transferência a o governo aqui de São Paulo liberou pra fazer tudo on-line pelo aplicativo! Quer dizer a vistoria ainda precisa, mas Nooosssa, que ódio que fiquei!

Processo de Isenção de IPVA

Bom, com o carro no meu nome lá fui eu... inicia o processo de pedido de isenção de pagamento do IPVA. Fui no Detran 2 vezes porque logicamente o site não funciona direito e não finaliza o que deveria com sucesso, enfim, depois que o processo tava ok, digo, iniciado, fui fazer a avaliação, foi numa clínica credenciada do Detran, tava L O T A D A, horário marcado pra inglês ver, não era nem horário marcado nem ordem de chegada nem prioridade, preferencial... nada era uma zona! Enfim 2, fiquei 3 horas no relógio esperando pra me atenderem, aí passo na assistente social, repsondo umas 352 perguntas (exagero não lembro quantas eram) volto pra salinha mais uma hora e o médico chama, me examina, faz outro milhão de perguntas, pede de novo os laudos/exames da minha deficiência (que eu já tinha anexado no site, que levei no Detran, e por sorte tava com eles de novo por lá).

Avaliação Biopsicossocial e Resultado

Enfim 3 ou 4, uso muito enfim, preciso arrumar um outro advérbio pra usar.. mas vamos lá, voltando, o médico complementou algumas perguntas da assistente social e no final falou que não poderia me dar o parecer na hora mas que era pra eu ficar tranquilo que o sistema mandaria um e-mail informando, em no máximo, 7 dias... demorou 15 e nada, liguei e aí me informaram que tava no site que eu já tinha consultado uma dezena de vezes e não tinha nada, o pulo do gato? Colocar nem lembro o que no final do endereço que tava lá no navegador, e aí tava lá, o tal do parecer, é que não lembro onde anotei o que colocar no link e não to achando o print, but era algo assim:

O cidadão passou por avaliação biopsicossocial dia tal, pela assistente social tal e médico tal e que após a tabulação dos resultados levou a pontuação de nem lembro quanto, e que portanto eu sou deficiente leve e não tenho direito a isenção. E fim!

Quando procurei a pontuação eu tava ali na raspa da beiçola, quase nem me enquadrando como deficiente.

Reflexão Final

Seilá, eu tô bem temeroso quanto ao sistema e a avaliação biopsicossocial.

PLR - Participação nos Lucros e Resultados - Se teve lucro tem que ter distribuição! E quando não teve, bom ai é mais complicado!

PIX Recebido do SINDPD

Resumo: Relato sobre o recebimento de um PIX do SINDPD, processo inesperado e simples, bastando informar os dados em um site específico.

Eu nem tava sabendo desse processo, mas saiu e só precisei informar meus dados num site feito especificamente pra esse fim.

Figura 1: PIX recebido SINDPD

Divagações no voo...

Quem é o Buga? Uma Apresentação Pessoal

Saudações,

Vida Pessoal

Sou o Buga, nasci em 1980 em São Paulo capital, mudei pra Campinas em 1998, fui pra Brasília em 2006 e retornei para Campinas em 2014.

Na família somos eu e meu pai.

Tenho uma acompanhante terapêutica, meu anjo na terra, a Ju está comigo há mais de 20 anos, ela prefere a alcunha esposa.

Somos pais de duas pessoas, a Helena com 8 anos e o Vinícius com 12, de uma cachorra, a Wendy e de 3 hamsters, o Paçoca, a Penélope e o Pequeno.

Formação e Carreira

Formei em engenharia química, fiz MBA em mercado financeiro, duas pós-graduações em tecnologia da informação, tentei por 3 vezes terminar faculdade de química, mas ainda não finalizei.

Tive uma fábrica de rodas e shapes de skate, que montamos do zero, eu e um amigo de infância com 20 e poucos anos, foi muito intenso e desafiador, aprendi muito, viajei bastante, conheci empresas, pessoas, trabalhava muito, não tanto quanto com cartões, mas era bastante mesmo, o sonho durou 6 longos anos.

Trabalhei a vida toda em banco, 20 longos anos, cuidava do sistema de autorização de cartões, as vezes funcionava aos trancos e barrancos, mas funcionava! Costumava dar uns probleminhas, mas não posso falar sobre isso publicamente, enfim, os riscos da atividade são inerentes a loucura do dia a dia. Teve vez aue fiz caca e fui promovido e teve vez que fiz caca e fui demitido, é da vida!

Abandonei esse mundo e desde o carnaval de 2023 virei engenheiro de processamento de petróleo júnior na Petrobras.

Vida Familiar e Crenças

A Ju é judia, eu sou deísta.

Saúde Mental e Neurodiversidade

Tenho minhas incontáveis idiossincrasias, tenho ciência de quase a totalidade delas, entretanto com o mascaramento de décadas e treinamentos/condicionamentos baseados no pior de Skinner, Vygotsky e Pavlov acabei sendo moldado para passar despercebido na multidão, na multidão, porque quem me conhece um pouco mais a fundo, consegue perceber que não sou muito ajustado.

Até falar ao telefone as vezes eu conseguia, quer dizer, as vezes não, muito raramente.

Não tenho hobbies, meus hiperfocos tem começo, meio e fim, não duram mais de 1 ano.

Tive até hoje, no máximo uns 10 episódios de desregulação total e o que me deixa sempre pasmo é que logo imediatamente após a explosão eu já me sentia pleno, num estado de torpor, uma paz em minha mente.

É desgastante ao extremo viver na normalidade, como consequência direta desenvolvi insônia crônica, não durmo direito desde que consigo me lembrar... Os remédios que controlam e induzem meu sono tem que ser trocados com frequência pois o efeito cessa depois de um par de anos.

Passei por alguns episódios de depressão ao longo da vida, geralmente desencadeados por alterações na minha rotina. Nesses momentos costumeiramente acompanham sintomas físicos, como vômitos, diarréia, sudorese que duram semanas até que eu consiga me adaptar novamente.

As crises de depressão severa duram de 6 meses a 1 ano.

Sensibilidades Sensoriais

Meu paladar é infantil, tenho restrição alimentar alta (menor que de meu pai que é vegetariano desde que me conheço por gente), mas assim como no comportamento também fui condicionado a me alimentar de acordo com o cardápio mesmo não gostando. Tirando peixes, frutos do mar e afins que sou alérgico, acabo conseguindo com muito esforço comer praticamente de tudo, mas tem seu preço e faz um tempo que não tô pagando mais não.

Sons não me incomodam há mais de década, desenvolvi habilidade de estar constantemente com uma música de fundo na minha mente, por vezes ela sai e sou pego na ecolalia e aí são alguns minutos pra me regular novamente, uso abafador apenas quando vou me deitar para dormir, costumava deixar algum som no ambiente, mas ultimamente, 4 anos pra cá o abafador tá de boa.

Tenho hipersensibilidade ao toque, pele sensível, se começo a suar desencadeia urticária colinérgica, uma etiqueta na camisa me causa uma crise alérgica, uso o mesmo uniforme há décadas, com poucas variações. Costuma ser sempre bem folgado pra não ficar justo, colado na pele. Uso uma camiseta sem costura lateral, calça social quando o serviço obriga calça mas geralmente estou de bermuda folgada e tênis largo (estilo skate). As variações causam desconforto, jeans, camisa, ALL star não são bem vindos, uso, mas dão "coisa".

Até a pandemia utilizava toca na cabeça. Tanto que se não soubesse o que me dar de aniversário era só comprar uma que era sucesso garantido, tenho mais de 50, but usava quase sempre as mesmas 3. Descobrimos que era um amuleto e acabei, assim como minha corrente de bicheiro e acabei abandonando seu uso sem grandes prejuizos.

Possuo extrema dificuldade em ir ao cabeleleiro, evito ao máximo, a última vez que fui, foi em 2014, passo mal, acabou deixando o cabelo comprido justamente por isso, esporadicamente, a cada 1, 2, 3 anos, não tenho uma memória das datas, raspo careca, já já tá na hora de raspar novamente. Ah, costumo frequentemente enrolar o cabelo nos dedos até a ponta do dedo ficar roxa, faço isso desde que me conheço por gente.

Amigos e Conexões

Tenho amigos que não vejo mais, outros que nem notícias tenho, um que é praticamente meu vizinho e que passo semanas sem o ver, são bem poucos os que tenho algum contato rotineiro.

Nesse final de semana reencontrei amigos de Brasília, alguns dos quais não via há 10 anos e não tinha mais contato, gostei muito, deu pra me atualizar dos acontecimentos mais marcantes na vida da maioria deles, muitos acontecimentos maravilhosos, outros nem tanto, histórias engraçadas, assustadoras, apaixonantes, revoltantes, enfim, coisas da vida de meus amigos que eu nem imaginava... mas todos estão bem, na medida do possível!

Infelizmente sinto que, obviamente até pelo tempo e meu distanciamento, que não pertenço mais aquele mundo. Fiz grandes amigos na vida, sei que eles se preocupam comigo e me querem bem mesmo eu sendo, digamos, o Buga.

Há algum tempo não ouço mais a frase: - "Você que é o Buga?" Com entonação de surpresa/espanto e com certeza a expressão fácil não negaria o sentimento, mas eu acho, acho mesmo porque essa habilidade eu não possuo. Quem nunca tinha me visto com certeza me imaginava uma pessoa bem diferente! Estou bem com isso, nunca gostei da reputação me preceder.

Reflexão Final

Ah seila, é mais ou menos isso aí.

Se me perguntarem se eu preferia ter sido eu sempre; com certeza eu teria escolhido eu, mas não tive a opção e hoje sou essa mistureba maluca em constante luta comigo mesmo.

Parafraseando o poeta: "Acho que não sei quem sou só sei do que não gosto"

Fui, Buga
Brasília -> Campinas
4 de agosto de 2024

2024 07 28 - Um lugar para escrever minhas abobrinhas!

Memórias Tech: REXX, Flash e Andanças pelo Mundo

Há algum tempo atrás, sem saber ao certo o porquê, apaguei uma coletânea de textos que eram o melhor amigo da minha memória. Tenho backup, mas pra restaurar vai dar uma trabalheira danada, então deixa pra lá, vamos começar de novo.

Notas sobre REXX

Hoje achei sem querer umas notas sobre REXX, coloquei lá no meu "livro" digital:

• Notas de Mainframe do Buga - Capítulo 7: REXX

Minha Conta no X

Abri uma conta no X, segue lá:

• @Bugolino2

Andanças pelo Mundo em 2011

Achei também minhas andanças pelo mundo quando isso ainda era novidade! Fiz um vídeo na época (por volta de 2011) depois de ler que o iPhone tava gravando dados de localização. Não lembro direito o processo que arrumei, mas o resultado é bem da hora! Pra fazer a brincadeira funcionar, converti o arquivo original de Flash (.swf) para AVI. Aproveitei e postei no Reels do Instagram. Confira o vídeo abaixo:

Player de Flash

Segue um leitor exibidor player de Flash totalmente funcional:

• Fléshi Player

BP Tools - BPTools - excelente ferramenta criptografica para seu dia a dia

Quase que perco... NADA COMO UM BOM BACKUP!

Resumo: Relato sobre a importância do backup ao recuperar um software essencial, links para download do EFT calculator e dicas sobre licenças e versões antigas.

Quase que perco... NADA COMO UM BOM BACKUP! Os caras tao querendo cobrar 1000 doletas por ano de uso!

Screenshot do software EFT calculator recuperado de backup

Os 2 modulos principais que é a calculadora e o enviador de comandos pro Thales tao ai, muito bom, achei lá atras no comecinho da firma dos caras, ainda chama EFT calculator e ja era bom!

Aqui o link pro drive pra baixar

https://drive.google.com/file/d/1wO1bOelY5CyJBKBcaWIbs40glBa-rBtY/view?usp=drive_link

e os links que eu tinha salvo achando que permalink é eterno!

https://www.eftlab.com/files/bp-tools-20.03-1271-master-a2e4297.exe

https://www.eftlab.com/download/win-3264/

Minha propria fonte pro computador!

Minha Fonte Digital: Projeto Concluído!

CAMPINAS, SP 31 DE JANEIRO DE 2024

Finalmente, após anos, consegui concluir a versão preliminar da minha fonte para documentos eletrônicos com a minha própria letra!

A sensação de ver esse projeto, que estava congelado há tanto tempo, tomando forma é indescritível, uma verdadeira perda de tempo!

Cada traço, cada detalhe, carrega consigo não apenas a tinta digital, mas também todo o esforço e a paixão que investi nesse trabalho. Ao longo desse processo, enfrentei inúmeros desafios e obstáculos, mas a persistência e a determinação me mantiveram focado no objetivo.

Ver a fonte funcionando, mesmo que em uma versão preliminar, é o tique que faltava na lista de pendências/tarefas, volto a dormir tranquilo.

Cada caractere impresso carrega a minha identidade, o resultado de incontáveis horas de trabalho e a vontade de criar algo único, novo, só meu!

Agora, mesmo sendo uma versão inicial, tenho em mãos um produto funcional, o que representa um marco significativo, essa conquista é apenas o começo de uma jornada de aperfeiçoamento e refinamento.

Ainda há muito a ser feito, mas a base está estabelecida e o caminho a ser percorrido se revela promissor, não que vá ter uma segunda versão ou que eu volte a mexer com isso, mas vale a intenção.

Que essa fonte seja a materialização de toda a minha dedicação e paixão por finalizar itens de minhas listas, que não são poucas nem são poucos itens em cada.

Que cada documento escrito com essa fonte carregue não apenas palavras, mas também a expressão da minha satisfação em ver esse projeto ganhar vida.

Obrigado a todos os envolvidos!

Figura 1 - A fonte em ação

Figura 2 : fonte do Buga em bold

The End of an Era - Last Mainframe Shutdown at Petrobras

Resumo: Buga comenta a desativação do mainframe da Petrobras há um ano, discutindo COBOL, legado, tentativas de migração e o futuro dos mainframes no setor bancário.

Desligando o Mainframe da Petrobras: Reflexões sobre Legado e Tecnologia

Há 1 ano a Petrobras tirava de operação seu mainframe!

Contexto e Histórico

Desde que comecei a trabalhar com cartão de crédito ouço falar que o mainframe está morrendo.

Existiram algumas tentativas em meados de 90 que deram em nada, quer dizer, giraram a economia, mas não atingiram o resultado pretendido. De uns 10 anos pra cá está rolando uma conversão automática de código COBOL pra Java, a própria IBM e no momento a Kyndryl tem projetos e oferece mão de obra e serviços para essa demanda, mas, na real, não funciona satisfatoriamente. A Cielo chegou a comprar um adquirente americano que rodava fora do ambiente mainframe pra incorporar a tecnologia, mas não deu certo.

Tentativas de Migração e Limitações

O que vai acabar com o mainframe não são as novas tecnologias, longe disso, até porque a maioria das tecnologias disruptivas que vemos atualmente nada mais são que usos de ideias e conceitos que já existem nos mainframes há décadas, mas isso é discussão acalorada e pra outra ocasião.

Atualmente, no setor bancário/cartão só existe 1 pilar que ainda sustenta o mainframe vivo, o legado!

De um sistema aqui, outro ali, vão migrando, convertendo, desligando algumas siglas, criando um novo sistema em baixa plataforma pra prover a mesma solução, movimento esse que nunca entendi creio que é mais seguir a onda, não ficar para trás porque tem gente fazendo assim preciso fazer também. Igual tantas outras modas como as metodologias ágeis ou ainda tentar aplicar testes de completude ou automatizados, que sequer fazem sentido pro COBOL.

Voltando ao legado, dependendo da aplicação, não dá pra reescrever, seja automaticamente ou não, não há pessoas que embarquem na ideia, o risco é inaceitável.

O Futuro dos Mainframes

Daria pros bancos continuarem pro resto da vida trabalhando com mainframes, sério!

O mainframe se adaptou, evoluiu mas demorou muito pra levar isso aos clientes, a IBM errou e errou feio ao não mudar seu modelo de negócio, restringir o acesso a tecnologia ao invés de incentivar como todos os players da computação em nuvem sempre fizeram, enfim agora é tarde, o estrago já foi feito e é irreparável.

O IBM mainframe continua evoluindo, o hardware está no limiar da tecnologia atual, os compiladores estão mais robustos e otimizados, os gerenciadores de transações, seja ela o tupiniquim GRI do Itaú Unibanco e do Banco do Brasil CICS continua uma obra de arte o IMS idem, seu banco de dados, o DB2 nem se fala e o Z/Os, seu sistema operacional é um espetáculo à parte!

O que decretará o fim da computação centralizada em hardwares Z da IBM será a migração de saldos, mas isso vai demorar um bocado, se é que acontecerá de verdade. Ainda não vi movimentação grande de nenhum banco nesse sentido (banco aqui leia-se, Santander Brasil, CAIXA, Banco Bradesco, Itaú Unibanco e Banco do Brasil).

Longa vida ao mainframe!

Escrito e revisto meia boca, porque to na hora do almoço!

Figura 1: Desligando pra sempre o mainframe da Petrobras

Tela fica amarelada escureçe as 22:00 android

Tela Fica Amarelada e Escurece às 22:00 no Android

Essa daqui acontecia no Poco, no Pixel tinha a opção de desligar o modo noturno e funcionava até que bem, mas no Xiaomi de jeito nenhum. Achei por aí na net uma solução...

Passo a Passo para Desativar o Modo Noturno

Tem que baixar o Android Platform Tools. Você pode encontrar no link oficial:

Android Platform Tools

Coloque o celular em modo desenvolvedor e rode via ADB os três comandos abaixo.

Comandos ADB para Desativar o Modo Noturno

adb shell 'settings list secure'

adb shell 'settings put secure night_display_activated 0'

adb shell 'settings put secure night_display_auto_mode 0'

Pronto, tela amarela de noite nunca mais! Pensa num negócio que irritava horrores!

Contexto sobre o Modo Noturno

O modo noturno ou escuro, presente em dispositivos Android como os da Xiaomi (Poco X7, X3, F6, etc.), pode ser ativado ou desativado nas configurações de tela e brilho, conforme tutoriais disponíveis online. No entanto, quando o sistema força a ativação automática às 22:00 ou em horários específicos, pode ser necessário usar ferramentas como ADB para desativar completamente o recurso, especialmente se a opção não estiver acessível nas configurações padrão.

Prova de conceito - POC - Jogo passa fase tipo Mario - Da pra fazer jogo sem saber nada de nada, só precisa de tempo e dedicação!

Achados de Backup: Prova de Conceito de um Jogo

Sempre bom dar uma vasculhada nos backups, as vezes achamos coisas bem interessantes!

Não consegui lembrar sequer o nome do programa que me possibilitou a criação dessa maravilha da tecnologia!

Da pra fazer jogo sem saber nada de nada, só precisa de tempo e dedicação!

Video 1 : Prova de Conceito

O pacote com o 'jogo'

https://drive.google.com/file/d/1ksC0HJBei3hpJ-psqVj0xjzsLEgIVGSw/view?usp=drive_link

---

O programa que criou essa maravilha foi o 

MMF2 - Multimedia Fusion 2

abri o pacote com o jogo no programa demo (download ai acima) e separei o 'fonte', ficou aqui

https://drive.google.com/file/d/13DCyWp2SLZcYkc5zOSQ_svYpPn4TCLmu/view?usp=sharing

Pacote de manuais do Vision Plus 2.7

Manuais Vision Plus 2.7: Relíquia PaySys encontrada!

Tava fuçando nos HDs antigos e eis que encontro os manuais do famoso Vision Plus, nessa época era da PaySys.

Figura 1: Tela do menu dos PDFs

Árvore de arquivos do pacote Vision Plus 2.7

  
E:.
│   1front.pdf
│   copyright.pdf
│   Index.log
│   Index.pdx
│   migration instructions.pdf
│   ReleaseLevel.pdf
│
├───ASM
│   │   Asmfront.pdf
│   ├───REFERENC
│   │       asm25rf.pdf
│   │       Updates.pdf
│   └───TECH
│           Asm25te.pdf
│           FLOW.PDF
│           Updates.pdf
│
├───CDM
│   │   cdmfront.pdf
│   ├───REPORTS
│   │       Cdm61rp.pdf
│   │       Updates.pdf
│   ├───SCREENS
│   │       Cdm61sc.pdf
│   │       Updates.pdf
│   ├───TECH
│   │       Cdm61te.pdf
│   │       FLOW.PDF
│   │       Updates.pdf
│   └───USER
│           Cdm61ur.pdf
│           Updates.pdf
│
├───CMS
│   │   cmsfront.pdf
│   ├───REPORTS
│   │       Cms25rp.pdf
│   │       Updates.pdf
│   ├───SCREENS
│   │       Cms25sc.pdf
│   │       updates.pdf
│   ├───TECH
│   │       Cms25te.pdf
│   │       Flow.pdf
│   │       Updates.pdf
│   └───USER
│           Cms25ur.pdf
│           Updates.pdf
│
├───CSF
│   │   csffront.pdf
│   ├───CMS
│   │       cmscsfpr.pdf
│   │       nous.pdf
│   └───MBS
│           mbscsfpr.pdf
│           nous.pdf
│
├───CTA
│   │   Ctafront.pdf
│   ├───REPORTS
│   │       Cta61rp.pdf
│   │       Updates.pdf
│   ├───SCREENS
│   │       cta61sc.pdf
│   │       Updates.pdf
│   └───TECH
│           Cta61te.pdf
│           Flow.PDF
│           Updates.pdf
│
├───FAS
│   │   Fasfront.pdf
│   ├───REFERENC
│   │       Fasref.pdf
│   │       Updates.pdf
│   └───Technica
│           fastech.pdf
│           Flow.pdf
│           Updates.pdf
│
├───IMP
│       Imp60sy.pdf
│       Updates.pdf
│
├───ITS
│   │   Itsfront.pdf
│   ├───REFERENC
│   │       Its71rf.pdf
│   │       updates.pdf
│   └───TECH
│           flow.PDF
│           Its71te.pdf
│           Updates.pdf
│
├───LTS
│   │   Ltsfront.pdf
│   ├───REFERENC
│   │       Lts61rf.pdf
│   │       Updates.pdf
│   └───TECH
│           FLOW.PDF
│           Lts61te.pdf
│           Updates.pdf
│
├───MBS
│   │   mbsfront.pdf
│   ├───REPORTS
│   │       mbs27rp.pdf
│   │       Updates.pdf
│   ├───SCREEN
│   │       mbs27sc.pdf
│   │       Updates.pdf
│   ├───TECH
│   │       FLOW.PDF
│   │       Mbs27te.pdf
│   │       Updates.pdf
│   └───USER
│           Mbs27ur.pdf
│           Updates.pdf
│
├───SPP
│   │   sppfront.pdf
│   ├───REFERENC
│   │       Spp25ref.pdf
│   │       UPDATES.PDF
│   └───TECH
│           Spp25te.pdf
│           updates.pdf
│
├───SS
│       SS60gu.pdf
│       ssfront.pdf
│       Update.pdf
│
├───TramsAG
│       AGfront.pdf
│       TRMAG5.pdf
│       Updates.pdf
│
├───TRAMSBC
│   │   bcfront.pdf
│   ├───REFERENC
│   │       Bcre.pdf
│   │       Updates.pdf
│   └───TECH
│           bcte.pdf
│           updates.pdf
│
├───TRAMSDE
│   │   DEfront.pdf
│   ├───REFERENC
│   │       de71re.pdf
│   │       Updates.pdf
│   └───TECH
│           De71te.pdf
│           Updates.pdf
│
├───Tramsec
│   │   Ecfront.pdf
│   ├───REFERENC
│   │       t-ec7ref.pdf
│   │       Updates.pdf
│   └───Technica
│           T-ec7tec.pdf
│           Updates.pdf
│
├───TRIAD
│   │   trifront.pdf
│   ├───4.1
│   │   ├───CMS
│   │   │       Cmstriad.pdf
│   │   │       updates.pdf
│   │   └───FAS
│   │       └───TECH
│   │               Fastectr.pdf
│   │               nous.pdf
│   └───5.0
│       ├───cms
│       │       cms5.0.pdf
│       │       updates.pdf
│       └───fas
│               fas5.0.pdf
│               updates.pdf
│
├───TRMBASE
│   │   trmfront.pdf
│   ├───REFERENC
│   │       Trm71re.pdf
│   │       Updates.pdf
│   └───TECH
│           Trm71te.pdf
│           UPDATES.PDF
│
└───VPLUS400
    │   as400front.pdf
    │
    ├───AS400 Supplement
    │   │   AS400.pdf
    │   ├───ASM
    │   │   ├───Reference
    │   │   │       asmscre.pdf
    │   │   └───Technical
    │   │           asmtech.pdf
    │   ├───CMS
    │   │   ├───reports
    │   │   │       cmsrepo.pdf
    │   │   ├───screens
    │   │   │       Cmsscre.pdf
    │   │   └───tech
    │   │           Cmstech.pdf
    │   ├───CTA
    │   │   ├───Screens
    │   │   │       ctascre.pdf
    │   │   └───Tech
    │   │           ctatech.pdf
    │   └───FAS
    │       ├───Reference
    │       │       Fasref.pdf
    │       └───Tech
    │               fastech.pdf
    │
    ├───SS
    │       ssas400.pdf
    │
    └───Sys&Oper
            flow.pdf
            sys&op.pdf
            updates.pdf
  

Download do pacote completo

Baixar pacote Vision Plus 2.7 (Google Drive)

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

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