Destroy GPT partition scheme absolutely, how?

I ran into a very nasty and time consuming problem. Creating a NanoBSD
image with a modified script framework creating GPT partitions, I put
the imaes via "dd(1)" on USB flash or SD flash. Because the images are
usually much smaller than the overall capacity of the USB or SD, the OS
(FreeBSD CURRENT, recently built as of this morning) complains about
the second GPT header isn't in the last LBA. Sometimes, my PCengines
APU2 doesn't boot then, a relief is to issue the command 

gpart recover da1

(in that case, the USB flash drive or SD flash is recognized
as /dev/da1).

But I run into a nasty situation, if the image put to the flash is
somehow corrupted. Then I tried to write a second, repaired image over
the first one using dd(1) again and do a recovering as mentioned above
- but this is fatal in two ways. First, the corrupted/broken GPT seems
to be "recovered" and put in replacement of the correct one - so I
guess. Performing no recover leaves the image on flash corrupted
anyway.

Well, to be honest, I didn't exactly know what is going on here. The
phenomenon is that I had a problem creating a NANO_DATASIZE= DATA
partition with an empty NANO_DATASIZE which somehow corrupted the
whole image. The image then never booted, complaining,
that /foo/bar/_.mnt was unmounted unleanly.

This happened multiple times, even if I tried to overwrite the SD or
USB flash with /dev/zero or /dev/random data, but I do stop such a dd
after a couple f minutes, since the SD is 32GB in size and the USB
flash drive is 32 GB, 64 GB and 128 GB - a pain in the ass if you want
to write via USB 2.0. But even with overwriting with a good image then
results in a corrupt image on flash drive, complaining about the GPT
second header not in last LBA and the issue with the uncleanly
unmount _.mnt (from the creation process of the NanoBSD image)! 

So I guess there is something magic happening. Some informations are
not lost and I suspect the "recovery" moving those foul data into
active places.

Using a fresh/new SD or USB resolves the problem. But the question
remains: how can I destroy any relevant GPT information on a Flash
drive (or even harddisk) to avoid unwanted remains of an foul image
installation? 

First guess was to write the last couple of bytes on such a flash drive
by letting dd(1) counting backwards, but I couldn't figure out how to
let dd(1) do such a procedure. The nightmare didn't end, while trying,
the SD flash card died :-(

thank you very much for your help and thoughts.

Kind regards, thanks in advance,

oliver