One way to potentially get dirtycow to actually replace files in memory instead of letting them die when the device reboots, is to patch a file and have it's size remain exactly as it was. Like you said.
If you remember some of my PM's from a few months back I did mention it then as well. Having the file sizes differ like they do, is actually part of what causes the system panic in the first place.
This is why when patching with dirty cow, lets say the "build.prop" file, if we remove a character from the prop file and fail to add another character back, the file size will differ. Add lines to the prop file, and the file size will differ.
My best theory on the whole thing is change a couple lines of the text and keep the same character count throughout.
If you want to change the build type from "user" to "userdebug" we will have to find 5 characters to remove from the build.prop to make up for the fact that we are adding the five character word 'debug'. The best bet here would be to try and shorten a commented line close by to keep the character count in the file the same.
But at the same time, if we are trying to shorten/remove lines from that build.prop file to make the project work, we may then need to add useless comment lines to make up all the characters we deleted with our patch.
It is possible to dump the dirtycow memory back to disk by mounting the system partition R/W, AFTER we have made the patches. I've read that mounting the system partition RW will actually dump memory back to disk.