Legendre polynomials

Legendre polynomials. Because… Why not?

Anatomy of a PE (2012-10-30)

[EDIT] This post was migrated from my blog from 2011…

Preamble

Executables (EXE/DLL) in Microsoft Windows make use of a format called PE (Portable Executable).

A PE image typically lies in the hard drive as a .exe or .dll file, and is loaded by the Windows Loader into the RAM of the system when a process is created from that file (e.g., by double-clicking the .exe). So, basically, we have two different states:

  • Physical PE image file.
  • Loaded PE image (running process).

Layout

The layout of a PE image contains the following elements:

  • A header, glued at the first byte of the file.
  • A list of consecutive sections.
  • An optional chunk of trailing (unused) bytes.

These elements are concatenated, and there may or may not be padding space between them. This padding space, if present, is usually filled with 0x00 bytes.

It is possible to add trailing bytes to a PE image. Actually, those files will simply lie there doing nothing. However, some types of processes such as package installers can use the trailing area to add some payload that the process will use (e.g., decrypt, uncompress, …) at some point.

The PE Header

The PE header contains a wealth of information, structured in a fixed way.

Among the many details about the PE that you can gather from the header, there’s the list of sections. The list of sections contains the name, position, and size of each section in the PE, both in physical file format, and when loaded in memory as a process.

Many other things are described by the header, such as the address of the Entry Point (the instruction where code execution must start), and the address of some data directories. It is in these data directories where you can find the list of DLLs the PE depends on, the list of functions exported by the PE, etc…

The PE Header is usually 0x0400 (1024) bytes long. The data structures contained in it are defined in winnt.h, and they are always the same (so you can assume offsets and such). One must pay attention, though, to the fact that depending on whether the process is 32-bit or 64-bit, some pieces of the header will be PE32 or PE64. One can tell whether the process is 32-bit or 64-bit by checking the header flags (which are found at a location which is common to PE32 and PE64 headers).

RVAs and VAs

In general, the addresses found in the PE header are given as RVAs (Relative Virtual Addresses). An RVA is an offset relative to the first byte of the PE image. Assuming that you know the location in memory of the first byte of the PE image (the image base pointer), then the relationship between a VA (Virtual Address) and its corresponding RVA is given by:

VA = ( base + RVA )

RVA = ( VA - base )

If the PE is a physical file, then the base pointer is simply the start of the file. However, if the PE has been loaded as a process, then the base address can be found in several ways that should (in theory) match:

  • The value returned by GetModuleHandle(0) is, in fact, the base pointer.
  • The HINSTANCE received by WinMain is, in fact, the base pointer.
  • The Windows Loader stores the base pointer at the PE header on load, in the BaseOfImage field.

The PE header is glued at this location in memory. So, in run-time, one can use this knowledge to do PE-related operations such as leap-frogging through the PE sections. A typical anti-cracking use is to run a CRC32 on the code section in order to display a badboy message if the executable code has been patched, infected, or tampered with.

Physical vs. loaded state

The anatomy of the PE image is different, yet quite similar, in both (physical vs. loaded) PE states.

When a PE is loaded as a process, the PE image file gets chopped in sections, and these sections get relocated (copied) in memory:

  • In both states, the PE image forms a block of contiguous bytes.
  • In both states, the header and the sections are found in the same order.
  • The amount of padding between sections usually differs.

In their physical file form, PE sections do not need to have any particular padding, so EXE/DLL files can be as small as possible. On the other hand, when loaded, each PE section occupies a certain number of whole memory pages with certain permissions (execution, read-only, etc…). The amount of padding for the start address and the size of each section is given by the PE header.

It is important to note that this relocation procedure simply adds some padding between sections. The section chunks themselves remain identical, and are a straight copy of the original bytes found in the physical file. The only exceptions are some areas which get initialised by the Windows Loader on load (e.g., some fields in the PE header, the IAT, …). I will talk about these in a future post.

[EDIT] I have made significant progress in this area in the 10+ years since I wrote this. But Part II of this post never saw the light of day. Spare time is scarce.

Code fortification (2012-10-17)

[EDIT] This post was migrated from my blog from 2011…

Lately, I’ve been reading a lot about code fortification, and low-level debugging. Here are some of the most interesting links I’ve found. They’re all worth reading if you fancy hardcore OS internals and such:

An In-Depth Look into the Win32 Portable Executable File Format

Peering Inside the PE: A Tour of the Win32 Portable Executable File Format

The Portable Executable Format on Windows

Writing a basic Windows debugger (Part I)

Writing a basic Windows debugger (Part II)

An Anti-Reverse Engineering Guide

Introduction Into Windows Anti-Debugging

Understanding the Import Address Table

Anti-unpacker tricks

This all brings me back to my teenager years coding in x86 assembly language.

Index-Of-Refraction (2011-10-15)

[EDIT] This post was migrated from my blog from 2011…

This all below is stuff that kids study in school. :)

Below is a visualization of the behavior of a ray of light as it hits a dielectric interface.

Some key phenomena which show up in the video are:

  • The Fresnel term (reflection vs. refraction).
  • The Index of Refraction.
  • The critical angle.
  • Total Internal Reflection (TIR).
  • As nd increases the Index of Refraction becomes higher, and so does the Fresnel term, which defines the proportion between reflected and refracted light. The critical angle becomes higher too, so there is more Total Internal Reflection.

When a ray of light hits an interface (assuming an ideal surface), all incident light must be either reflected or refracted. The Fresnel term (controlled by nd) tells how much light is reflected at a given incident angle. All the light that is not reflected is refracted, so both amounts (reflection and refraction) always add up to the total amount of incident light.

The Fresnel term approaches 1 at grazing angles (all light is reflected and nothing is refracted, regardless of nd) and is low (the lower the smaller the nd) at perpendicular angles (more light is refracted).

As a rule of thumb:

  • The lower the nd, the lower the IOR, and the more transparent the surface (more glass/liquid-like).
  • The higher the nd, the higher the IOR, and the more reflective the surface (more metallic/mirror-like).

For example:

  • Void: nd=1.
  • Air: nd=1.1.
  • Water: nd=1.33.
  • Glass: nd=1.51.
  • Diamond: nd=2.5.
  • Metals: nd=20+. (approx. complex IOR).
  • Ideal mirror: nd=infinity.

When a ray of light enters a medium with an nd lower than the nd of the previous medium, there is an angle at which the Fresnel term becomes 1 and beyond which light won’t refract anymore. This angle is called critical angle, and beyond it, the surface behaves like a perfect mirror, reflecting back all incident light. This effect is called Total Internal Reflection (TIR).

The cosine lobe (2021-10-12)

[EDIT] This post was migrated from my blog from 2011…

Testing image/video uploads.

Hello again!

Like most “computer people” I’ve had some attempts over the years to manage a personal website, then a blog, then various social media accounts, etc… to quickly realize with each attempt that I don’t have the time, and to some extent, the will or need to keep on posting. I am always way too busy for non-productive stuff.

On the other hand, pretty much like GitHub itself, there is some true value in archiving and organizing images, results, etc… of projects you’ve worked on, even if just to build some sort of “historical archive” of your journey as a researcher.

I am certain that I won’t be updating this micro-blog often (if at all). Mostly because my R&D and management work at RandomControl (Maverick Render) leaves me with basically no spare time. But I will try to “now and then” drop here some 3D/2D/physics code experiments and such.

I will start by transporting (some of) my very old chemaguerra.com blog from 2011 to micro-posts here.

Godspeed!