There are some post regarding this and this was seen on a reddit/r/jailbreak page . And here is how  the restore process actually works.
Terms to be familiar with:
  • SHSH Blob - Apple's signature blob + your device's ECID, which makes the blob device bound.
  • APTicket - Apple's new type of SHSH blob, a singular file which contains the SHA-chunks of the IMG3/IMG4 files to be restored to the device and also is signed by Apple.
  • IMG3 - Apple's firmware image format used for iBoot, ramdisk, iBEC, boot logos, etc. for 32 bit devices (A6 SoC and older)
  • IMG4 - Apple's firmware image format used for iBoot and friends on 64 bit devices (A7 and newer, includes the Apple Watch)
  • Bootrom - First stage of boot on an iOS device. Implicitly trusted, and has Apple's Public Key, establishing a chain of trust. On A7 and newer, it's also responsible for nonce generation and verification
  • iBoot/iBEC - 2nd stage boot loader, responsible for bootstrapping the kernelcache and ramdisk.
  • LLB/iBSS - 1st stage boot loader, responsible for bootstrapping iBoot, and on 32 bit devices, responsible for nonce verification.
  • ApNonce - random number for AP to verify
  • SepNonce - random number for SEP to verify
  • NVRAM - Persistent memory where boot time values are stored like boot-command and boot-args
  • SEP - Secure Enclave on 64 bit devices that handles cryptographic operations, and maintains Data Protection even when the AP is compromised.
Now to get started, let's start with a DFU restore on 64 bit devices, since that's what most people will do when they restore:
  • First, the device will enter DFU mode, and the bootrom will generate a nonce for both the AP and SEP (Called ApNonce and SepNonce) and then will wait for iBSS to be sent.
  • Next the restore client (iTunes, PurpleRestore) will take digests of the IMG4 firmware files for the version to be restored and send them to gs.apple.com (The TSS Server).
  • The TSS server will either reply with an APTicket containing the ApNonce and SepNonce generated by the bootrom, and the signed SHA chunks of the files being flashed or an error message with status=94 which means you cannot restore to that version. On 64 bit devices, the ticket is stitched to all the IMG4 files being restored
  • The device will receive iBSS and will begin to request iBEC, and after iBEC is sent, it will check to see if the ticket is valid and matches the nonce. If both values are true, then iBSS bootstraps iBEC
  • Once iBEC loads, the restore client sends over the ramdisk, DeviceTree, and kernelcache image, all stitched with the ticket received at the very beginning. They are verified and then loaded. When a ramdisk is detected at 0xc0000000, the following strings are added to the boot-args buffer, so that the kernel knows what to do after it's booted. (Normally, the kernel boots the filesystem, but because we want to get to the ramdisk these boot-args are needed)
Boot-args: rd=md0 nand-enable-reformat=1 -progress -restore
(-restore is on iOS 10+)
  • Once the ramdisk is booted, the device will start a daemon called restored. It's basically a restore time version of lockdownd. It will check the ticket file, so even if you did manage to bypass APTicket checks for iBSS, you still have to deal with restored checking the hash. (though it's a non issue really) and then check and mount the user and system partitions. Then it'll wipe the NAND (not all of it) and make new filesystems for the user and system partitions. another check will be done and the restore client will send the root filesystem image to the device
  • ASR will now kick in and begin checking the root filesystem image it received from the restore client and restoring it to the system partition. After this another disk check is done.
  • The kernelcache is now written to the system partition along with the apticket.der file.
  • The firmware images are now sent to the device, and the device writes them to /dev/disk1 and /dev/disk2.
  • Persistent boot-args are cleared, boot-command is set to fsboot and the device is rebooted.
The only differences between a 64 bit device and 32 bit device DFU restore is the fact that before you send iBEC, an apticket.der must be sent to the device and that there's no SepNonce, so only ApNonce matters. IMG3s are used instead of IMG4s on 32 bit devices.
That's it! any questions, feel free to ask!

And the Following are  how OTA updates work,
  • First, the device checks the Apple update servers for an available update that's newer than the currently running version. Afterwards, the device begins to download the OTA update ZIP that applies for the currently running version.
  • Next, the device will begin to make a 3rd partition called the upgrade partition (Mount point is /boot in the filesystem) and place the RAMDisk, iBoot, iBEC, kernelcache and device tree there.
  • Now comes the important part. Since the device cannot request an APTicket while in recovery, it needs to request it in user land. The device needs some way to generate a specific nonce, and it does this by having the kernel make an NVRAM value called com.apple.System.boot-nonce and store a nonce "generator" in it. This generator allows the APTicket nonce to be predicted while in recovery. Once the APTicket is received and placed in /boot, the boot-command NVRAM variable is set to upgrade, and the device reboots.
  • Once iBoot enters recovery mode, boot-command upgrade is run, the upgrade partition is mounted, and iBEC will be loaded, and after that, the ramdisk, kernelcache, and device tree are loaded, and from here, the procedure is the same.