Revising CRC value after data adjustment
1) Yes

2) It's complicated.

The CRC is a linear operation on GF(2) (GF(2) is just the fancy discrete-math way of saying binary, added modulo 2).  So each bit of your 32 bits will have the same effect on your two CRCs in the add-modulo 2-sense.

The really bone-headed (but possibly good enough) way to do this is to have a table of 32 32-bit words.  For each bit in your field that you flip, XOR the CRC with the corresponding word from the table.  That should work just fine.  The actual words in that table are the CRCs for the whole data stream with every bit but the bit in question set to zero.

There are alternate ways to do this -- you could have four tables of 256 words each, for instance, with each byte of your 32-bit variable field selecting one word from its corresponding table.  That saves you XORs at the cost of keeping the table in memory.

If it works, you probably want to generate your long message with that variable section set to zero, then you won't have to compute which bits have flipped, because you know that whatever bits are set to 1 in your replacement variable field are the flipped bits.

Going from an n-bit CRC backwards to an n-bit field that you can freely set should have the same linearity property; if you can tack some bits on to the packet after your desired message you should be able to decide ahead of time what you want the packet CRC to be, and then set it after the fact.  Or you can do the same trick I mention above, with each bit in the message corresponding to a different 32-bit pattern in the free space that you need to toggle.