Tradutor

quinta-feira, 6 de fevereiro de 2014

Moedas Criptográficas: Elétrons como Força de Trabalho

MOEDAS CRIPTOGRÁFICAS:
ELÉTRONS COMO FORÇA DE TRABALHO



BEM, Geyslan Gregório



RESUMO
Breve explanação do conceito moeda criptográfica e sua implicação na mudança de paradigma da atribuição de valor e prova de trabalho comumente aceitos. Tece sobre visões econômicas e o uso do modelo da demanda e oferta nesse commodity. Expõe métodos de obtenção e comercialização de moedas e possibilita uma discussão sobre a viabilidade da criação de uma nova/própria moeda.

ABSTRACT
Brief reasoning of the cryptographic currency concept and its implication in the paradigm change of the attribution of values and work-of-proof commonly accepted. It discusses economic views and the use of the model of supply and demand in this commodity. Exposes methods of obtaining and trading currencies and provides a discussion of the feasibility of creating a new/own currency.

Keywords: Cryptocurrency, Cryptocoin, Work-of-proof, Mining, Economics, Fiat-money, Paradigm breakthrough.



1. INTRODUÇÃO

Economists, and especially monetarists, tend to overestimate the purely economic, narrow and technical functions of money and have placed insufficient emphasis on its wider social, institutional and psychological aspects. However, money originated very largely from non-economic causes: from tribute as well as trade, from blood-money and bride-money as well as from barter, from ceremonial and religious rites as well as from commerce, from ostentatious ornamentation as well as from acting as the common drudge between economic men.” Roy Davies [1]


2. MOEDA

Uma vez que a domesticação de animais nas culturas tende a preceder às colheitas, o gado foi, provavelmente [1], a primeira forma de dinheiro utilizada, por volta de 9.000 a 6.000 Antes da Era Comum. Tais animais eram, e ainda são em alguns lugares do planeta, meio para transações de objetos. Dentre outros, os produtos da colheita, os minerais preciosos, e os citados animais, foram os mais utilizados por todo o período subsequente, até 687 AEC, quando a primeira moeda bruta foi cunhada em Lídia [2-3], na Ásia Menor.

Figura 1 - Moeda do início do século 6 AEC - um terço de estáter
Fonte: http://www.cngcoins.com/Coin.aspx?CoinID=57383


Dos primórdios do dinheiro até hoje muito mudou, no entanto, sua propriedade básica persevera: o valor atribuído. Com essa atribuição, o homem é capaz de facilmente se desfazer de uma posse, material ou virtual, em troca de algum outro produto social, também material ou virtual, por conta da valoração [4] e consequente precificação das posses envolvidas.

A função por excelência da moeda é a de intermediária de trocas. Para desempenhar esse papel ela não precisa ter nenhum valor intrínseco ou, como outrora, ser lastreada em metal precioso. Frise-se que a moeda é um bem que possui confiança e aceitação geral pelos agentes econômicos, estes sendo todos os indivíduos e instituições que, através das suas ações, intervêm num sistema econômico. A medida de valor [5] também é função da moeda quando esta é precificada. E, por fim, ela serve como reserva de valor, para indivíduos que não precisam gastá-la imediatamente, transformando-a em ativo financeiro.


2.1. DEMANDA POR MOEDA

A teoria clássica [5] diz que a moeda é demandada com a finalidade de se efetuarem pagamentos originados por transações de compra e venda de bens e serviços. Nesse pensamento, a demanda de moeda está diretamente ligada a duas variáveis: volume de transações e velocidade da moeda, esta última que representa o número de vezes que a moeda gira para efetuar pagamentos (quanto maior a velocidade, menor a necessidade de moeda).

Já John Maynard Keynes, economista britânico, afirmou que a demanda de moeda é originada por três motivos: transação, precaução e especulação. A precaução faz com que as pessoas demandem moeda para cobrir despesas em caso de emergências, na vez que, por meio da especulação, as pessoas preferem manter sua riqueza na forma de moeda (preferência pela liquidez) garantindo maior taxa de juros em posterior aplicação.


2.2. CRIAÇÃO (INJEÇÃO) DE MOEDA

Atualmente, a moeda é criada tanto por meio de débitos e empréstimos, quanto por medidas políticas como a Quantitative easing [6] ou por simples impressão de mais papel moeda. Contudo, não deixa de ser lastreada na riqueza real produzida pela economia num todo, pois se houver injeção de moeda acima desse critério, o seu valor decresce ocasionando a [7] inflação. Mesmo a moeda tendo um contra-balanço, em princípio, para sua quantidade em circulação, ela, em verdade, demonstra caráter ilimitado. É salutar se ater ao fato de que a moeda é apenas uma representação intermediária de valor, não havendo um objeto, material ou imaterial, ao qual se possa identificar vínculo direto ao seu valor atribuído. Em suma, moeda, como entendido nos dias de hoje, não é um bem escasso; é um artifício controlador da economia de determinado Estado, criado, por vezes, como uma renovação do ciclo de débito, haja vista a demanda crescente por crédito.


3. MOEDA CRIPTOGRÁFICA


Figura 2 - Imagens ilustrativas das moedas criptográficas mais comuns (Litecoin e Bitcoin, respectivamente)
Fonte: http://arranrice.com/2013/12/26/trading-crypto-currencies/


Tudo se inicia quando o pseudônimo Satoshi Nakamoto (pessoa ou grupo supostamente detentor(a), hoje, de quase um milhão de bitcoins [8]) desenvolve o que foi chamado de “Bitcoin: A Peer-to-Peer Electronic Cash System” no paper [9] de mesmo título. A ideia de se criar uma moeda virtual já havia sido discutida por Steven Levy [10], e a custo computacional por Wei Dai [11], entretanto, foi após o advento da rede bitcoin que o conceito de moeda criptográfica veio à tona.

É importante relevar que essa nova “moeda” virtual em si não é uma moeda como as que foram anteriormente citadas [12-16], ela carece, para a terminologia econômica, de alguns aspectos como aceitação geral. Porém, essa carência tende a se extinguir com o tempo, como pode ser acompanhado pelo site coinmap.org e pela adesão crescente [17-18] noticiada pela mídia.


3.1. WORK-OF-PROOF

A moeda que o homem recebe pela sua labuta diária (seja ela prestada fisicamente ou intelectualmente) é uma mera contraprestação pecuniária. Em resumo, o resultado de seu esforço é sua prova de trabalho, seu work-of-proof. Na febre do ouro [19], o homem buscou obter resultados futuros com a mineração desse metal maleável; tal anseio se repetiu com a chegada das moedas criptográficas.

Um dos grandes questionamentos contrários a essa nova moeda é o de que se está a fazer dinheiro do nada. O que se esquece é que tais moedas virtuais são escassas, finitas, contrariamente à moeda estatal que pode ser criada facilmente. Frise-se, mais uma vez, que as “moedas” virtuais são objetos valorados pela sua oferta e procura, dessa forma se encaixando, perfeitamente, dentre as [20] commodities.

Ao se minerar a moeda virtual diretamente pela rede peer-to-peer, o paradigma da prova de trabalho é quebrado, pois esta não está mais atrelada ao esforço físico ou intelectual, e sim à aceitação da própria moeda depreendida pelo poder computacional empregado na sua mineração (lastreio em bits [21]):


They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them.” [9]


Os softwares específicos para a mineração (minerd, cgminer, cudaminer etc) coletam as transações da rede, validam-nas evitando as conflituosas, inserem-nas em grandes blocos, e processam os hashes criptográficos inúmeras vezes, até encontrar um bom o bastante para uso. Após isso submetem o bloco para a rede, adicionando-o à cadeia de bloco [22]. Os mineradores estão, em suma, automatizando o processo de segurança da rede e recebendo uma recompensa em troca.

Mesmo que sejam contra esse novo tipo de moeda, as políticas estatais [23] não têm o poder para recusarem sua circulação entre seus detentores. Além das várias propriedades que tais moedas oferecem, sejam algumas delas a descentralização, transações anônimas (se tomados os cuidados necessários), segurança criptográfica, e custos transacionais reduzidos a centavos (comparados às taxas exorbitantes de cartões de crédito), há moedas paralelas à estatal [24-25] que circulam livremente em várias sociedades e são forte exemplo de fomentação de riquezas.


3.2. MANEIRAS DE SE OBTER MOEDA CRIPTOGRÁFICA

No Brasil há possibilidade de se comercializar (converter em/de moeda estatal) duas moedas virtuais: bitcoin e litecoin. Através de cadastro no site mercadobitcoin.com.br, o usuário pode efetuar compras e vendas a um custo percentual (intermediação). Essa empresa é uma sociedade limitada e está registrada na Receita Federal com a atividade econômica secundária descrita como “Atividades de intermediação e agenciamento de serviços e negócios em geral, exceto imobiliários”. Há ainda outros bons sites no exterior, já conhecidos dos investidores, nos quais se pode transacionar outras coins: MtGox (mtgox.com), e BTC-E (btc-e.com).

Outro método, e mais empolgante, é o de mineração da moeda diretamente pela rede peer-to-peer. Para tanto, o interessado deve dispor de poder computacional para o processamento de hashes que comprovam sua participação na construção da cadeia de blocos [26]. Transformar elétrons em moeda é um pouco confuso quando não se tem em mente a já discutida quebra de paradigma e aspectos sobre o funcionamento da própria moeda em questão; como exemplo temos a sua própria segurança que é fortalecida [27] a cada novo minerador de confiança que se conecta à rede.


Figura 3 - Mineração através do software cgminer.
Fonte: Rig do autor.


3.3. VIABILIDADE DE MINERAÇÃO

A mineração através de GPUs (2ª geração) ainda é possível para moedas alternativas e ou novas, a maioria baseada no algoritmo Scrypt [28], como a litecoin, todavia, quando se trata de mineração de bitcoin, ou seja, moedas que usam o algoritmo sha-256 [29], o retorno financeiro só é alcançado com o uso de ASIC [30] (Application-specific integrated circuit) (3ª geração), haja vista o seu baixo consumo de energia e alto poder de processamento, comparado às GPUs.

Isso se dá mais pela dificuldade [31-32] que tais moedas apresentam. Logo as moedas scrypt atingirão um nível de dificuldade tão alto que suas minerações só se darão através de ASICs também. Trata-se literalmente de uma “corrida do ouro”; quem conseguir “extrair” mais moedas o mais breve possível, com o mínimo de consumo energético e o máximo poder de processamento, terá, possivelmente, maior prospecção de lucro.

Figura 4 - Evolução da dificuldade de mineração da Litecoin de 05/2013 a 01/2014
Fonte: http://bitcoinwisdom.com/litecoin/difficulty


Figura 5 - Evolução da dificuldade de mineração da Bitcoin de 05/2013 a 01/2014
Fonte: http://bitcoinwisdom.com/bitcoin/difficulty


Evidencia-se, pela análise dos gráficos acima, que quanto maior a taxa de hash, maior a dificuldade. Em poucas palavras, quanto maior o interesse no minério de tal moeda, maior a dificuldade de mineração e, consequentemente, maior poder de processamento necessário.

Rigs (equipamentos) são comumente usados com o objetivo comum de minerar o máximo possível com o mínimo de energia. Seu efetivo funcionamento depende do conhecimento do interessado e da disponibilidade de partes (GPUs, Placas mãe, ASICs) no mercado.

Alguns mineradores são apenas hobbistas radicais [33] com pouco interesse no lucro da moeda. Sua satisfação está em montar o rig e vê-lo funcionando. Essa adesão se dá de forma similar a de hackers que participam de meios open sources com o interesse apenas de contribuir. Contudo, esse tipo de minerador faz parte de um ínfimo grupo, até por que o intuito da grande maioria é deveras a obtenção de lucro.

Figura 6 - Minerador com 6 (seis) GPUs (2 placas-mãe)
Fonte: https://bitcointalk.org/index.php?topic=7216.2220


Figura 7 - Minerador com 4 (quatro) GPUs
Fonte: https://bitcointalk.org/index.php?topic=7216.2220


O maior problema dos ASICs é sua indisponibilidade imediata. Os fabricantes tendem a demorar de dois a três meses para fechar lotes de pré-compra. Em suma, o interessado paga o produto (ou parte dele), aguarda o período da fabricação e entrega (para o Brasil, ainda deve-se somar o custo de 60% do imposto de importação mais ICMS). Tal demora encarece o produto e aumenta sua inviabilidade, lembrando que a dificuldade da mineração tende a aumentar constantemente: o minerador ASIC que mineraria n moedas no ato da compra, após todo o ínterim, ao ser recebido, minerará sempre menos moedas.

Figura 8 - Vários mineradores ASIC
Fonte: http://www.indiegogo.com/projects/bitcoin-mining-hardware


Através dos fatores analisados (custo e disponibilidade de hardware, consumo de energia, facilidade de troca em moeda estatal, alta dificuldade de mineração de bitcoins), e, ainda, usando-se GPUs, a litecoin se destaca como a moeda em voga para mineração e rentabilidade quase certa nos dias de hoje, demonstrando estabilidade e alavancagem futura.


3.4. CRIANDO-SE A PRÓPRIA MOEDA

Dar origem a uma moeda ao bel prazer soa muito como uma utopia retirada de um conto fantasioso. Defendendo o lado anti-cryptocoin, o economista Paul Krugman no seu post Bitcoin is Evil [34] cita o posicionamento do escritor de sci-fi Charlie Stross [35]:


To editorialize briefly, BitCoin looks like it was designed as a weapon intended to damage central banking and money issuing banks, with a Libertarian political agenda in mind—to damage states ability to collect tax and monitor their citizens financial transactions. Which is fine if you're a Libertarian, but I tend to take the stance that Libertarianism is like Leninism: a fascinating, internally consistent political theory with some good underlying points that, regrettably, makes prescriptions about how to run human society that can only work if we replace real messy human beings with frictionless spherical humanoids of uniform density (because it relies on simplifying assumptions about human behaviour which are unfortunately wrong).”


Krugman afirma, corroborando com Stross, que o intento da bitcoin parece ser o de destruir o controle estatal e bancário, assemelhando-se a uma política libertarista. Ambos, propositalmente ou não, extrapolam a questão ao deixar de analisar as nuances econômicas e atacando diretamente um posicionamento político. A própria justificativa inicial de Stross é sobre a proibição da troca local de bitcoins na China; ora se vê o embasamento de ambos referenciando a atitude de um país de política aquém da democrática, esta que não se sobressai ao já esperado. Atente-se, ademais, para o fato de o residente chinês não ter sido impossibilitado de negociar bitcoins através da rede peer-to-peer diretamente com outros usuários ou exchanges no exterior.

Bitcoin é open source [36], ou seja, seus criadores não pretenderam torná-la uma [37-38] “moeda criptográfica única”. Após seu surgimento, várias altcoins (alternative coins) foram criadas, baseadas no seu código aberto, como por exemplo a litecoin, a peercoin, e a recente e famosa dogecoin. Haja vista nem todos os aspectos de uma moeda criptográfica agradarem seus usuários/mineradores, modificações a respeito de volume de moedas, algoritmo utilizado para construção do bloco em cadeia, tempo de liberação de novos blocos, dentre outras, são feitas com o intento de se atingir um determinado público. Programar na linguagem C é o mínimo que o aspirante à “cunhagem” deve saber, além de deter conhecimento sobre criptografia, e, dependendo das mudanças pleiteadas, sobre redes peer-to-peer.

De toda sorte, é meritório ressaltar que algumas moedas criptográficas já foram criadas e tiveram uma curta vida, isso devido à pequena aceitação do público ou falta de divulgação necessária. Para se evitar uma morte prematura, o interessado deve pesquisar bastante sobre as principais características econômicas e tecnológicas envolvidas. Ironicamente, o viés social, por vezes imprevisível, pode transformar uma brincadeira como a dogecoin e seus memes [39-40] em um negócio, até o momento, bastante promissor.


REFERÊNCIAS

[1] DAVIES, Roy. A Comparative Chronology of Money - Monetary History from Ancient Times to the Present Day. Disponível em: <http://projects.exeter.ac.uk/RDavies/arian/amser/chrono.html>. Acessado em: jan de 2014.
[2] WIKIPEDIA. Lydia - First coinage. Disponível em: <http://en.wikipedia.org/wiki/Lydia#First_coinage>. Acessado em: jan de 2014.
[3] ASIA MINOR COINS. Kings of Lydia - Asia Minor Coins - Photo Gallery. Disponível em:
<http://www.asiaminorcoins.com/gallery/thumbnails.php?album=431>. Acessado em: jan de 2014.
[4] ALMEIDA, Fábio. A diferença entre preço e valor. O Pequeno Investidor, 2014. Disponível em: <http://www.opequenoinvestidor.com.br/2010/12/a-diferenca-entre-preco-e-valor/>. Acessado em: jan de 2014.
[5] VICECONTI, Paulo E. V.; DAS NEVES, Silvério. Introdução à Economia. 5ª ed. 2002. 267 p.
[6] WIKIPEDIA. Money Creation. Disponível em: <http://en.wikipedia.org/wiki/Money_creation>. Acessado em: jan de 2014.
[7] WIKIPEDIA. Inflation. Disponível em: <http://en.wikipedia.org/wiki/Inflation>. Acessado em: jan de 2014.
[8] JEFFRIES, Adrianne. Four years and $100 million later, Bitcoin’s mysterious creator remains anonymous - We still don't know who invented Bitcoin. But we do know he's rich. 06/05/2013. Disponível em: <http://www.theverge.com/2013/5/6/4295028/report-satoshi-nakamoto>. Acessado em: jan de 2014.
[9] NAKAMOTO, Satoshi. Bitcoin: A Peer-to-Peer Electronic Cash System. 24/05/2009. Disponível em: <http://bitcoin.org/bitcoin.pdf>. Acessado em: jan de 2014.
[10] LEVY, Steven. E-Money (That’s what I want). 12/1994. Disponível em: <http://www.wired.com/wired/archive/2.12/emoney.html>. Acessado em: jan de 2014.
[11] DAI, Wei. b-money, a scheme for a group of untraceable digital pseudonyms to pay each other with money and to enforce contracts amongst themselves without outside help. Disponível em: <http://www.weidai.com/bmoney.txt>. 1998. Acessado em: jan de 2014.
[12] TERRA ECONOMIA. Moeda virtual, cada Bitcoin chega a valer R$ 268 em negócios. 03/06/2013. Disponível em: <http://economia.terra.com.br/operacoes-cambiais/operacoes-empresariais/moeda-virtual-cada-bitcoin-chega-a-valer-r-268-em-negocios,3a1dac07bfafe310VgnVCM10000098cceb0aRCRD.html>. Acessado em: jan de 2014.
[13] O'BRIEN, Matthew. Bitcoin Is No Longer a Currency - It's the ultimate dotcom stock. 11/04/2013. Disponível em: <http://www.theatlantic.com/business/archive/2013/04/bitcoin-is-no-longer-a-currency/274859/>. Acessado em: jan de 2014.
[14] FORBES, Steve. Bitcoin: Whatever It Is, It's Not Money! 16/04/2013. Disponível em: <http://www.forbes.com/sites/steveforbes/2013/04/16/bitcoin-whatever-it-is-its-not-money/>. Acessado em: jan de 2014.
[15] BRADBURY, Danny. Bitcoin Could be Regulated as a Commodity, Senate Banking Hearing Advised. 19/11/2013. Disponível em: <http://www.coindesk.com/bitcoin-regulated-commodity-banking-hearing-advised/>. Acessado em: jan de 2014.
[16] WILLIAMS-GRUT, Oscar. GoldMoney Group adds Bitcoin to commodity vault. 13/01/2014. Disponível em: <http://www.independent.co.uk/news/business/news/goldmoney-group-adds-bitcoin-to-commodity-vault-9055414.html>. Acessado em: jan de 2014.
[17] HENRIK, Rodrigo. CoinMap. Número de locais físicos que aceitam Bitcoin aumenta 81%. 02/12/2013. Disponível em: <http://bestbitcoin.com.br/coinmap-numero-de-locais-fisicos-que-aceitam-bitcoin-aumenta-81-por-cento/>. Acessado em: jan de 2014.
[18] COMPUTERWORLD. Bitcoin pode ser usado para transações privadas, diz governo alemão. 19/08/2013. Disponível em: <http://www.computerworld.com.pt/2013/08/19/bitcoin-pode-ser-usado-para-transacoes-privadas-diz-governo-alemao/>. Acessado em: jan de 2014.
[19] WIKIPEDIA. Febre do ouro. Disponível em: <http://pt.wikipedia.org/wiki/Febre_do_ouro>. Acessado em: jan de 2014.
[20] WIKIPEDIA. Commodity. Disponível em: <http://pt.wikipedia.org/wiki/Commodity>. Acessado em: jan de 2014.
[21] RESENDE, Daniel; AGUSTINI, Gabriela. Moeda digital com lastro em bits já circula fora da internet. 28/03/2013. Disponível em: <http://www.comparacaodefundos.com/blog/moeda-digital-com-lastro-em-bits-ja-circula-fora-da-internet/>. Acessado em: jan de 2014.
[22] EMANSIPATER. What exactly is Mining? Stack Exchange, Bitcoin. 08/09/2011. Disponível em: <http://bitcoin.stackexchange.com/questions/148/what-exactly-is-mining>. Acessado em: jan de 2014.
[23] DENG, Chao. China proíbe compra de bitcoins e derruba preço da moeda virtual. 19/12/2013. Disponível em: <http://online.wsj.com/news/articles/SB10001424052702304866904579266710645195076>. Acessado em: jan de 2014.
[24] DUARTE, Hélter. Bairro de Fortaleza cria moeda própria e enriquece. 21/03/2009. Disponível em: <http://g1.globo.com/globoreporter/0,,MUL1052010-16619,00-BAIRRO+DE+FORTALEZA+CRIA+MOEDA+PROPRIA+E+ENRIQUECE.html>. Acessado em: jan de 2014.
[25] WIKIPEDIA. Local Currency. Disponível em: <http://en.wikipedia.org/wiki/Local_currency>. Acessado em: jan de 2014.
[26] CLARK, Chris. Bitcoin Internals: A Technical Guide to Bitcoin. 22/11/2013. Amazon Digital Services.
[27] ROIO, Denis. Bitcoin, the end of the Taboo on Money. Versão 1.0, 06/04/2013. Disponível em: <https://files.dyne.org/.xsend.php?file=readers/Bitcoin_end_of_taboo_on_money.pdf> Acessado em: jan de 2014.
[28] WIKIPEDIA. Scrypt. Disponível em: <http://en.wikipedia.org/wiki/Scrypt>. Acessado em: jan de 2014.
[29] WIKIPEDIA. Secure Hash Algorithm. Disponível em: <http://en.wikipedia.org/wiki/Secure_Hash_Algorithm>. Acessado em: jan de 2014.
[30] WIKIPEDIA. Application-specific integrated circuit. Disponível em: <http://en.wikipedia.org/wiki/Application-specific_integrated_circuit>. Acessado em: jan de 2014.
[31] BITCOIN WIKI. Bitcoin Difficulty. Disponível em: <https://en.bitcoin.it/wiki/Difficulty>. Acessado em: jan de 2014.
[32] LITECOIN WIKI. Litecoin Difficulty. Disponível em: <https://litecoin.info/Difficulty>. Acessado em: jan de 2014.
[33] TAYLOR, Michael Bedford. Bitcoin and The Age of Bespoke Silicon. Disponível em: <http://cseweb.ucsd.edu/~mbtaylor/papers/bitcoin_taylor_cases_2013.pdf>. Acessado em: jan de 2014.
[34] KRUGMAN, Paul. Bitcoin is Evil. 28/12/2013. Disponível em: <http://krugman.blogs.nytimes.com/2013/12/28/bitcoin-is-evil/>. Acessado em: jan de 2014.
[35] STROSS, Charlie. Why I want Bitcoin to die in a fire. 18/12/2013. Disponível em: <http://www.antipope.org/charlie/blog-static/2013/12/why-i-want-bitcoin-to-die-in-a.html>. Acessado em: jan de 2014.
[36] GITHUB. Bitcoin Source Code in Github. Disponível em: <https://github.com/bitcoin/bitcoin>. Acessado em: jan de 2014.
[37] HERN, Alex. Bitcoin me: How to make your own digital currency. 07/01/2014. Disponível em: <http://www.theguardian.com/technology/2014/jan/07/bitcoin-me-how-to-make-your-own-digital-currency>. Acessado em: jan de 2014.
[38] COHEN, Reuven. Bitcoin Mania: How To Create Your Very Own Crypto-Currency, For Free. 29/11/2013. Disponível em: <http://www.forbes.com/sites/reuvencohen/2013/11/29/bitcoin-mania-how-to-create-your-very-own-crypto-currency-for-free/>. Acessado em: jan de 2014.
[39] SILVA, Juliana. Dogecoin supera Bitcoin e se torna a moeda virtual com mais transações - InfoMoney. 17/01/2014. Disponível em: <http://www.infomoney.com.br/minhas-financas/gadgets/noticia/3150198/dogecoin-supera-bitcoin-torna-moeda-virtual-com-mais-transacoes>. Acessado em: jan de 2014.
[40] WEISENTHAL, Joe. The 'Joke' Digital Currency Dogecoin Is Actually A Really Big Deal. 27/12/2013. Disponível em: <http://www.businessinsider.com/dogecoin-is-a-big-deal-2013-12>. Acessado em: jan de 2014.

Mining cryptocoins (Minerando moedas criptográficas) - Será?

E o Brasil acordou para as moedas criptográficas. A demanda interna por produtos para confecção de rigs está grande (riser cables, rig frames, rigs completos).



Aproveitando esse despertar, estamos ofertando os produtos e serviços relacionados:

GPU R9 290 4GB 512bit

Cabo (riser) 1x -> 16x com MOLEX

Cabo (riser) 1x -> 16x

Cabo (riser) 16x

Dogecoins


o/



terça-feira, 7 de janeiro de 2014

[AnchisesLandia] Mais de 500 Profissionais de Segurança no Twitter

Compartilho com vocês uma bela lista, elaborada pelo colega Anchises, com os profissionais e afins da área de Segurança (estende-se a várias especialidades). E aproveito para agradecer a esse grande hacker pela inclusão de meu nome (fato que só percebi hoje - /o\ shame), mesmo eu sendo apenas um curioso a respeito de computadores. :-)

Mais de 500 Profissionais de Segurança no Twitter

o/

segunda-feira, 28 de outubro de 2013

"It works" mantra

Hi there,

I would like to share with you this Coverity post (Andy) that, somehow, I have instigated through discussion in lkml. Andy's argument corroborates with mine, which concerns the deceptive "it works" mantra.

Code isn't only a piece that makes things happen. It's really a piece of art that demands clarity for whomever read it.

o/

sexta-feira, 7 de junho de 2013

(Un)building Software - English Version

“Reverse engineering is the process of extracting the knowledge or design blueprints from anything man-made. Software is one of the most complex and intriguing technologies around us nowadays, and software reverse engineering is about opening up a program’s 'box' and looking inside. Of course, we won’t need any screwdrivers on this journey. Just like software engineering, software reverse engineering is a purely virtual process, involving only a CPU, and the human mind” Reversing – Secrets of Reverse Engineering – Eldad Eilam

Before we get involved with reversing itself it's important to learn how the binary software assembling really works.

For its construction, it is necessary (unless you are masochistic and want to build machine code directly) a programming language. This translates as a standardized method to inform instruction to a processor. Each language has its own standardization as well as their level of abstraction (low, medium and high). 

Following, are highlighted the procedures demanded for the transformation of the written code in a block of statements "understandable" by the computer.


Software assembling

The construction or compilation is a multistage process that involves various tools. In our case, the tools used will be the front-end of gcc (GNU Compiler), the cc1 (C Compiler)the as (GNU Assembler), the collect2 (ld wrapper), and ld (GNU Linker). The complete set of tools used in the process of compilation is called toolchain, which is already installed on GNU / Linux most of time. The creation of specific toolchains are essential for cross-compiling but this subject is for a future post. 

While invoking GCC the sequence of commands executed obey the following stages:

- pre-processing (macro expansion)
- compilation (source code to assembly language)
- assembler (assembly language into machine code)
- linking (creating the final binary)



Let us create as example a minimalist program in C with the famous Hello World routine.

# mkdir construindo; cd construindo
# echo -e "#include <stdio.h>\nint main() { printf(\"Hello World\\\n\"); return 0;}" > programa1.c

To this compilation we will use gcc.

# gcc programa1.c -o programa1

While running gcc the preprocessing, compilation, assembly and linking steps are performed one after another in a transparent manner until the ELF binary 'programa1' is finally created.

# ./programa1
Hello World

Then, for better understanding, we will cover each phase manually. 


Preprocessing and Compilation

Preprocessing

In past versions of gcc, preprocessing was done as a separate stage through cpp (C preprocessor):

# cpp programa1.c -o programa1.i

The output was a file with expanded macros and declared header files included. The preprocessor, in fact, translate the average abstraction of C language (that we programmed) to another one to be recognizable by the next stage of the build.

# 1 "programa1.c"
# 1 "<command-line>"
# 1 "programa1.c"
# 1 "/usr/include/stdio.h" 1 3 4
# 28 "/usr/include/stdio.h" 3 4
# 1 "/usr/include/features.h" 1 3 4
...
extern void funlockfile (FILE *__stream) __attribute__ ((__nothrow__ , __leaf__$
# 940 "/usr/include/stdio.h" 3 4
# 2 "programa1.c" 2
int main(void) { printf("Hello World\n"); return 0;}

This first stage is currently embedded by cc1 compiler when used with default options, ie, it is usually omitted.

# gcc programa1.c -o programa1 -v
...
 /usr/lib/gcc/x86_64-linux-gnu/4.7/cc1 -quiet -v -imultiarch x86_64-linux-gnu programa1.c -quiet -dumpbase programa1.c -mtune=generic -march=x86-64 -auxbase programa1 -version -fstack-protector -o /tmp/ccZvPRPS.s
...

As can be seen in verbose mode the cc1 performs preprocessing and compilation generating the assembly file directly. We can make the cc1 be invoked twice, with the use of -no-integrated-cpp option primarily for preprocessing, generating the expanded file (*. I) and then to compile, generating mounting file (*. s). This proceeding is useful when you want to use a preprocessor alternative.

# gcc programa1.c -o programa1 -v -no-integrated-cpp
...
 /usr/lib/gcc/x86_64-linux-gnu/4.7/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu programa1.c -mtune=generic -march=x86-64 -fstack-protector -o /tmp/ccjNwBsL.i
...
 /usr/lib/gcc/x86_64-linux-gnu/4.7/cc1 -fpreprocessed /tmp/ccjNwBsL.i -quiet -dumpbase programa1.c -mtune=generic -march=x86-64 -auxbase programa1 -version -fstack-protector -o /tmp/cc0B4fmf.s
...

We may also interrupt the process of gcc, invoking cc1 only once with the intention of you generate the file (*. I) preprocessed.

# gcc programa1.c -o programa1.i  -v -E
...
 /usr/lib/gcc/x86_64-linux-gnu/4.7/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu programa1.c -o programa1.i -mtune=generic -march=x86-64 -fstack-protector
...

To do this we use the option '-E'.


Compilation

The main purpose of using cc1 through the expanded file or not (programa1.i) is generate its respective assembly code, low-level language.

# gcc programa1.i -o programa1.s -v -S
...
 /usr/lib/gcc/x86_64-linux-gnu/4.7/cc1 -fpreprocessed programa1.i -quiet -dumpbase programa1.i -mtune=generic -march=x86-64 -auxbase-strip programa1.s -version -o programa1.s -fstack-protector
...

# gcc programa1.c -o programa1.s -v -S
...
 /usr/lib/gcc/x86_64-linux-gnu/4.7/cc1 -quiet -v -imultiarch x86_64-linux-gnu programa1.c -quiet -dumpbase programa1.c -mtune=generic -march=x86-64 -auxbase-strip programa1.s -version -o programa1.s -fstack-protector
...

The option '-S' instructs gcc to only convert the C code, preprocessed or not, to assembly language (programa1.s).

.file "programa1.c"
.section .rodata
.LC0:
.string "Hello World"
.text
.globl main
.type main, @function
main:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
movl $.LC0, %edi
call puts
movl $0, %eax
popq %rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size main, .-main
.ident "GCC: (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2"
.section .note.GNU-stack,"",@progbits

Attention! The assembly code generated may be different on your computer. This discrepancy may have been caused by several reasons: gcc version; architecture used; compilation flags.

To generate the corresponding code in 32-bit, just use the-m32.

# gcc programa1.i -S -m32

or

# gcc programa1.c -S -m32

See the difference:

.LFB0:
.cfi_startproc
pushl %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl %esp, %ebp
.cfi_def_cfa_register 5
andl $-16, %esp
subl $16, %esp
movl $.LC0, (%esp)call puts
movl $0, %eax
leave
.cfi_restore 5
cfi_def_cfa 4, 4ret
.cfi_endproc


Assembler

In assembly the code is converted into their related instructions into machine code. The result is an object file (object file).

# gcc programa1.s -o programa1.o -v -c
...
 as -v --64 -o programa1.o programa1.s
...

# gcc -c programa1.s -o programa1.o -v -m32 -c
...
 as -v --32 -o programa1.o programa1.s
...

The '-c' option tell the gcc to compile only or just mount the source file, skipping the linking process.

As seen above, the "as" assembles the binary using the assembly file(programa1.s). When we run the file against the constructed object-file we can see the ELF structure.

# file programa1.o
programa1.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped

programa1.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

However as the build process has not been finished, when we try to run it we get the message that it is impossible to run the binary file. By using ltrace (analysis tool called the libraries) we get the message "./programa1.o is not an ELF executable nor shared library". The assembler built a block of binary instructions for the architecture but not defined the addresses related to the external functions and consequently not relocated the binary to the correct execution.


Linking

Until then the object file assembled do not know where to look (the address of the functions necessary for the correct functioning). The Linking is, in this case, the process of agglutination of the object files, symbol resolution and relocation of the sections and their addresses in binary once generated.

Let's see.

# gcc programa1.o -o programa1 -v
...
 /usr/lib/gcc/x86_64-linux-gnu/4.7/collect2 --sysroot=/ --build-id --no-add-needed --as-needed --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro -o programa1 /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.7/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.7 -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../.. programa1.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.7/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crtn.o
...

or

# gcc programa1.o -o programa1 -v -m32
...
 /usr/lib/gcc/x86_64-linux-gnu/4.7/collect2 --sysroot=/ --build-id --no-add-needed --as-needed --eh-frame-hdr -m elf_i386 --hash-style=gnu -dynamic-linker /lib/ld-linux.so.2 -z relro -o programa1 /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib32/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib32/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.7/32/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.7/32 -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../i386-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib32 -L/lib/i386-linux-gnu -L/lib/../lib32 -L/usr/lib/i386-linux-gnu -L/usr/lib/../lib32 -L/usr/lib/gcc/x86_64-linux-gnu/4.7 -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../i386-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../.. -L/lib/i386-linux-gnu -L/usr/lib/i386-linux-gnu programa1.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.7/32/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib32/crtn.o
...

What gcc actually does is invoke collect2 (wrapper for the ld (binutils)) stating all the object files to be linked. 

It is true that ld can be used directly, of all sorts, the gcc/collect2 now informs all libs needed for linking, which makes it much easier


After the process is finished, you can verify that the executable is properly linked.

# file programa1
programa1: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xa0c...bf73, not stripped

programa1: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xe07...8df3, not stripped

And finally run it.

# ./programa1
Hello World


Conclusion

We were able, in this post, to follow briefly the process of building an ELF executable, exemplifying their procedures in GNU / Linux using GCC. Next, we will begin a practical approach of reverse engineering that will enable an understanding of the ELF structure as well as the method and tools used in reversing.

See you there!

Translated by: Pedro Fausto

More Information

Reversing – Secrets of Reverse Engineering – Eldad Eilam
Reverse Engineering
A Introduction to GCC – Brian Gough
Compiler, Assembler, Linker and Loader: A Brief Story
Basics of GCC compilation process
GNU C Compiler Internals/GNU C Compiler Architecture
GCC front-end Whitepaper - Andi Hellmund
Programming language
List of programming languages by type
C (programming language)
Low-level programming language
Assembly Language
Machine code

quinta-feira, 6 de junho de 2013

(Des)construindo Software - Parte 2

Ao finalizar o primeiro post, disse-lhes que neste iniciaríamos uma abordagem prática da engenharia reversa que possibilitaria um entendimento objetivo da estrutura ELF. Contudo, optei por inverter essa ordem, sendo que agora daremos início diretamente pelo ELF, a despeito de que a análise da sua estrutura, mesmo que realizada minimamente, em si já é um meio de reversão, e, somente empós, fá-la-emos propriamente lidando com o respectivo binário.

Preciso também fazer menção às correções que efetuei no primeiro post da sequência. Graças ao Ygor Parreira (valeu, dmr!), identifiquei informações desatualizadas na descrição do processo de compilação. Por isso, para que não haja prejuízo no estudo, a releitura se faz obrigatória.

Os arquivos deste post estão disponíveis no GitHub.


ELF (Pointed Ears)

O ELF (Executable and Linking Format) é um formato (estrutura) que especifica a composição e organização de um arquivo-objeto (representação binária, resultado do procedimento de montagem) para que este seja funcional ao sistema operacional que o utiliza; é, em miúdos, um mapa que permite a criação/utilização correta, através dos linker e loader, dos arquivos com esse padrão.

Originalmente desenvolvido e publicado pelos USL (UNIX System Laboratories) como parte da ABI, o ELF se tornou padrão em vários sistemas operacionais Unix-like, substituindo formatos antigos como a.out e COFF. Hoje em dia é utilizado também em sistemas operacionais não-Unix como OpenVMS, BeOS e Haiku, assim como em videogames, celulares, tablets, roteadores, televisões etc.

No tocante à introdução (pg. 45) do System V - Application Binary Interface (ABI), Ed. 4.1 (documento que descreve a interface entre o programa e o sistema operacional ou outro programa), faço uma ressalva à afirmação "o arquivo-objeto é criado pelo assembler 'e' link editor", pois, contrariedade a essa regra foi demonstrada na criação do crackme.03, ao ser desprezada a lincagem. De toda sorte, num processo normal de compilação é correto se dizer que o procedimento de lincagem estará presente.


Tipos de ELF (Middle-Earth, D&D, ...)

Discorramos um pouco sobre os tipos mais comuns de arquivos-objeto ELF.



Relocável

O arquivo-objeto relocável possui código e dados prontos para a combinação com outros arquivos-objeto, que comporão um executável ou um objeto compartilhado.

Vejamos abaixo o programa1.o.

gcc programa1.c -m32 -c

# file programa1.o
programa1.o: ELF 32-bit LSB  relocatable, Intel 80386, version 1 (SYSV), not stripped

# readelf-h programa1.o | grep Type
  Type:                              REL (Relocatable file)

# readelf -r programa1.o 
Relocation section '.rel.text' at offset 0x3ec contains 2 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
0000000c  00000501 R_386_32          00000000   .rodata
00000011  00000a02 R_386_PC32        00000000   puts

Relocation section '.rel.eh_frame' at offset 0x3fc contains 1 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00000020  00000202 R_386_PC32        00000000   .text

Nesse primeiro exemplo, o gcc compilou e montou o binário relocável programa1.o que ainda não teve os endereços para execução informados em sua estrutura (ELF), assim como também não teve resolvidas as referências de símbolos.

Com o readelf constatamos que os endereços não foram definidos.

# readelf -S programa1.o 
There are 13 section headers, starting at offset 0x11c:

Section Headers:
  [Nr] Name          Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]               NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text         PROGBITS        00000000 000034 00001c 00  AX  0   0  4
  [ 2] .rel.text     REL             00000000 0003ec 000010 08     11   1  4
  [ 3] .data         PROGBITS        00000000 000050 000000 00  WA  0   0  4
  [ 4] .bss          NOBITS          00000000 000050 000000 00  WA  0   0  4
  [ 5] .rodata       PROGBITS        00000000 000050 00000c 00   A  0   0  1
...

E através do nm temos a lista de todos os símbolos; a serem resolvidos.

# nm -a programa1.o
00000000 b .bss
...
00000000 d .data
...
00000000 t .text
00000000 T main
...

Segue outro exemplo utilizando o relocável programa2.o (versão em assembly do programa1).

nasm -f elf32 programa2.asm

# readelf -r programa2.o 
Relocation section '.rel.text' at offset 0x260 contains 1 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
0000000b  00000201 R_386_32          00000000   .data


Executável

Este tipo de arquivo-objeto contém as informações necessárias à criação de sua respectiva imagem de processo por meio da função (syscall) exec.

Continuemos com o programa1.

# gcc programa1.c -m32 -o programa1
# ./programa1
Hello World

# file programa1
programa1: ELF 32-bit LSB  executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=df0b281079aace57fec72570a37ba345c7679a59, not stripped

# readelf -S programa1
There are 30 section headers, starting at offset 0x7f0:

Section Headers:

  [Nr] Name           Type           Addr     Off    Size   ES Flg Lk Inf Al
...
  [12] .plt           PROGBITS       080482c0 0002c0 000040 04  AX  0   0 16
  [13] .text          PROGBITS       08048300 000300 000194 00  AX  0   0 16
  [14] .fini          PROGBITS       08048494 000494 000014 00  AX  0   0  4
  [15] .rodata        PROGBITS       080484a8 0004a8 000014 00   A  0   0  4
...

Pode ser visto acima que o arquivo-objeto do tipo executável teve sua estrutura relocada.

Podemos confirmar isso, também, através do cabeçalho ELF. Vejam que o objeto relocável não possui endereço de entrada.

# readelf -h programa1.o | grep Entry
  Entry point address:               0x0

Porém, possui quando executável.

# readelf -h programa1 | grep Entry
  Entry point address:               0x8048300

No programa1, a lincagem (collect2) amarrou (symbol binding) as referências locais e as concernentes às bibliotecas dinâmicas, e relocou as estruturas de dados, prontificando o arquivo-objeto à execução.

Escrutinemos mais ainda com a tool ldd que nos lista as bibliotecas compartilhadas necessárias ao executável.

# ldd programa1
linux-gate.so.1 (0xf76ea000)
libc.so.6 => /usr/lib32/libc.so.6 (0xf751b000)
/lib/ld-linux.so.2 (0xf76eb000)

Vemos acima que o programa1.c faz uso da biblioteca compartilhada libc (função printf).

O programa2 (assembly), entretanto, tem suas peculiaridades.

ld -m elf_i386 programa2.o -o programa2
./programa2 
Hello World

# readelf -r programa2
There are no relocations in this file.

# file programa2
programa2: ELF 32-bit LSB  executable, Intel 80386, version 1 (SYSV), statically linked, not stripped

# ldd programa2
not a dynamic executable

O ldd não apresenta nenhuma biblioteca compartilhada, uma vez que o programa2 só faz uso de syscalls. Tal fato denota que não foi necessário se efetuar a combinação com outros arquivos-objeto, restando apenas perfazer os demais procedimentos como a resolução das referências de símbolos locais e a relocação. É importante destacar que o programa1, diferentemente do programa2, será também lincado dinamicamente a cada nova instanciação, por conta de seus símbolos indefinidos.


Objeto Compartilhado

Este arquivo-objeto detém código e dados apropriados para duas situações de lincagem.


Objeto compartilhado combinado com outro objeto compartilhado e/ou com relocável.

Inicialmente, engendremos o arquivo-objeto compartilhado libfoo1.so.

# gcc -c -fPIC -m32 foo1.c -o foo1.o
# readelf -h foo1.o  | grep Type
  Type:                              REL (Relocatable file)

# gcc -shared -m32 -o libfoo1.so foo1.o
# readelf -h libfoo1.so | grep Type
  Type:                              DYN (Shared object file)

Veja abaixo a criação a partir da combinação do arquivo-objeto compartilhado libfoo1.so com o relocável foo2.o.

# gcc -c -fPIC -m32 foo2.c -o foo2.o
# gcc -shared -m32 -o libfoo2.so foo2.o libfoo1.so
# readelf -h libfoo2.so | grep Type
  Type:                              DYN (Shared object file)

E finalmente a combinação dos dois objetos compartilhados, libfoo2.so e libfoo1.so.

# gcc -shared -m32 -o libfoo3.so libfoo2.so libfoo1.so
# readelf -h libfoo3.so | grep Type
  Type:                              DYN (Shared object file)


Combinado com um executável ou com outro objeto compartilhado para criação da imagem do processo pelo dynamic linker.

Este é o caso do nosso programa1 que ao ser executado é combinado, previamente a sua inicialização, com os demais arquivos-objeto compartilhados, através da ld-linux.so. Isso também ocorre com as próprias bibliotecas compartilhadas ao serem carregadas pelo sistema.


Core Dump

Um core dump (memory dump, system dump) é um arquivo-objeto contendo o estado da memória de um determinado programa, produzido pelo sistema geralmente quando aquele termina anormalmente (crashed).

Vejamos, como usuário root.

# gcc -m32 coredump.c -o coredump

# ulimit -c
0
# ulimit -c unlimited
# ulimit -c

unlimited

# ./coredump
Falha de segmentação (imagem do núcleo gravada)

Geralmente, o dump é salvo na pasta atual com o nome de core. A localização e formato do nome do dump podem ser modificados no arquivo /proc/sys/kernel/core_pattern. Mais informações: man core.

# file core
core: ELF 32-bit LSB  core file Intel 80386, version 1 (SYSV), SVR4-style, from './coredump'

Se estiverem utilizando Arch Linux, como foi o meu caso, faz-se necessário extrair o core dump de um sistema de journaling utilizado pelo systemd.

# systemd-coredumpctl | tail
...
Sex 2013-05-31 07:41:01 BRT    447     0     0  11 /home/uzumaki/git/hb/desconstruindo/coredump

# systemd-coredumpctl dump -o core
TIME                           PID   UID   GID SIG EXE
Sex 2013-05-31 07:41:01 BRT    447     0     0  11 /home/uzumaki/git/hb/desconstruindo/coredump
More than one entry matches, ignoring rest.

# file core
core: ELF 32-bit LSB  core file Intel 80386, version 1 (SYSV), SVR4-style, from './coredump'

Um exemplo de uso do core dump seria com o gdb para se investigar a causa do crash.

# gdb -q ./coredump core
Reading symbols from /home/uzumaki/git/hb/desconstruindo/coredump...(no debugging symbols found)...done.
[New LWP 447]

warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
Core was generated by `./coredump'.
Program terminated with signal 11, Segmentation fault.
#0  0x4c4b4a49 in ?? () 

(gdb) backtrace
#0  0x4c4b4a49 in ?? ()
#1  0x504f4e4d in ?? ()
#2  0x54535251 in ?? ()
#3  0x58575655 in ?? ()
#4  0xf7005a59 in ?? ()
...


Pode ser visto acima que a falha na segmentação ocorreu por conta do overflow dos caracteres.


Estrutura ELF (Crystal Bones, Wood Bones, ...)

O formato ELF provê visões paralelas do conteúdo do binário que refletem as diferentes necessidades ao se lincar e ao se executar um programa. Inicialmente estudaremos a Visão de Lincagem.
 


Na estrutura há apenas um componente com localização fixa, o ELF Header que se encontra no offset zero do arquivo-objeto. Nele são armazenadas as informações que descrevem a organização do restante do arquivo.

A Program header table instrui o sistema como criar uma imagem de processo, portanto é um componente obrigatório nos arquivos-objeto executáveis e nos compartilhados; já os relocáveis não fazem uso dela.

As Sections contemplam a massa de informação do arquivo-objeto utilizada na visão de lincagem, como instruções, dados, tabela de símbolos, informação de relocação, dentre outros.

A Section header table contém informações descritivas das sections do objeto. Nela, para cada section, há uma entrada que fornece dados como nome, tamanho, dentre mais. Na lincagem o arquivo-objeto a ser combinado deve obrigatoriamente conter tal tabela. Outros arquivos-objetos podem ou não a conter.


Tipos de Dados (Not dices)

Seguem os tipos usados para a representação de dados nos arquivo-objetos ELF.


Criei o elfdatatypes para mostrar o tamanho dos tipos em ambas arquiteturas.


ELF Header (Game Master)

Existem dois tipos de ELF header em /usr/include/elf.h: Elf32_Ehdr e Elf64_Ehdr. Seus nomes são contrações em inglês (_Ehdr -> Elf header). ;)

Segue estrutura em C.



Verifiquemos o tamanho do ELF Header do programa1.

# readelf -h programa1 | grep this
  Size of this header:               52 (bytes)

O posicionamento do ELF Header, como já citado, sempre será no offset zero do arquivo-objeto, no entanto seu tamanho dependerá da arquitetura: 32 bits (52 bytes); 64 bits (64 bytes).

Vejamos os 52 bytes relativos ao ELF Header 32.

# xxd -l 52 programa1
0000000: 7f45 4c46 0101 0100 0000 0000 0000 0000  .ELF............
0000010: 0200 0300 0100 0000 0083 0408 3400 0000  ............4...
0000020: f007 0000 0000 0000 3400 2000 0800 2800  ........4. ...(.
0000030: 1e00 1b00                                ....

Em conformidade com a estrutura Elf32_Ehdr, os 16 primeiros bytes são concernentes à identificação do arquivo-objeto (e_ident[16]). Se somarmos o tamanho dos tipos que se seguem (Elf32_Half e_type [2 bytes], Elf32_Half e_machine [2 bytes], Elf32_Word e_version [4 bytes]), chegaremos ao offset 24 que é referente ao entry point (0083 0408).

# readelf -h programa1 | grep Entry
  Entry point address:               0x8048300 (00830408 em ordem inversa)

Antes de finalizarmos, para não ficar nenhum dissabor, vejamos um código em C (elfentry) que lê o valor Entry Point do arquivo-objeto programa2.

# gcc -m32 elfentry.c -o elfentry
# ./elfentry
Entry Point: 0x8048080

# readelf -h programa2 | grep Entry
  Entry point address:               0x8048080


Ficamos por aqui. No próximo encontro, esmiuçaremos a estrutura ElfN_Ehdr.

Até lá!   o/


http://maxpaint.livejournal.com/

Mais Informações

ELF - Wikipedia
Elf (another kind) - Wikipedia
ABI - System V Application Binary Interface - SCO
The ELF Object File Format - Introduction - Linux Journal
The ELF Object File Format by Dissection - Linux Journal
Dissecando ELF - Felipe Pena
Linker (computing) - Wikipedia
Relocation (computing) - Wikipedia
Loader (computing)
Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Brazil License.