ELF Hello World Tutorial / Global file structure by Ciro Santilli 37 Updated 2025-06-02 +Created 1970-01-01
View more
An ELF file contains the following parts:
  • ELF header. Points to the position of the section header table and the program header table.
  • Section header table (optional on executable). Each has e_shnum section headers, each pointing to the position of a section.
  • N sections, with N <= e_shnum (optional on executable)
  • Program header table (only on executable). Each has e_phnum program headers, each pointing to the position of a segment.
  • N segments, with N <= e_phnum (only on executable)
The order of those parts is not fixed: the only fixed thing is the ELF header that must be the first thing on the file: Generic docs say:
Although the figure shows the program header table immediately after the ELF header, and the section header table following the sections, actual files may differ. Moreover, sections and segments have no specified order. Only the ELF header has a fixed position in the file.
In pictures: sample object file with three sections:
            +-------------------+
            | ELF header        |---+
+---------> +-------------------+   | e_shoff
|           |                   |<--+
| Section   | Section header 0  |
|           |                   |---+ sh_offset
| Header    +-------------------+   |
|           | Section header 1  |---|--+ sh_offset
| Table     +-------------------+   |  |
|           | Section header 2  |---|--|--+
+---------> +-------------------+   |  |  |
            | Section 0         |<--+  |  |
            +-------------------+      |  | sh_offset
            | Section 1         |<-----+  |
            +-------------------+         |
            | Section 2         |<--------+
            +-------------------+
But nothing (except sanity) prevents the following topology:
            +-------------------+
            | ELF header        |---+ e_shoff
            +-------------------+   |
            | Section 1         |<--|--+
+---------> +-------------------+   |  |
|           |                   |<--+  | sh_offset
| Section   | Section header 0  |      |
|           |                   |------|---------+
| Header    +-------------------+      |         |
|           | Section header 1  |------+         |
| Table     +-------------------+                |
|           | Section header 2  |---+            | sh_offset
+---------> +-------------------+   | sh_offset  |
            | Section 2         |<--+            |
            +-------------------+                |
            | Section 0         |<---------------+
            +-------------------+
But some newbies may prefer PNGs :-)
Figure 1.
ELF Executable and Linkable Format diagram by Ange Albertini
. Source.
Read the full article
ELF Hello World Tutorial / Program header table by Ciro Santilli 37 Updated 2025-06-02 +Created 1970-01-01
View more
Only appears in the executable.
Contains information of how the executable should be put into the process virtual memory.
The executable is generated from object files by the linker. The main jobs that the linker does are:
  • determine which sections of the object files will go into which segments of the executable.
    In Binutils, this comes down to parsing a linker script, and dealing with a bunch of defaults.
    You can get the linker script used with ld --verbose, and set a custom one with ld -T.
  • do relocation according to the .rela.text section. This depends on how the multiple sections are put into memory.
readelf -l hello_world.out gives:
Elf file type is EXEC (Executable file)
Entry point 0x4000b0
There are 2 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x00000000000000d7 0x00000000000000d7  R E    200000
  LOAD           0x00000000000000d8 0x00000000006000d8 0x00000000006000d8
                 0x000000000000000d 0x000000000000000d  RW     200000

 Section to Segment mapping:
  Segment Sections...
   00     .text
   01     .data
On the ELF header, e_phoff, e_phnum and e_phentsize told us that there are 2 program headers, which start at 0x40 and are 0x38 bytes long each, so they are:
00000040  01 00 00 00 05 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 40 00 00 00 00 00  00 00 40 00 00 00 00 00  |..@.......@.....|
00000060  d7 00 00 00 00 00 00 00  d7 00 00 00 00 00 00 00  |................|
00000070  00 00 20 00 00 00 00 00                           |.. .....        |
and:
00000070                           01 00 00 00 06 00 00 00  |        ........|
00000080  d8 00 00 00 00 00 00 00  d8 00 60 00 00 00 00 00  |..........`.....|
00000090  d8 00 60 00 00 00 00 00  0d 00 00 00 00 00 00 00  |..`.............|
000000a0  0d 00 00 00 00 00 00 00  00 00 20 00 00 00 00 00  |.......... .....|
Structure represented www.sco.com/developers/gabi/2003-12-17/ch5.pheader.html:
typedef struct {
    Elf64_Word  p_type;
    Elf64_Word  p_flags;
    Elf64_Off   p_offset;
    Elf64_Addr  p_vaddr;
    Elf64_Addr  p_paddr;
    Elf64_Xword p_filesz;
    Elf64_Xword p_memsz;
    Elf64_Xword p_align;
} Elf64_Phdr;
Breakdown of the first one:
  • 40 0: p_type = 01 00 00 00 = PT_LOAD: this is a regular segment that will get loaded in memory.
  • 40 4: p_flags = 05 00 00 00 = execute and read permissions. No write: we cannot modify the text segment. A classic way to do this in C is with string literals: stackoverflow.com/a/30662565/895245 This allows kernels to do certain optimizations, like sharing the segment amongst processes.
  • 40 8: p_offset = 8x 00 TODO: what is this? Standard says:
    This member gives the offset from the beginning of the file at which the first byte of the segment resides.
    But it looks like offsets from the beginning of segments, not file?
  • 50 0: p_vaddr = 00 00 40 00 00 00 00 00: initial virtual memory address to load this segment to
  • 50 8: p_paddr = 00 00 40 00 00 00 00 00: unspecified effect. Intended for systems in which physical addressing matters. TODO example?
  • 60 0: p_filesz = d7 00 00 00 00 00 00 00: size that the segment occupies in memory. If smaller than p_memsz, the OS fills it with zeroes to fit when loading the program. This is how BSS data is implemented to save space on executable files. i368 ABI says on PT_LOAD:
    The bytes from the file are mapped to the beginning of the memory segment. If the segment’s memory size (p_memsz) is larger than the file size (p_filesz), the ‘‘extra’’ bytes are defined to hold the value 0 and to follow the segment’s initialized area. The file size may not be larger than the memory size.
  • 60 8: p_memsz = d7 00 00 00 00 00 00 00: size that the segment occupies in memory
  • 70 0: p_align = 00 00 20 00 00 00 00 00: 0 or 1 mean no alignment required. TODO why is this required? Why not just use p_addr directly, and get that right? Docs also say:
    p_vaddr should equal p_offset, modulo p_align
The second segment (.data) is analogous. TODO: why use offset 0x0000d8 and address 0x00000000006000d8? Why not just use 0 and 0x00000000006000d8?
Then the:
 Section to Segment mapping:
section of the readelf tells us that:
  • 0 is the .text segment. Aha, so this is why it is executable, and not writable
  • 1 is the .data segment.
Read the full article
Positron by Ciro Santilli 37 Updated 2025-06-02 +Created 1970-01-01
Read the full article
E. Coli genome starting point by Ciro Santilli 37 Updated 2025-06-02 +Created 1970-01-01
View more
The conventional starting point is not at the E. Coli K-12 MG1655 origin of replication.
biocyc.org/ECOLI/NEW-IMAGE?type=EXTRAGENIC-SITE&object=G0-10506 explains:
This site is the origin of replication of the E. coli chromosome. It contains the binding sites for DnaA, which is critical for initiation of replication. Replication proceeds bidirectionally. For historical reasons, the numbering of E. coli's circular chromosome does not start at the origin of replication, but at the origin of transfer during conjugation.
If it is a bit hard to understand what they mean by "origin of transfer" though, as that term is usually associated with the origin of transfer of bacterial conjugation.
Read the full article
Magnetoresistive disk head by Ciro Santilli 37 Updated 2025-06-02 +Created 1970-01-01
Read the full article
English as a universal language by Dan Dascalescu (2008) by Ciro Santilli 37 Updated 2025-06-02 +Created 1970-01-01
View more
Read the full article
Cool data embedded in the Bitcoin blockchain / Custom encoded images of unknown source by Ciro Santilli 37 Updated 2025-06-02 +Created 1970-01-01
View more
Figure 1.
bitcoin.jpg
. Source.
A bitcoin logo on block 123573 (2011-05-13).
This is the very first ASCII string to show up at github.com/cirosantilli/bitcoin-inscription-indexer after only the Genesis block message.
Reconstructing it should likely be a simple matter of copy pasting the ASCII yEnc encoding present in the two transactions from tx ceb1a7fb57ef8b75ac59b56dd859d5cb3ab5c31168aa55eb3819cd5ddbd3d806 into a text file and decoding the yEnc, but after searching for 20 minutes Ciro couldn't find a working yEnc decoder on Ubuntu 21.10. How can a format be so dead, even after considerable extensive use in the Usenet??? It makes you think about life.
As mentioned by Ken, the logo is split across two transactions: ceb1a7fb57ef8b75ac59b56dd859d5cb3ab5c31168aa55eb3819cd5ddbd3d806 and 9173744691ac25f3cd94f35d4fc0e0a2b9d1ab17b4fe562acc07660552f95518.
There appears to be nothing strictly linking the two transactions, besides that they are very close by and the only ASCII strings around back in those pre-infinite-spam days, as can be seen at: github.com/cirosantilli/bitcoin-inscription-indexer/blob/master/data/out/0123.txt#L11, so you could just see both of them by eye.
Also the first one starts with:
=ybegin line=128 size=8776 name=bitcoin.jpg
and the second one ends in:
=yend size=8776 crc32=a7ac8449
so this is likely clearly part of the yEnc format for someone who knows it, and the filename bitcoin.jpg gives the file format.
They are not even in the same block:
both from 2011-05-13. Also note that they ended up being committed reverse order, since you don't have a strict order control over the final blockchain.
Figure 2.
v27sSra.jpg
.
An image of a dozen people siting at a dinner table, with each person identified by a Twitter handle that was edited in.
It contains a base 64 encoded image:
v27sSra.jpg

/9j/4AAQSkZJRgABAQEASABIAAD/2wBDACgcHiMeGSgjISMtKygwPGRBPDc3PHtYXUlkkYCZlo+A
...
TAkBaMxbbhuYXGDMyXw/MIV84IqrE//Z
...
By manually copy pasting that into a file v27sSra.base64 we can obtain the image with:
base64 -d <v27sSra.base64 >v27sSra.jpg
The exact same content appears to be present on the next input transaction 56d23a230042c094bc54bb72fc4c10a3f26750030b9927994e741d3689f5c09e on the same block.
Google reverse image search leads to freedom-to-tinker.com/2015/05/21/the-story-behind-the-picture-of-nick-szabo-with-other-bitcoin-researchers-and-developers/ The story behind the picture of Nick Szabo with other Bitcoin researchers and developers by Arvind Narayanan (2015), in which Arvind (@random_walker) who attended the meeting clearly lists all names and handles, and talks about the background of gathering of Bitcoin devs that happened in March 2014. The article also contains a higher resolution version of the image uploaded to the blockchain.
It also links to a popular Reddit thread that contains the image from May 2015: www.reddit.com/r/Bitcoin/comments/36hfu4/pic_coredevs_having_dinner_with_nick_szabo/
Read the full article
Cool data embedded in the Bitcoin blockchain / Marijuana plant by Ciro Santilli 37 Updated 2025-06-02 +Created 1970-01-01
View more
j(-> 1EGa1izEFDHzEobDDQny73re9BwXdzhZvH <-
j(                 ,
j(                dM
j(                MMr
j(               4MMML                  .
j(               MMMMM.                xf
j(              "M6MMM               .MM-
j( h..          +MM5MMM            .MMMM
j( .MM.         .MMMMML.          MMMMMh
j( )MMMh.        MM5MMM         MMMMMMM
j(  3MMMMx.     'MMM3MMf      xnMMMMMM"
j(  '*MMMMM      MMMMMM.     nMMMMMMP"
j(    *MMMMMx    "MMM5M\    .MMMMMMM=
j(     *MMMMMh   "MMMMM"   JMMMMMMP
j(       MMMMMM   GMMMM.  dMMMMMM
j(        MMMMMM  "MMMM  .MMMMM(        .n
j(         *MMMMx  MMM"  dMMMM"    .nnMMMM
j(Mn...     'MMMMr 'MM   MMM"   .nMMMMMMM*
j(4MMMMnn..   *MMM  MM  MMP"  .dMMMMMMM""
j( ^MMMMMMMMx.  *ML "M .M*  .MMMMMM**"
j(    *PMMMMMMhn. *x > M  .MMMM**""
j(       ""**MMMMhx/.h/ .=*"
j(                .3P"%....
j(              nP"     "*MMnx
The transaction before the ASCII art tx 9b08c00ced2bca4525d74e82db9af2aec8ef213eb1c1bf68a48b6be929968332 starts with what is likely a "Legalize" and must be a Tor Onion service:
j(-> 1EGa1izEFDHzEobDDQny73re9BwXdzhZvH <-
but that address as is + .onion is invalid, TODO find the correct one.
Other marijuana plants can be found contained entirely in single transactions:
tx d338da06d13a21a296506c0c8cd8c8533ba8fa076ff5c2c1fd02a457aac3ef77 via cryptograffiti.info contains a marihuana plant followed by a complaint:
[ mirrored by http://dmabraham.info/ | moarrr ]
[ CryptoGraffiti: Donate BTC: 1MVpQJA7FtcDrwKC6zATkZvZcxqma4JixS ]
[ Latest News: EU/Greece chaos due to huge debts! ]
[ Bless! ]

{ Supa - https://bitcoin-otc.com/viewratingdetail.php?nick=supa }
William Robert Girdlestone
1535 Dingwall RD Apt 35
Courtenay
British Columbia
Canada
V9N 3S8

( https://bitcointalk.org/index.php?topic=575743.0 )
[ One of the lowest rated #bitcoin-otc users, owing me at least 10 BTC ]
[ Most likely much more with compounding interesting, but its all ]
[ written off as a huge loss to me. Never again deal with him! ]
Read the full article
NADP+ by Ciro Santilli 37 Updated 2025-06-02 +Created 1970-01-01
Read the full article
Citric acid cycle by Ciro Santilli 37 Updated 2025-06-02 +Created 1970-01-01
View more
Happens in the matrix of the mitochondrion in eukaryotes.
Read the full article
Calcite by Ciro Santilli 37 Updated 2025-06-02 +Created 1970-01-01
Read the full article
Assign the hard task to the lazy person by Ciro Santilli 37 Updated 2025-06-02 +Created 1970-01-01
View more
quoteinvestigator.com/2014/02/26/lazy-job/ (archive):
I will always choose a lazy person to do a difficult job because a lazy person will find an easy way to do it.
Read the full article
Hash table by Ciro Santilli 37 Updated 2025-06-02 +Created 1970-01-01
Read the full article
ARM CPU by Ciro Santilli 37 Updated 2025-06-02 +Created 1970-01-01
Read the full article
Anus by Ciro Santilli 37 Updated 2025-06-02 +Created 1970-01-01
Read the full article
Amazon custom silicon by Ciro Santilli 37 Updated 2025-06-02 +Created 1970-01-01
View more
Like Google custom silicon, Amazon server operations are so large that with the slowdown of Moore's law, it started being worth it for them to develop custom in-house silicon to serve as a competitive advantage, not to be sold for external companies. Can you imagine the scale required to justify silicon development investment that is not sold externally!
Read the full article
Shahidah Cawley by Ciro Santilli 37 Updated 2025-06-02 +Created 1970-01-01
Read the full article
The Internet's Own Boy (2014) by Ciro Santilli 37 Updated 2025-06-02 +Created 1970-01-01
Read the full article
x86 Paging Tutorial by Ciro Santilli 37 Updated 2025-06-02 +Created 1970-01-01
View more
This tutorial explains the very basics of how paging works, with focus on x86, although most high level concepts will also apply to other instruction set architectures, e.g. ARM.
The goals are to:
  • demonstrate minimal concrete simplified paging examples that will be useful to those learning paging for the first time
  • explain the motivation behind paging
This tutorial was extracted and expanded from this Stack Overflow answer.
Read the full article
webpack/sass by Ciro Santilli 37 Updated 2025-06-02 +Created 1970-01-01
Read the full article

Unlisted articles are being shown, click here to show only listed articles.