This is easiest to do on a Windows laptop. You’ll need a program called Forscan and some method to connect to the car. I’ve successfully used a VXDIAG VCX Nano and an OBDLink MX Bluetooth. Making these changes will require the extended licensing for Forscan, which is only available in the Windows version. You can get a 2 month free trial by registering on their forum and using this form.

Another very useful tool is the AsBuiltExplorer. It can calculate the checksum bits and performs analysis on the As-Built files for various cars. It also has a hex to bin converter.

The last two hex digits in each line are the checksum. If you’re sure you’re making all the other changes correctly, you can ignore them and click yes for the error message that will pop up when you write changes. There are a few cases where I’ll represent the checksum with “XX” because I didn’t keep track of it.

Your As-Built data may be different from mine and the other examples. The important thing to pay attention to are the bits that I’ll mark for each change. Use a hex to bin converter like the one in the AsBuiltExplorer if you need help figuring out what bits you have enabled and what to type into Forscan.

Keyless Entry
I found instructions for this here and here.
You’ll need compatible remotes. I got these keys to work with remote start as well.
To enable the factory keyless entry, you’ll need to change the appropriate bits in two different modules. After writing each change, you’ll be prompted to cycle the key off and back on.
BCM 726-18-01 from 0000 0000 46 to 0100 0006 4D
IPC 720-01-03 from 8008 0000 B3 to 8088 0000 33

726-18-01 0000 0001 0000 0000 | 0000 0000 0000 0110
                  ^                             ^^

720-01-03 1000 0000 0000 1000 | 0000 0000 0000 0000
720-01-03 1000 0000 1000 1000 | 0000 0000 0000 0000
                    ^

Once these changes have been made, you’ll need to program the keys. The instructions I found are as follows:
Close the driver’s door, then using the buttons on the driver’s door lock, unlock, lock, and unlock the doors.
Cycle the ignition key off to on 8 times, ending with the key on.
The locks should now cycle. Each time this happens you have 20 seconds to complete the next action.
Press any button on the first remote, the locks will cycle to confirm.
Press any button on the second remote, the locks will cycle to confirm.
Continue with any additional remotes (up to 4 total, I believe) or turn the key off to exit programming mode. The locks will cycle again to confirm leaving programming mode.

AWD gauge
Information on this came from here.
IPC 720-01-02 from 8A14 0003 3D08 to BA14 0003 3D38

720-01-02 1000 1010 0001 0100 | 0000 0000 0000 0011 | 0011 1101
720-01-02 1011 1010 0001 0100 | 0000 0000 0000 0011 | 0011 1101
            ^^

Enable Aux Input Without Sync
I found a little information in this guide for enabling Sirius. The rest was trial and error. There is also some hardware required. An expensive cable is available from fordpimods.com. I used this cable instead, but the pins aren’t a direct fit with the connector in the Ford. I’m temporarily using some 2.54mm female crimp sockets. They’re a loose fit in the connector, but fit snugly on the actual pins. I found the pinout for the connector in this post.
FCDIM 7A5-01-01 from 0001 9000 205F to 0001 1000 20DF
Bit 16 disables aux, set to 0 to enable.

7A5-01-01 0000 0000 0000 0001 | 1001 0000 0000 0000 | 0010 0000
7A5-01-01 0000 0000 0000 0001 | 0001 0000 0000 0000 | 0010 0000
                                ^

Remote Start
You’ll need compatible remotes, and you’ll either need to have factory keyless entry or follow the procedure above to activate it. I can confirm that these keys work.
You’ll also need to install a hood switch if your car doesn’t already have one. The wiring and connector will be there even if the switch isn’t.

I found a little information on enabling this feature here. The rest I figured out with the AsBuiltExplorer tool and a little trial and error.
BCM 726-19-01 from 0047 to 0148
IPC 720-01-03 from 8088 0000 to 8088 00C8

726-19-01 0000 0000
726-19-01 0000 0001
                  ^
720-01-03 1000 0000 1000 1000 | 0000 0000 0000 0000
720-01-03 1000 0000 1000 1000 | 0000 0000 1100 1000
                                          ^^   ^

Additional Options in IPC Module
Not all options are actually available or functional, these are just the bits to enable them under the IPC’s Settings screen. There appear to be some interactions between these values and the ones in 720-01-02. I’ll update soon with a little more info on this, and as I have time to experiment more with them.

720-01-03 1001 0000 1000 1000 | 0000 0000 1100 1000
720-01-03 1011 0110 1110 1100 | 0000 0000 1100 1000
            ^^  ^^   ^^   ^

The marked bits activate the following options:
02 Auto High Beam
03 Autolamp Delay
05 Easy Entry
06 Remote Windows
09 Auto Lock
10 Auto Unlock
13 Rain Sense Wipers

I created this branch for some of my own development. Since some others might be interested in it I decided to make it publicly available. I have only been running it on my own experimental boards, but it should work on the other F4 targets as well. I’ll try to do bugfixes for other targets if I get feedback, but I am unable to test any of them myself. You assume all risk by trying it, and I highly recommend testing everything with a current limited power source and no props first, just to be safe.

Where to get it:
Source
Release 2.6.0

Installation:
For wiring refer to Raceflight documentation.
Make sure proper STM32 VCP and DFU drivers are installed.

OPBL targets should be able to flash using bin files as normal.

For .hex files use Cleanflight Configurator->Firmware Flasher
If flashing from an OPBL target or unflashed board, follow Recovery/Lost communication instructions in configurator.
Use ‘Load Firmware [Local]’ to select your target’s hex file, then flash.

Configuration:
Refer to Cleanflight and Betaflight documentation.

Setting looptime in configurator will currently work up to 8kHz.
Acc is always enabled on F4 targets with SPI, gets disabled over 2.6kHz on I2C targets.
PID is capped at 2.6kHz for Oneshot125 same as Betaflight.
PID is capped at 4kHz when Oneshot42 or Multishot is enabled.
PID cap can be manually overridden in the CLI by lowering pid_process_denom. (min is 1)

Known issues:

• Configurator connection trouble: As I understand, this is an operating system related issue with the drivers for the VCP. My mac has no problems, but my linux machine does. After connecting the USB or restarting the board I have to wait 20-60 seconds before the configurator will connect. I don’t have personal experience with it, but I believe Windows problems similar to what I have with linux.
• BLHeli Passthrough: (all methods) Reading and writing settings works, but flash new image usually fails (>90% failure rate).
• CLI dump: You only get the last part of the data when large amounts are sent. This only happens on VCP. I haven’t tracked down the exact cause, but I’m assuming it’s related to the buffers.
• Revo nano: There are reported problems with this on Raceflight. They will likely exist here as well. I’m willing to try to fix this, but I don’t have the hardware to test.
• Issue with USE_SERVOS and QUAD_MIXER_ONLY: Specific settings are required in all target files or compilation fails. Proper fix will be to deal with this in code, but for now setting the tags in target files works.
• Misc compile warnings

I tried formatting the sdcard (normally just delete logs and leave config.txt) and I’m still having the same problems. I also tried some different sdcards with no luck.

I had previously looked at the headers and everything seemed fine, but your mention of them made me look more closely. I see that random data was missing from the middle of the header in some logs, and simply cut off early by data in others.

I figured out that the specific problem was gyro scaling, but there was quite a bit of other info missing too.

my temporary fix: Get a log in angle mode with settings as close as possible to the log I want to fix and copy its header into the log with problems.

Did some more testing. Tried going back to old commits and using cleanflight master branch, and still had problems with them. Since it looks like this isn’t a betaflight problem like I had originally thought, I did some more looking and found the appropriate rcgroups thread.

Solution was found in this pull request.

Manually merged changes into latest betaflight.
There was a problem on one line because it references masterConfig.looptime.
I just set it to a static value based on the looptime of 1000 and compiled it.

<< blackboxMaxHeaderBytesPerIteration = constrain((masterConfig.looptime * 3) / 500, 1, BLACKBOX_TARGET_HEADER_BUDGET_PER_ITERATION);
>> blackboxMaxHeaderBytesPerIteration = constrain(6, 1, BLACKBOX_TARGET_HEADER_BUDGET_PER_ITERATION);

Flashed the flight controller and logs are back to normal.