New articles - OurBigBook.com

Ciro Santilli  40 Updated 2025-07-16

.data is section 1:

00000080  01 00 00 00 01 00 00 00  03 00 00 00 00 00 00 00  |................|
00000090  00 00 00 00 00 00 00 00  00 02 00 00 00 00 00 00  |................|
000000a0  0d 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000b0  04 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

80 0: sh_name = 01 00 00 00: index 1 in the .shstrtab string table
Here, 1 says the name of this section starts at the first character of that section, and ends at the first NUL character, making up the string .data.
.data is one of the section names which has a predefined meaning according to www.sco.com/developers/gabi/2003-12-17/ch4.strtab.html:
These sections hold initialized data that contribute to the program's memory image.

80 4: sh_type = 01 00 00 00: SHT_PROGBITS: the section content is not specified by ELF, only by how the program interprets it. Normal since a .data section.
80 8: sh_flags = 03 7x 00: SHF_WRITE and SHF_ALLOC: www.sco.com/developers/gabi/2003-12-17/ch4.sheader.html#sh_flags, as required from a .data section
90 0: sh_addr = 8x 00: TODO: standard says:
If the section will appear in the memory image of a process, this member gives the address at which the section's first byte should reside. Otherwise, the member contains 0.
but I don't understand it very well yet.
90 8: sh_offset = 00 02 00 00 00 00 00 00 = 0x200: number of bytes from the start of the program to the first byte in this section
a0 0: sh_size = 0d 00 00 00 00 00 00 00
If we take 0xD bytes starting at sh_offset 200, we see:
```
00000200  48 65 6c 6c 6f 20 77 6f  72 6c 64 21 0a 00        |Hello world!..  |
```
AHA! So our "Hello world!" string is in the data section like we told it to be on the NASM.
Once we graduate from hd, we will look this up like:
```
readelf -x .data hello_world.o
```
which outputs:
```
Hex dump of section '.data':
  0x00000000 48656c6c 6f20776f 726c6421 0a       Hello world!.
```
NASM sets decent properties for that section because it treats .data magically: www.nasm.us/doc/nasmdoc7.html#section-7.9.2
Also note that this was a bad section choice: a good C compiler would put the string in .rodata instead, because it is read-only and it would allow for further OS optimizations.
- a0 8: sh_link and sh_info = 8x 0: do not apply to this section type. www.sco.com/developers/gabi/2003-12-17/ch4.sheader.html#special_sections
- b0 0: sh_addralign = 04 = TODO: why is this alignment necessary? Is it only for sh_addr, or also for symbols inside sh_addr?
- b0 8: sh_entsize = 00 = the section does not contain a table. If != 0, it means that the section contains a table of fixed size entries. In this file, we see from the readelf output that this is the case for the .symtab and .rela.text sections.

 Read the full article

ELF Hello World Tutorial / .text section by

Ciro Santilli  40 Updated 2025-07-16

 View more

Now that we've done one section manually, let's graduate and use the readelf -S of the other sections:

  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 2] .text             PROGBITS         0000000000000000  00000210
       0000000000000027  0000000000000000  AX       0     0     16

.text is executable but not writable: if we try to write to it Linux segfaults. Let's see if we really have some code there:

objdump -d hello_world.o

gives:

hello_world.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <_start>:
   0:       b8 01 00 00 00          mov    $0x1,%eax
   5:       bf 01 00 00 00          mov    $0x1,%edi
   a:       48 be 00 00 00 00 00    movabs $0x0,%rsi
  11:       00 00 00
  14:       ba 0d 00 00 00          mov    $0xd,%edx
  19:       0f 05                   syscall
  1b:       b8 3c 00 00 00          mov    $0x3c,%eax
  20:       bf 00 00 00 00          mov    $0x0,%edi
  25:       0f 05                   syscall

If we grep b8 01 00 00 on the hd, we see that this only occurs at 00000210, which is what the section says. And the Size is 27, which matches as well. So we must be talking about the right section.

This looks like the right code: a write followed by an exit.

The most interesting part is line a which does:

movabs $0x0,%rsi

to pass the address of the string to the system call. Currently, the 0x0 is just a placeholder. After linking happens, it will be modified to contain:

4000ba: 48 be d8 00 60 00 00    movabs $0x6000d8,%rsi

This modification is possible because of the data of the .rela.text section.

 Read the full article

ELF Hello World Tutorial / SHT_STRTAB by

Ciro Santilli  40 Updated 2025-07-16

 View more

Sections with sh_type == SHT_STRTAB are called string tables.

They hold a null separated array of strings.

Such sections are used by other sections when string names are to be used. The using section says:

which string table they are using
what is the index on the target string table where the string starts

So for example, we could have a string table containing:

Data: \0 a b c \0 d e f \0
Index: 0 1 2 3  4 5 6 7  8

The first byte must be a 0. TODO rationale?

And if another section wants to use the string d e f, they have to point to index 5 of this section (letter d).

Notable string table sections:

.shstrtab
.strtab

 Read the full article

ELF Hello World Tutorial / .shstrtab by

Ciro Santilli  40 Updated 2025-07-16

 View more

Section type: sh_type == SHT_STRTAB.

Common name: "section header string table".

The section name .shstrtab is reserved. The standard says:

This section holds section names.

This section gets pointed to by the e_shstrnd field of the ELF header itself.

String indexes of this section are are pointed to by the sh_name field of section headers, which denote strings.

This section does not have SHF_ALLOC marked, so it will not appear on the executing program.

readelf -x .shstrtab hello_world.o

outputs:

Hex dump of section '.shstrtab':
  0x00000000 002e6461 7461002e 74657874 002e7368 ..data..text..sh
  0x00000010 73747274 6162002e 73796d74 6162002e strtab..symtab..
  0x00000020 73747274 6162002e 72656c61 2e746578 strtab..rela.tex
  0x00000030 7400                                t.

The data in this section has a fixed format: www.sco.com/developers/gabi/2003-12-17/ch4.strtab.html

If we look at the names of other sections, we see that they all contain numbers, e.g. the .text section is number 7.

Then each string ends when the first NUL character is found, e.g. character 12 is \0 just after .text\0.

 Read the full article

ELF Hello World Tutorial / .symtab by

Ciro Santilli  40 Updated 2025-07-16

 View more

Section type: sh_type == SHT_SYMTAB.

Common name: "symbol table".

First the we note that:

sh_link = 5
sh_info = 6

For SHT_SYMTAB sections, those numbers mean that:

strings that give symbol names are in section 5, .strtab
the relocation data is in section 6, .rela.text

A good high level tool to disassemble that section is:

nm hello_world.o

which gives:

0000000000000000 T _start
0000000000000000 d hello_world
000000000000000d a hello_world_len

This is however a high level view that omits some types of symbols and in which the symbol types . A more detailed disassembly can be obtained with:

readelf -s hello_world.o

which gives:

Symbol table '.symtab' contains 7 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS hello_world.asm
     2: 0000000000000000     0 SECTION LOCAL  DEFAULT    1
     3: 0000000000000000     0 SECTION LOCAL  DEFAULT    2
     4: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT    1 hello_world
     5: 000000000000000d     0 NOTYPE  LOCAL  DEFAULT  ABS hello_world_len
     6: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT    2 _start

The binary format of the table is documented at www.sco.com/developers/gabi/2003-12-17/ch4.symtab.html

The data is:

readelf -x .symtab hello_world.o

which gives:

Hex dump of section '.symtab':
  0x00000000 00000000 00000000 00000000 00000000 ................
  0x00000010 00000000 00000000 01000000 0400f1ff ................
  0x00000020 00000000 00000000 00000000 00000000 ................
  0x00000030 00000000 03000100 00000000 00000000 ................
  0x00000040 00000000 00000000 00000000 03000200 ................
  0x00000050 00000000 00000000 00000000 00000000 ................
  0x00000060 11000000 00000100 00000000 00000000 ................
  0x00000070 00000000 00000000 1d000000 0000f1ff ................
  0x00000080 0d000000 00000000 00000000 00000000 ................
  0x00000090 2d000000 10000200 00000000 00000000 -...............
  0x000000a0 00000000 00000000                   ........

The entries are of type:

typedef struct {
    Elf64_Word  st_name;
    unsigned char   st_info;
    unsigned char   st_other;
    Elf64_Half  st_shndx;
    Elf64_Addr  st_value;
    Elf64_Xword st_size;
} Elf64_Sym;

Like in the section table, the first entry is magical and set to a fixed meaningless values.

 Read the full article

ELF Hello World Tutorial / .strtab by

Ciro Santilli  40 Updated 2025-07-16

 View more

Holds strings for the symbol table.

This section has sh_type == SHT_STRTAB.

It is pointed to by sh_link == 5 of the .symtab section.

readelf -x .strtab hello_world.o

outputs:

Hex dump of section '.strtab':
  0x00000000 0068656c 6c6f5f77 6f726c64 2e61736d .hello_world.asm
  0x00000010 0068656c 6c6f5f77 6f726c64 0068656c .hello_world.hel
  0x00000020 6c6f5f77 6f726c64 5f6c656e 005f7374 lo_world_len._st
  0x00000030 61727400                            art.

This implies that it is an ELF level limitation that global variables cannot contain NUL characters.

 Read the full article

ELF Hello World Tutorial / .rela.text by

Ciro Santilli  40 Updated 2025-07-16

 View more

Section type: sh_type == SHT_RELA.

Common name: "relocation section".

.rela.text holds relocation data which says how the address should be modified when the final executable is linked. This points to bytes of the text area that must be modified when linking happens to point to the correct memory locations.

Basically, it translates the object text containing the placeholder 0x0 address:

   a:       48 be 00 00 00 00 00    movabs $0x0,%rsi
  11:       00 00 00

to the actual executable code containing the final 0x6000d8:

4000ba: 48 be d8 00 60 00 00    movabs $0x6000d8,%rsi
4000c1: 00 00 00

It was pointed to by sh_info = 6 of the .symtab section.

readelf -r hello_world.o outputs:

Relocation section '.rela.text' at offset 0x3b0 contains 1 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
00000000000c  000200000001 R_X86_64_64       0000000000000000 .data + 0

The section does not exist in the executable.

The actual bytes are:

00000370  0c 00 00 00 00 00 00 00  01 00 00 00 02 00 00 00  |................|
00000380  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

The struct represented is:

typedef struct {
    Elf64_Addr  r_offset;
    Elf64_Xword r_info;
    Elf64_Sxword    r_addend;
} Elf64_Rela;

So:

370 0: r_offset = 0xC: address into the .text whose address this relocation will modify
370 8: r_info = 0x200000001. Contains 2 fields:
- ELF64_R_TYPE = 0x1: meaning depends on the exact architecture.
- ELF64_R_SYM = 0x2: index of the section to which the address points, so .data which is at index 2.
The AMD64 ABI says that type 1 is called R_X86_64_64 and that it represents the operation S + A where:
- S: the value of the symbol on the object file, here 0 because we point to the 00 00 00 00 00 00 00 00 of movabs $0x0,%rsi
- A: the addend, present in field r_added
This address is added to the section on which the relocation operates.
This relocation operation acts on a total 8 bytes.
380 0: r_addend = 0

So in our example we conclude that the new address will be: S + A = .data + 0, and thus the first thing in the data section.

 Read the full article

ELF Hello World Tutorial / Dynamic linking sections by

Ciro Santilli  40 Updated 2025-07-16

 View more

This program did not have certain dynamic linking related sections because we linked it minimally with ld.

However, if you compile a C hello world with GCC 8.2:

gcc -o main.out main.c

some other interesting sections would appear.

 Read the full article

ELF Hello World Tutorial / Standards by

Ciro Santilli  40 Updated 2025-07-16

 View more

ELF is specified by the LSB:

The LSB basically links to other standards with minor extensions, in particular:

Generic (both by SCO):
- System V ABI 4.1 (1997) www.sco.com/developers/devspecs/gabi41.pdf, no 64 bit, although a magic number is reserved for it. Same for core files. This is the first document you should look at when searching for information.
- System V ABI Update DRAFT 17 (2003) www.sco.com/developers/gabi/2003-12-17/contents.html, adds 64 bit. Only updates chapters 4 and 5 of the previous document: the others remain valid and are still referenced.
Architecture specific (by the processor vendor):
- IA-32: refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-IA32/LSB-Core-IA32/elf-ia32.html, points mostly to www.sco.com/developers/devspecs/abi386-4.pdf
- AMD64: refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-AMD64/LSB-Core-AMD64/elf-amd64.html, points mostly to www.x86-64.org/documentation/abi.pdf

A handy summary can be found at:

man elf

 Read the full article

ELF Hello World Tutorial / How to learn by

Ciro Santilli  40 Updated 2025-07-16

 View more

Spin like mad between:

standards
high level generators. We use the assembler as and linker ld.
hexdumps
file decompilers. We use readelf. It makes it faster to read the ELF file by turning it into human readable output. But you must have seen one byte-by-byte example first, and think how readelf output maps to the standard.
low-level generators: stand-alone libraries that let you control every field of the ELF files you generated. github.com/BR903/ELFkickers, github.com/sqall01/ZwoELF and many more on GitHub.
consumer: the exec system call of the Linux kernel can parse ELF files to starts processes: github.com/torvalds/linux/blob/v4.11/fs/binfmt_elf.c, stackoverflow.com/questions/8352535/how-does-kernel-get-an-executable-binary-file-running-under-linux/31394861#31394861

 Read the full article

ELF Hello World Tutorial / Specified file formats by

Ciro Santilli  40 Updated 2025-07-16

 View more

The ELF standard specifies multiple file formats:

Object files (.o).
Intermediate step to generating executables and other formats:
```
Source code

    |
    | Compilation
    |
    v

Object file

    |
    | Linking
    |
    v

Executable
```
Object files exist to make compilation faster: with make, we only have to recompile the modified source files based on timestamps.
We have to do the linking step every time, but it is much less expensive.

Executable files (no standard Linux extension).
This is what the Linux kernel can actually run.

Archive files (.a).
Libraries meant to be embedded into executables during the Linking step.

Shared object files (.so).
Libraries meant to be loaded when the executable starts running.

Core dumps.
Such files may be generated by the Linux kernel when the program does naughty things, e.g. segfault.
They exist to help debugging the program.

In this tutorial, we consider only object and executable files.

 Read the full article

ELF Hello World Tutorial / Implementations by

Ciro Santilli  40 Updated 2025-07-16

 View more

Compiler toolchains generate and read ELF files.
Sane compilers should use a separate standalone library to do the dirty work. E.g., Binutils uses BFD (in-tree and canonical source).

Operating systems read and run ELF files.
Kernels cannot link to a library nor use the C stlib, so they are more likely to implement it themselves.
This is the case of the Linux kernel 4.2 which implements it in th file fs/binfmt_elf.c.

Specialized libraries. Examples:
- github.com/eliben/pyelftools. By a hardcore Googler: plus.google.com/+EliBenderskyGplus/posts
- sourceforge.net/projects/elftoolchain

 Read the full article

Why do the electron and the proton have the same charge except for the opposite signs? by

Ciro Santilli  40 Updated 2025-07-16

 View more

physics.stackexchange.com/questions/21753/why-do-electron-and-proton-have-the-same-but-opposite-electric-charge

Given the view of the Standard Model where the electron and quarks are just completely separate matter fields, there is at first sight no clear theoretical requirement for that.

As mentioned e.g. at QED and the men who made it: Dyson, Feynman, Schwinger, and Tomonaga by Silvan Schweber (1994) chapter 1.6 "Hole theory", Dirac initially wanted to think of the holes in his hole theory as the protons, as a way to not have to postulate a new particle, the positron, and as a way to "explain" the proton in similar terms. Others however soon proposed arguments why the positron would need to have the same mass, and this idea had to be discarded.

 Read the full article

Oil drop experiment by

Ciro Santilli  40 Updated 2025-07-16

 View more

Clear experiment diagram which explains that the droplet mass determined with Stoke's law:

Video 1.

Quantum Mechanics 4a - Atoms I by ViaScience (2013)

Source.

American Scientific, LLC sells a ready made educational kit for this: www.youtube.com/watch?v=EV3BtoMGA9c

Here's some actual footage of a droplet on a well described more one-off setup:

Video 2.

Millikan's Experiment, Part 2: The Experiment by Phil Furneaux (2017)

Source. From Lancaster University

This American video likely from the 60's shows it with amazing contrast: www.youtube.com/watch?v=_UDT2FcyeA4

 Read the full article

Anomalous magnetic dipole moment by

Ciro Santilli  40 Updated 2025-07-16

 Read the full article

Diffraction of Cathode Rays by a Thin Film by Thomson and Reid (1927) by

Ciro Santilli  40 Updated 2025-07-16

 View more

www.nature.com/articles/119890a0

 Read the full article

Davisson-Germer experiment by

Ciro Santilli  40 Updated 2026-08-21

 View more

 Read the full article

Ionizing and non-ionizing radiation by

Ciro Santilli  40 Updated 2025-07-16

 Read the full article

Very low frequency by

Ciro Santilli  40 Updated 2025-07-16

 View more

Notably used for communication with submarines, so in particular crucial as part of sending an attack signal to that branch of the nuclear triad.

 Read the full article

Radio wave by

Ciro Santilli  40 Updated 2025-07-16

 View more

This is likely the easiest one to produce as the frequencies are lower, which is why it was discovered first. TODO original setup.

Also because it is transparent to brick and glass, (though not metal) it becomes good for telecommunication.

Some notable subranges:

FM broadcasting

 Read the full article

 Pinned article: Introduction to the OurBigBook Project

Welcome to the OurBigBook Project! Our goal is to create the perfect publishing platform for STEM subjects, and get university-level students to write the best free STEM tutorials ever.

Everyone is welcome to create an account and play with the site: ourbigbook.com/go/register. We belive that students themselves can write amazing tutorials, but teachers are welcome too. You can write about anything you want, it doesn't have to be STEM or even educational. Silly test content is very welcome and you won't be penalized in any way. Just keep it legal!

Video 1.

Intro to OurBigBook

. Source.

We have two killer features:

topics: topics group articles by different users with the same title, e.g. here is the topic for the "Fundamental Theorem of Calculus" ourbigbook.com/go/topic/fundamental-theorem-of-calculus
Articles of different users are sorted by upvote within each article page. This feature is a bit like:
- a Wikipedia where each user can have their own version of each article
- a Q&A website like Stack Overflow, where multiple people can give their views on a given topic, and the best ones are sorted by upvote. Except you don't need to wait for someone to ask first, and any topic goes, no matter how narrow or broad
This feature makes it possible for readers to find better explanations of any topic created by other writers. And it allows writers to create an explanation in a place that readers might actually find it.
Figure 1.
Screenshot of the "Derivative" topic page
. View it live at: ourbigbook.com/go/topic/derivative
Video 2.
OurBigBook Web topics demo
. Source.
local editing: you can store all your personal knowledge base content locally in a plaintext markup format that can be edited locally and published either:
- to OurBigBook.com to get awesome multi-user features like topics and likes
- as HTML files to a static website, which you can host yourself for free on many external providers like GitHub Pages, and remain in full control
This way you can be sure that even if OurBigBook.com were to go down one day (which we have no plans to do as it is quite cheap to host!), your content will still be perfectly readable as a static site.
Figure 2.
You can publish local OurBigBook lightweight markup files to either OurBigBook.com or as a static website
.
Figure 3.
Visual Studio Code extension installation
.
Figure 4.
Visual Studio Code extension tree navigation
.
Figure 5.
Web editor
. You can also edit articles on the Web editor without installing anything locally.
Video 3.
Edit locally and publish demo
. Source. This shows editing OurBigBook Markup and publishing it using the Visual Studio Code extension.
Video 4.
OurBigBook Visual Studio Code extension editing and navigation demo
. Source.
Internal cross file references done right:
Infinitely deep tables of contents:
Figure 6.
Dynamic article tree with infinitely deep table of contents
.
Live URL: ourbigbook.com/cirosantilli/chordate
Descendant pages can also show up as toplevel e.g.: ourbigbook.com/cirosantilli/chordate-subclade