►
From YouTube: Rust Before Main - Ryan Levick - Rust Linz, July 2022
Description
When you run a Rust program, you may be tempted to think that the first code to execute is the main function. However, this is far from the case. In this talk, we'll explore what happens before the main function runs. By the end, you'll have a deeper understanding of what happens before the bits that rustc compiles your program into ever run.
Ryan has been writing Rust since around version 0.10. He now focuses on Rust full time at Microsoft. When he's not doing Rust, he enjoys cooking, traveling and exploring Berlin where he lives.
Resources:
The Bits Between the Bits: https://www.youtube.com/watch?v=dOfucXtyEsU
Making Your Own Executable Packer: https://fasterthanli.me/series/making-our-own-executable-packer
How the heck do we get to main(): http://dbp-consulting.com/tutorials/debugging/linuxProgramStartup.html
Everything You Ever Wanted to Know About DLLs: https://www.youtube.com/watch?v=JPQWQfDhICA
Minimizing Rust Binary Size: https://github.com/johnthagen/min-sized-rust
Rust Linz: https://rust-linz.at
Speak at Rust Linz: https://sessionize.com/rust-linz
Twitter: https://twitter.com/rustlinz
A
This
talk
will
be
quite
different
from
my
last
talk
at
rust.
Lentz
that
talk
was
was
quite
General
and
about
why
you
should
care
about
Russ.
This
is
a
as
a
much
more
technical
talk,
but
don't
worry
it's
still,
hopefully
going
to
be
very
approachable
and
open
for
everybody.
We're
going
to
be
talking
today
about
rust
before
Maine,
as
in
Russ.
A
A
The
answer
might
surprise
you:
what
tools
can
we
use
to
inspect
trust,
inspect
Russ
executables
so
that
we
can
look
into
them?
And
just
so
you
know
everything
we're
going
to
be
talking
about
today
is
only
going
to
have
to
do
with
Linux,
but
don't
worry
if
you're,
a
Mac,
OS
or
Windows
user.
This
stuff
will
sort
of
kind
of
translate.
A
lot
of
the
concepts
are
very
similar
on
those
platforms,
but
they
may
not
be
quite
the
same
all
right.
A
So,
let's
talk
about
my
mental
model
before
I
learned
about
all
this
stuff
about
how
a
binary
executable
actually
runs.
So
here
on
the
left,
we
have
a
binary,
and
most
people
know
that
a
binary
is
binary,
it's
a
whole
bunch
of
ones
and
zeros
and
I.
Imagine
that
when
you
executed
a
binary
executable,
you
just
started
at
the
very
beginning
of
the
file
and
you
interpreted
whatever
those
ones
and
zeros
were
as
assembly
instructions
for
the
given
architecture
that
you're
on
let's
say
for
at
the
beginning.
A
Here
we
have
a
load
B
into
a
instruction
here,
and
then
we
go
to
the
next
one.
After
that-
and
you
know
it
can
move
around-
we
can
have
a
jump
here,
for
instance,
so
we
jump
to
another
place
in
the
binary
and
then
we
execute
again
and
that's
kind
of
how
executing
machine
code
or
binary
code
Works
in
practice,
and
this
isn't
necessarily
wrong.
It's
just
a
little
bit
too
simple.
A
A
So
before
we
get
started
a
few
tips
on
how
to
think
about
things,
how
to
approach
these
problems.
First
of
all,
it
Bears
to
be
repeated.
Computers
are
not
magic.
There's
nothing
necessarily
magical
happening
here.
It's
really
all
just
kind
of
engineering.
At
the
end
of
the
day.
That
means
all
of
this
is
ultimately
understandable.
A
It
may
not
be
obvious
at
first
and
you
may
not
get
it
without
kind
of
putting
a
lot
of
effort
into
understanding
it,
but
it
is
understandable.
It's
not
magic.
It's
not!
You
know
something
that
you
have
to
Divine
from
the
Stars.
It's
all
there
for
you
to
understand
everything
you
see
here
was
made
by
humans.
It
is
a
deliberate
Choice.
It
didn't
have
to
be
this
way.
It
just
ended
up
being
this
way.
A
Some
of
that
is
because
of
deliberate
engineering
choice
and
some
of
those
choices,
you
could
argue,
were
good
choices,
and
some
of
it
is
just
kind
of
random
circumstance,
an
engineer
working
on
something
kind
of
had
to
make
a
decision,
and
they
said
well,
given
a
couple
of
choices.
I
guess
we'll
go
with
this
one.
There
weren't
really
any
good
reasons
for
that
decision,
but
they
made
it
and
now,
40
years
or
50
years
later,
we're
kind
of
stuck
with
it.
A
So
don't
just
assume
that
if
you
see
something
it's
funny
or
it
doesn't
look
quite
right-
it's
because
you
don't
understand
it
or
you're,
not
smart
enough.
It
might
simply
be
because
it's
kind
of
just
random
at
any
given
point.
It's
not
always
easy
to
tell
which
between
deliberate
choice
and
random
circumstance,
a
given
decision
might
be,
and
unfortunately
out
there
in
the
world.
A
Some
explanations
are
not
always
the
best,
so
just
because
you
don't
understand
something
doesn't
mean
that
you're,
not
smart
enough,
it
might
be
that
the
person
just
doesn't
want
to
explain
it
very
well.
So
don't
give
up
before
we
begin
I'd
like
to
talk
through
the
rust
compilation
model,
and
this
is
vastly
simplified
and
in
some
ways
not
even
fully
correct.
But
it's
important
for
this
talk
that
we
kind
of
understand
how
rust
compiles
code.
A
So
you
have
some
code,
here's
a
main
function.
Printing.
You
know
a
wave
Emoji
here
and
we're
going
to
pass
that
rust
code
over
to
rust,
C
and
llvm
in
it
and,
of
course,
most
rust.
Users
usually
use
cargo,
but
hopefully
everybody
here
knows
that
cargo
is
the
build
tool
and
ultimately,
what
cargo
does
is
call
rest.
C,
the
rust,
compiler
and
rust.
A
C
is
a
front
end
that
can
interpret
parts
and
understand
rust
code
and
lovm
is
the
the
back
end
that
rough
C
plugs
into
that
takes
rasi's
understanding
of
your
code
and
turns
it
into
machine
code,
but
what
it
does?
What
lovm
ultimately
produces
object
files,
and
these
are
kind
of
groups
of
functions
metadata
and
things
about
your
program
in
separate
files,
depending
on
what
the
particular
compilation
unit
is.
Typically,
this
is
at
the
crate
level
in
Rust
we
get
those
object
files.
These
are
not
really
executable
quite
yet
they
have
to
be
linked
together.
A
So
we
take
those
object
files.
We
add
in
a
Linker,
that's
lb
in
the
case
of
Linux,
often
and
out
from
the
Linker,
comes
a
binary
executable
or
a
binary
Library,
a
shared
library
of
some
sort
or
something
like
that,
and
that
is
a
program
that
can
actually
be
run.
So
that's
the
compilation
model.
Keep
that
in
mind.
That's
what
happens
before.
We
even
start
to
run
our
program.
A
A
The
number
zero
signaling
typically
success,
there's
an
issue
with
this
program,
though,
for
our
purposes
when
we
compile
it
and
we
look
at
it
even
in
release
mode,
it
turns
out
that
it's
3.8
megabytes,
big,
that's
a
little
big,
probably
too
big
for
our
purposes,
because
it
kind
of
makes
things
difficult
to
look
at
and
inspect
when
you're
dealing
with
a
whole
bunch
of
stuff.
It
would
be
much
nicer
if
we
could
still
have
the
same
rust
program,
but
a
lot
smaller.
A
We
can
do
that
pretty
easily.
If
we
go
into
our
cargo.com
will
file
and
under
the
profile
dot
release
section
we
put
in
a
couple
of
you
know:
nice
features
that
we
have
here
the
first
one
is
strip
that
can
strip
out
some
unnecessary
things
in
your
binary,
because
your
binary
includes
things
like
debug
information,
which
you
know.
If
you're
not
debugging
your
program,
you
don't
really
need
and
some
other
symbols
and
things
like
that
that
can
help
with
tooling
but
are
not
necessary
for
the
actual
running
of
of
the
program.
A
A
Lto
is
turned
to
true
that's
linked
time,
optimization
that
gives
the
Linker
additional
ways
to
optimize
the
size
of
our
program
and
the
last
one
is
panic,
abort
and
if
you're
not
familiar
with
this,
this
is
simply
changing
the
way
that
panics
work
in
in
rust
from
unwinding
the
stack
giving
you
a
nice
message
with
the
Stacked
race
and
things
like
that
to
Simply
aborting
your
program,
stopping
the
program
cold,
and
it
turns
out
that
we
end
up
with
a
program.
That's
93
percent,
smaller.
A
If
we
just
add
these
four
options
here,
so
that's
easy,
but
268
kilobytes
is
still
pretty
big.
It
turns
out
if
you,
if
you
compile
a
c
program,
that's
of
similar
complexity,
you're,
probably
looking
at
around
15
kilobytes.
So
can
we
do
any
better
and
it
turns
out
we
can
by
getting
rid
of
the
standard
Library,
so
we're
statically
linking
the
standard
Library
we're
bringing
it
in
we're
bringing
a
whole
bunch
of
stuff
that
we
don't
actually
need
because
we're
not
really
using
the
standard
Library
other
than
to
exit.
A
So
this
program
here
is
even
simpler.
It
actually
adds
a
external,
an
external
dependency
lib
C
here,
but
that
simplifies
our
program
by
allowing
us
to
only
use
what
we
need.
We
actually
Define
a
real
main
function,
not
the
rust
specific
name
function.
You
have
things
like
no
mangle
here
you
can
see
no
stood
no
main
up
there.
So
there
there
is
no
main
function,
we're
actually
defining
an
main
function
ourselves
and
we
have
to
define
a
panic
Handler
as
well.
A
What
happens
if
this
program
panics
well
we'll
just
go
into
an
infinite
Loop,
and
if
we
do
that
our
program
is
much
smaller.
It's
now
97
smaller
than
our
original
program
at
14
kilobytes,
which
is
roughly
the
size
of
what
you
would
get.
If
you
did
the
same
thing
with
C,
so
we're
in
the
area,
we
didn't
have
to
do
a
ton
of
work
to
get
there
all
right,
14k
much
easier
to
work
with,
let's
start
exploring,
but
wait
what
is
binary
executable.
A
So
what
we
still
don't
know
we
we
know
it's
ones
and
zeros,
but
like
what
are
what
shape
are
those
ones
in
zero
Zen?
And
here
we're
going
to
use
our
first
tool
called
hex
dump
HD
and
we're
going
to
look
at
our
hello
world
binary
and
look
at
the
first
line
and
the
clue
to
what
this
binary
executable
is
is
in
the
the
very
first
line
of
binary
code
there
and
you'll
see
elf.
A
Keep
that
in
mind.
We
can
also
use
the
file
tool
to
look
and
the
file
tool
is
a
nice
tool
that
says
okay,
give
it
a
file,
I'll,
try
and
find
out
to
the
best
of
my
ability.
What
I
think
this
file
is,
and
the
file
tool
correctly
sees
that
this
is
an
elf
executable,
64
bit
and
there's
a
whole
bunch
of
stuff
in
here
that
you
don't
understand
yet
that
you'll
understand
a
lot
better.
At
the
end
of
this
talk,
so
we
see
this
is
an
elf
file,
an
elf
file.
Okay,
that's
that's
good.
A
A
Elf
has
information
both
for
static
linking
that's
when
we
had
the
object
files
before
and
object.
Files
are
Elf
in
the
elf
format
and
they
can
be
linked
together,
but
it
also
has
information
for
runtime
execution,
so
our
executable
that
we're
actually
going
to
run
also
is
elf
and
the
elf
file
has
information
needed
to
execute
that
file.
A
A
The
dot
text
section
contains
our
code,
so
there
are
different
sections
in
this
executable
format.
We're
not
going
to
look
into
elf
very
deeply.
Today,
if
you're
interested
I
have
resources
at
the
end,
but
there
are
sections
in
this
format
that
kind
of
divide
up
the
file
format
and
one
of
them
is
dot
text,
and
that
contains
our
code.
A
A
Well
we're
going
to
use
another
tool,
object,
dump
or
object,
dump
and
pass
our
binary
to
it
with
the
Dash
D
flag
on
it
and
Dash
D
allows
us
to
disassemble
the
text
inside
of
our
or
the
code
inside
of
our
our
binary
and
you'll
see
here
we
have
our
main
function.
It's
right
there.
We
see
it
we're
good
to
go
all
right,
but
unfortunately
it's
not
the
whole
truth.
So
there's
a
lot
more
code
here
than
just
our
main
function.
That
main
function
is
what
we
wrote:
that's
exactly
it.
A
It
has
xor
eax
that
is
essentially
making
eax
register
into
zero.
If
you
don't
know
assembly,
that's
totally
fine,
don't
worry
about
it,
and
then
it
returns.
So
it's
doing
very
simple
things,
but
there's
a
bunch
of
code
around
it-
and
we
see
interesting
things
in
here
that
we,
you
know,
probably
don't
recognize,
we'll
talk
a
little
bit
more
about
that
as
well.
A
A
A
It's,
usually
the
underscore
start
symbol
is
the
real
entry
point
for
our
program.
So
you
can
see
here
in
our
executable.
We've
run
object,
dump
with
the
Dash
D
to
disassemble,
and
this
is
our
underscore
start
symbol
here
and
again
it's
a
bunch
of
assembly.
You
don't
have
to
worry
about
what
it
does.
You
can
just
you
know,
breathe
in
the
the
web,
the
web
assembly,
the
assembly,
the
the
non-web
assembly
here
and
and
and
we'll
talk
about
what
it
does
on
the
next
page.
A
Okay.
So
what
is
it
doing
here?
Well,
it's
not
that
interesting.
It's
setting
up
the
stack!
So
if
you
know
about
the
stack
versus
the
Heap
there's
a
couple
of
instructions,
you
have
to
do
to
kind
of
make
the
the
processor
happy
with
your
stack
it's
moving,
ARG,
C
and
RV.
Those
are
the
arguments
that
you
usually
get
in
main
function.
A
Typically
in
C,
for
instance,
those
are
command
line.
Arguments
that
you're
getting
in
rxc
is
the
count
of
them.
Arcv
is
the
actual
pointer
to
them.
So
it's
moving
that
to
the
right
place.
I
mean
it's
basically
prepping.
The
call
to
libsy
start
main,
so
you
can
see
a
third
line
up
there
in
the
in
the
assembly.
There's
a
call
queue
and
there
and
that's
call
queue-
is
just
assembly
for
call
a
function
and
the
function
that
it's
calling.
A
So,
let's
talk
about
that,
the
other
main
Lipsy
start
main.
What
does
it
do?
It
performs
initialization
of
the
execution
environment.
It
calls
the
main
function,
the
main
function
we
provided
with
appropriate
arguments
and
it
handles
the
return
from
Main
and
it
does
some
other
stuff.
But
we
won't
talk
about
that
today.
A
The
function
also
calls
various
hooks
that
allow
the
user
to
change,
startup
and
exit.
So
you,
you
can
actually
Define
things
in
your
binary
that
run
before
your
program
runs
and
after
your
program
exits,
there's
a
way
to
do
this
and
and
Russ,
but
it's
not
quite
so
easy
and
there
haven't
really
been
as
far
as
I'm
aware
any
kind
of
stable
ways
to
do
this
and
rust.
Quite
yet,
but
you
can,
you
know,
hack
the
Linker
to
do
it.
A
A
word
on
dependencies.
We're
talking
about
lib
C
here.
We're
talking
about
lip
c
main
and
stuff
like
that,
but
like
where
are
these
dependencies
is,
is
Lipsy
like
in
our
binary?
No,
it's
not
so
libsy
exists
on
your
machine
somewhere
and
in
this
case
it's
in
slash
lib,
slash,
x8664
Linux,
you
know,
libc.so.6
is
where
libsy
actually
lives.
So
it's
in
your
on
your
machine
somewhere
and
our
program
is
merely
referencing
to
it,
calling
out
to
it.
So
this
is
what
is
called
a
dynamically
linked
dependency.
A
It's
not
statically
linked
it's
not
in
our
binary,
it's
living
somewhere
else
and
we're
using
another
tool
here.
Ldd
and
what
ldd
does
is
tell
us
what
these
Dynamic
dependencies
of
our
program
are,
and
it's
important
to
remember:
Dynamic
versus
static
here,
most
cargo
dependencies
and
things
like
that
are
statically,
linked
they're
brought
into
your
program
and
live
in
your
program.
So
if
you're,
depending
on
regex
or
something
like
that
from
crates.io,
it's
literally
inside
of
your
executable,
whereas
there
are
other
dependencies
that
live
separately.
A
Like
I
said,
lde
controls,
binaries
Dynamic
dependencies
and
we're
relying
on
libc.so.6
by
by
the
way
so
stands
for
shared
object.
This
is
just
a
a
term.
They
use
in
Linux
for
libraries
that
are
shared
across
the
system
on
Windows.
You
might
refer
to
them
as
dlls,
so
Linux
vsdo
is
the
first
one
there,
and
this
is
not
super
interesting
for
our
purposes.
It's
basically
provided
there
to
kind
of
cache
system
calls
so
that
they
can
be
faster.
A
The
kernel
kind
of
automatically
maps
that
for
us
into
our
program
or
it
gives
access
to
it
for
our
program
and
we've
touched
on
libc
and
we'll
also
touch
on
LD
Linux,
x60
X
8664.so.2.
Soon,
that's
a
very
important
Dynamic
dependency
that
we
have
so
stay
tuned.
Okay.
So,
let's
back
up,
how
did
we
get
here?
So
we're
all
trying
to
figure
out
how
we
got
to
Maine?
Well,
we
start
at
underscore
start
right.
That's
where
we
start
and
then
underscore
start
ends
up.
A
A
So
does
this
mean
that
we
can
just
call
underscore
start
ourselves
and
yeah?
In
fact,
we
can.
We
can
Define
underscore
start
ourselves
as
well,
so
before
we
were
defining
main
this
time,
we're
defining
underscore
start
instead,
and
this
works
all
fine,
except
if
you
try
and
compile
this
you'll
get
a
compiler
error
and
it
will
say
Hey.
You
have
two
underscore
start
symbols
here.
You
should
only
have
one
and
that's
because
by
default
the
Linker
puts
in
an
underscore
start
for
you,
so
we
have
to
when
we're
compiling
this
program.
A
A
Is
there
something
special
about
underscore
start
that
the
kernel
knows
about
or
something
like
that?
Well
turns
out?
No,
that's
not
the
case
this
time
we're
going
to
use
another
tool.
This
is
called
read,
elf,
and
what
read
elf
does
is:
allow
us
to
read
elf
and
print
it
out
in
a
nice
format
so
that
we
can
understand
it.
We're
passing
dot
dash
H
here
and
what
Das
H
does
is.
A
Give
us
the
header
of
our
of
our
L
file
and
headers
a
whole
bunch
of
metadata
and
the
particular
piece
of
metadata
that
we're
interested
in
is
this
entry
point
address.
This
entry
point
address
is
what
tells
the
world
where
we
want
to
start
executing
where,
in
this
elf
file
should
the
kernel
or,
however,
start
executing
this
program,
and
if
we
look
inside
of
our
L
file
at
that
offset
that
it
was
1040
hex
you'll,
see,
let's
add
our
start
symbol.
A
So
the
the
fact
that
it's
called
underscore
start
is
more
of
a
convention
than
anything.
It's
really
and
it's
a
convention
that
the
Linker
takes.
You
know
advantage
of
and
stuff
like
that,
but
from
the
operating
systems
perspective
it
doesn't
know
anything
about
start
and
in
fact,
underscore
start
is
not
even
really
there
it's.
You
know
it's
just
a
label.
It
knows
about
that
because
of
that
metadata
information
inside
of
the
header.
A
All
right,
then
that
begs
the
question:
okay,
then
what
calls
start?
Is
it
the?
Is
it
the
kernel
that
calls
start
and
sometimes
yes,
sometimes
the
answer
is
yes,
but
we
need
something
in
addition
to
just
getting
started.
We
need
a
couple
of
more
services
to
be
done
for
us.
We
need
something
that
parses
this
elf
binary
and
Maps
it
into
memory
for
us.
So
we
have
a
whole
bunch
of
code.
It
exists
on
disk
right
but
like
we
need
it
in
Ram
somewhere,
so
that
we
can
run
it.
A
So
that's
you
know,
and
we
presumably
need
to
make
it
executable,
because
if
you
know
anything
about
security,
when
it
comes
to
kernels
like
not
all
memory
is
treated
the
same,
some
memory
is
readable
and
writable.
Some
of
it
is
executable.
We
need
to
make
sure
that
everything
lives
in
its
right
place.
A
How
do
we
get
the
elf
binary
from
disk
on
into
memory
and
then,
second,
how
do
we
like
load
these
Dynamic
dependencies
that
we
have
and
put
them
in
memory?
How
do
we
make
sure
that
they're
in
our
address
space,
because
they
exist
somewhere
on
disk
too?
So
we
need
something
that
loads
them
as
well,
and
we
also
need
a
way
to
ensure
that
our
binary
code
can
call
them
so,
like
you
know,
if
somebody
loads
it
into
memory
and
our
code
is
there
like?
A
What
address
do
we
call
to
call
into
lib
see
like
who?
Who
does
that
mapping
for
us
and
things
like
that?
Well
turns
out,
we
need
a
tool
called
a
dynamic
loader,
and
this
Dynamic
loader
is
also
known
as
a
dynamic
Linker
confusingly,
and
this
is
different
than
a
Linker
AKA
a
static
Linker.
This
is
a
dynamic
Linker
and
it's
also
known
as
a
dynamic
interpreter.
A
So
if
you
see
any
of
these
three
names,
you
know
that
you're
talking
about
the
same
thing,
Dynamic,
loader,
Dynamic,
Linker,
Dynamic
interpreter,
are
all
the
same
thing
and
what
they
do
is
essentially
what
we've
talked
about.
Take
this
elf
binary
map
it
into
memory,
low
Dynamic
dependencies
and
ensure
our
binary
can
call
them.
A
The
kernel
does
some
of
that
stuff,
and
you
know
where
it's
where
the
kernel
starts
and
where
the
dynamic
interpreter
starts
is
kind
of
not
for
the
for
today,
but
we
can
think
of
the
dynamic
interpreter
as
doing
a
lot
of
this
heavy
lifting
for
us
so
like
what,
where,
where
is
this
Dynamic
Linker?
How
does
you
know
who's
running
it
whatever?
A
Dependency
and
if
you
remember
back
to
ldd
before
this
is
exactly
the
third
dependency
that
we
talked
about,
that
are
that
our
our
binary
has.
So
you
know
it
was
the
kernel
that
put
our
our
some
of
our
our
executable
into
to
memory
and
then
you
know
looked
inside
of
our
binary
and
said.
Oh,
this
thing
needs
a
dynamic
loader,
which
one
does
it
need.
Oh
it
needs
that
one
I'll
load
that
one
for
it
and
then
I'll
like
hand
it
off
to
the
dynamic
loader
and
I'm
out.
A
So
really
the
kernel
has
a
pretty
simple
job
when
it
comes
to
things
and
it
hands
off
to
the
dynamic
loader
to
do
the
really
heavy
lifting
okay.
So
how
do
we
get
here?
So
we
have
a
dynamic
loader
that
the
kernel
hands
the
dynamic
loader
this
this
executable,
the
dynamic
loader,
does
a
whole
bunch
of
work
that
we're
not
even
going
to
get
into
today,
because,
unfortunately
we
don't
have
enough
time.
A
It
does
things
like
map
memory,
so
it
takes
the
stuff
that's
on
disk
and
puts
it
into
the
right
place
in
memory
it
loads
our
Dynamic
dependencies.
It
does
something
called
relocations,
which
is
a
whole
nother
subject,
essentially
saying
you
want
to
call
this
function
over
here.
Well,
where
in
memory
is
it
okay,
I'll,
basically
Hot
Patch
your
program
to
be
able
to
call
that
that
function
in
in
the
right
place
of
memory?
A
So
if
you
thought
of
binary
executables
as
being
very
static,
things
I
hate
to
break
it,
to
you,
there's
a
whole
lot
of
dynamicness
to
static
binaries
and
then
eventually,
when
the
dynamic
loader
is
done
with
everything
that
it
needs
to
do.
It
jumps
to
underscore
start
for
us
and
that's
when
our
program
takes
over
okay.
So
we
we
know
how
we
get
to
that.
A
We
know
how
to
get
from
the
Dynamic
loader
to
the
underscore
start
symbol,
and
we
know
how
to
get
from
underscore
start
to
main
so
like
we're
almost
there
right,
whereas
at
some
point
we
have
to
to
stop
this
madness
and
we
have
to
to
just
be
at
the
beginning
right.
So
what
actually
invokes
the
dynamic
loader-
and
that
is
this
XV
cve
call-
and
this
is
the
system-
call
that
Linux
provides
for
actually
executing
a
a
binary
and,
as
we
see
here,
xcb
executes
a
program
referred
to
by
the
pass.
A
That's
passed
to
it.
This
path
must
be
either
a
binary,
executable
or
a
script,
starting
with
a
hash
bang
interpreter.
So
you
know
if
you've,
if
you've
seen
that
in
a
script
before
then
you
know
where
that
comes
from.
If
you
want
to
run
a
ruby
or
a
python
or
something
that's
where
that
comes
from,
and
basically
then
that
loads
it
into
the
kernel
and
the
kernel
looks
at
the
alpha.
Executable
looks
at
The
Interpreter
named
in
that
dot,
interp
segment
that
we
talked
about
before
notices.
A
Okay,
it
needs
a
dynamic,
loader,
I'll
load
that
for
it
and
then
I'll
just
hand
it
off
to
Dynamic
loader
and
walk
away,
and
that's
it
that's
basically
the
beginning.
So
where
does
our
journey
begin?
It
starts
at
this
system.
Call
that
is
is
literally
what
gets
called
when
you're
at
a
terminal,
if
you're
in
a
terminal-
and
you
do
dot
slash
your
your
binary,
executable
name.
All
the
shell
does
is
take
the
path
there
and
pass
it
off
to
this
x.
A
Cve
system
call
does
very
little
other
than
that,
and
that
gets
passed
over
to
a
dynamic
loader
from
the
kernel
that
data
enclosure
eventually
calls
underscore
start,
which
eventually
calls
underscore
lipstart
main,
which
eventually
calls
our
main
function.
We
finally
figured
out
how
we
get
to
Main
and
then
all
of
the
fun
actually
begins.
A
A
A
A
But
what
do
we
not
learn
today
because
there's
a
whole
bunch?
This
was
kind
of
just
the
introduction
and
to
actually
how
programs
get
executed
on
Linux.
We
didn't
learn
about
the
specifics
of
lip
C
star
main
at
all.
There's
it's
more
complex
than
I.
Let
on
we
didn't
learn
anything
about
the
exact
layout
and
contents
of
Elf
files.
What's
in
the
header,
the
difference
between
sections
and
segments
where
things
live,
different
string
tables
and
things
like
that,
we
didn't
learn
about
the
full
responsibilities
of
the
dynamic
Linker.
A
We
didn't
learn
how
this
works
at
all
on
other
platforms.
What
about
Windows?
What
about
Mac
OS?
What
about
BSD
lots
of
fun?
Dynamic
loading
tricks?
We
didn't
talk
about
so,
if
you're
interested
in
kind
of
okay.
How
can
this
help
me
hack
things
and
things
like
that?
I
suggest
you
look
into
LD
preload.
There
are
a
couple
of
talks
out
there
that
I've
seen
given
where
people
use
LD
preload
to
do
fun.
A
Things
I
believe
there
was
one
by
Young
Eric
who
ended
up
putting
something
in
LD
preload
that
kind
of
rewrote
all
of
the
libc
functions
and
charge
of
printing
and
just
caused
everything
to
be
uppercased
and
append.
Exclamation
points
to
it,
so
you
can
kind
of
hack
binaries
that
way,
which
is
really
fun.
A
So,
given
all
those
things
that
we
don't
know
about,
I
want
to
give
you
some
resources
to
go,
because
this
was
really
just
an
introduction.
The
first
one
I'll
talk
about
is
Matt
gobble.
It's
the
bits
between
the
bits
which
is
kind
of
what
got
me
into
this
stuff.
This
is
a
CPP
con
talk
that
talks
about
how
to
get
to
Main
for
a
c
plus
executable,
and
that
talk
goes
even
deeper
than
I
was
able
to
go
in
today.
A
So
take
a
look
at
that
one
then,
of
course,
fast
food
lines.
Making
your
own
executable,
Packer
is
probably
kind
of
the
best
I
would
say,
rust,
specific
introduction
or
really
guide
to
learning
about
this
stuff.
You
essentially
create
your
own
Dynamic
loader
from
scratch,
which
is
really
cool,
Patrick
Horgan's,
how
the
heck
do
we
get
to
Maine
is,
is
really
great
and
gave
me
a
lot
of
this
information
if
you're
into
Windows
James
mcnellis
is
everything
ever
wanted
to
know
about.
A
Dlls
is
really
fantastic,
so
you
can
kind
of
essentially
learn
the
same
thing,
but
from
a
Windows
perspective
and
then
John
Fagan's,
minimizing
rust,
binary
size
is
a
great
resource
if
you
want
to
make
the
smallest
possible
rust
binary
so
that
all
of
this
is
a
little
bit
easier
to
work
with
all
right,
and
that's
it
that's
my
talk.
If
there
are
any
questions,
be
happy
to
answer.