Starting from Remus Rusanu's answer, I will make clear and complete some informations..
First before starting the backup process, a mark is done into the transaction log file to indicate that a backup will begin.
Full backup contains both the data and log. For data, it simply copies all the pages of the database that have "records" inside, in any order, into the backup, as is at the moment it reads the page, and can use a parallel processing (a fuzzy logic algorithm is used for ordering the pages, taken from the memory when it is in cache or from the disk). It then appends into the backup media all the 'relevant' log, from the beginning mark, to the last moment of page copying. This includes, at the very least, all the log between the LSN at the start of the backup operation and the LSN at the end of the backup operation. In reality there is more log usually, as it has to include all active transactions at the start of backup and log needed by replication. See Debunking a couple of myths around full database backups.
Last, a new mark is done inside the transaction log to indicate the end of the backup process.
When the database need to be restored, first the process read the very first pages of the backup that contains the physical database organization (files and filegroups ak "storages") and create a physical similar organisation of empty files. Then all the data pages are copied out into the database files, then all the log pages are copied out into the log file(s). The database is inconsistent at this moment, since it contains data page images that may be out of sync with one another. But now a normal recovery is run. Since the log contains all the log during the backup, at the end of the recovery the database is consistent.