Internal Exceptions in a BCB DLL?

Hi,

I have written a DLL with C++ Builder. Internal to the DLL, I throw and
catch exceptions, but take care not to throw them out of the DLL. The
DLL is built with all Debug options off and everything works fine.

I have also written a BCB application which links to the DLL. However, when I
run this from C++ Builder with the Integrated Debugging option on, an
internal DLL exception causes the application execution to break and
display a CPU Debug Window. What is the reason for this, and how can I
make it go away? I would really like my DLL to behave like a black box,
and not provide debugging hooks to other developers.

Also, is it possible that VC++ developers could be presented with this debug information?

Hope someone out there can help.

Thanks

Andy

Well, I'm not much into DLL's, but in compiling programs or extension with common sense indicates one would always have at least on debug option enabled if not more.

Yes I agree, insofar as that I may need to debug my DLLs, not others.

I seem to recall that Microsoft released a patch for NT several years ago, and left all the debug hooks in place. This allowed easy decompilation and led to the accusation that Microsoft was deliberately building in 'back doors' to Windows for use by the NSA.

Not that I have any dark secrets to hide, but I just want to produce a black blox release DLL version.

Among cryptography product companies, "Have you had a meeting with Lew Giles?" is code for "Has the NSA asked you to secretly weaken your product?" Giles has been known to visit companies and request that they add back doors to their products so that the NSA could break the encryption. The deal went something like this: Giles offered you preferential treatment for export if you would add a back door. The back door could be subtle enough that it wouldn't show up in the design, and only be obvious if someone analyzed the binary code. It could be something that would easily be viewed as a mistake if someone learned about it. Maybe you could weaken your random number generator, or leak a few key bits in a header. Anything that would let the NSA decrypt the ciphertext without it looking like the crypto was broken.

In return you would be able to export your products. But you and he would have to come up with some kind of cover story as to why you could export what was normally unexportable encryption, something that would allay any suspicion.

Giles was supposedly very smooth. He would try a variety of tactics to make you go along with this plan. Sometimes he would meet with just the engineers -- no management -- to try and circumvent potential problems.

I've heard this story from several cryptography companies, large and small. None of them were willing to talk on the record. All were visited at least two years ago; most were visited by Giles. None agreed to this bargain. (Presumably those who did would be unwilling to admit even talking to the NSA.) And all of these stories are at least two years old; I have no idea if Giles is still employed by the NSA, if he is still doing this kind of thing, or in fact if anyone is still doing this kind of thing.

None of this should be surprising. The NSA seems to have done whatever it could to add trap-doors into cryptography products. They completely subverted the Swiss company CryptoAG, for example, and for at least half a century have been intercepting and decrypting the top-secret documents of most of the world's governments. (The URL for this absolutely fascinating story is http://mediafilter.org/caq/cryptogate

This kind of thing happens in Canada, too. One name I've heard is Norm Weijer; a couple of years ago he visited several Canadian crypto companies. One person tells the story of submitting his product to Norm for export approval. The product used a number of different proprietary algorithms, all weakened to 40-bit. The word came back, unofficially of course, that if he would get rid of the proprietary algorithms and replace them with 56-bit DES, they could get export approval. Presumably using their existing DES crackers was easier than building unique crackers for this particular product. But of course, your not Lew Giles, are you?