Most likely not; the flash protection is not done by the firmware, but by the Intel Management Engine and a public key burnt into silicon (Intel Boot Guard).
The current exploit only runs far later, after the validation is performed. So unless you manage to mangle the code execution flow of the authentic firmware to the point that it skips the whitelists, you can't get rid of it.
On X220 and previous, the whitelist is removed by creating a modified version of the BIOS without the included whitelist, then flashing it to the BIOS chip. Technically, this can still be done on X230, but as it has the flash write disable unless a signed Lenovo image is to be flashed, the user must desolder the BIOS chip and flash it with the modified image using an SPI chip flasher. As this exploit can remove this flash write protection, perhaps a modified BIOS image can be flashed from the system itself, bypassing the Lenovo signature check?
Huh, here[0] is a a tutorial on removing the whitelist for the X230, via desoldering and an SPI flasher. Looking at the images, the chip looks like an SOIC-8. I wonder why they didn't just use a test clip like this one[1]...
EDIT: The obvious answer would be that they didn't have one handy and were competent enough that de- and re-soldering the chip was not a big deal.
EDIT (again): Also, they wanted to flash a NEW chip with the contents of the original so that they could fall back to the original in the event of failure.
>I wonder why they didn't just use a test clip like this one
Because they tried and it didn't work (third post). It seems to depend on the mobo as well as the programmer you're using, but sometimes SPI programming without removing the chip doesn't work, which has to do with the mobo consuming the power you're supplying to the chip. Some people work around that by supplying separate power but even then it's a crapshot.
Huh, interesting. I managed to do it successfully on my X201, but only after supplying power through the RasPi I was using to flash it (no power to the board, battery and clock battery disconnected, though I doubt the latter was necessary).
The current exploit only runs far later, after the validation is performed. So unless you manage to mangle the code execution flow of the authentic firmware to the point that it skips the whitelists, you can't get rid of it.