It depends on what you mean by "crack". If you meant "decipher", as you hint in your question's detail, then, it depends on your implementation of the cipher.
From a purely mathematical POV, OTP's are indecipherable. But math isn't the only thing that keeps the ciphertext safe: there's the implementation of the cipher, implementation of the key, management of the key, the hardware used in the implementation of the cipher, and social aspects of the key and the plaintext.
There are many ways to crack ciphertext.
As to cipher implementation, if you used non-true random numbers, bits of the key could be deduced, and if one had access to the kind of plaintext originally enciphered, it might be possible to deduce more of the key. For instance, knowing that the plaintext was a text document, or an executable, that can help decipher more of the ciphertext.
As to key implementation, if you reuse the key within the algorithm (for example, you use a key shorter in length than the plaintext, then start at the beginning of the key again), that is a death knell to the ciphertext. In a whitebox crack, having access to the algorithm being implemented, this can give away whether you started to reuse a key from the beginning, the end, every other character, etc, and that's more information that can be used to decipher.
As to key management, if the key were stored on your hard drive, it's a only a matter of time before that key is found. You might store the key on a piece of paper - but where do you put that paper? And what if the thing you're encrypting is over a megabyte in size - you gonna type all that in (error-free)?
As to hardware, getting actual random bits is part of it. But storing the key, storing intermediate data during the enciphering process, and what happens to the original plaintext once it has been enciphered is an issue. If you have a text file containing the password to your Netflix account, then you encrypt it with OTP, then use a right-click and delete for the original text file, you've not secured anything.
As to the social part, having someone surreptitiously install a key logger, video camera, drug you, phish you, or otherwise trick you into giving up the content or location of the cipher key is another way to "crack" a code.
Sometimes, and I guess this applies to any attempt at decipher no matter the algorithm, having access to partial plaintext, or the kind of plaintext it is, is enough to get the rest of it. Such might not stand up in court if you were accused of peddling state secrets to the enemy. There are times when that is all that's needed, especially if it can be proven. Example: the netflix password is known to be four digits; if partial decipher leads to three of the 4 digits because you didn't use a truly random number generator, then it's trivial to brute force your way to the missing digit. The proof? Just use it and see if it works.
The length of ciphertext is also helpful information. If you were under investigation of downloading illegal music, 1MB enciphered files would probably be interesting. Files that were a few kilobytes - or a few gigabytes - in length would probably be ignored, unless the investigator also had access to the implementation source, and determined that the file size of the ciphertext was also part of obfuscation.
Having access to the metadata - the kind of plaintext being enciphered - can also help. If it is known that the plaintext was an executable or a text file, then, partial decryption can rule out some bits.
OTP's are mathematically proven unbreakable. But that's not the whole picture, and is never the only consideration in cracking ciphertext. The important details (isn't the devil always in the details?) are in the implementation of the cipher, hardware, key management, and social aspects of it all. Each of these things are just as important as the other in ensuring the security of the ciphertext, and poor implementation of any one of them can give away the plaintext.
A chain, they say, is only as strong as its weakest link.
As to randomness... it is true that today's PC's are only marginally better than its predecessors at generating truly random numbers - which is to say they can't. But that's not entirely correct, either. It depends on the effort needed to get a random number. If you used a chip completely dedicated to throwing out a random bit, then I'd say that the result isn't looking good. Computers, after all, tend to be consistent in their output. But if the algorithm relied on analog data, such as room or CPU temperature, the current nanosecond (tick) in the day, or the typing speed of the operator, or the selection of nth character an operator is asked to randomly type in, etc, that can create true random results - but at a strong cost of time and effort to implement it, and some users may not want it.
OTP's are very sensitive to the randomness of a result. It isn't that 11111111 is any more or less random than 00101101; rather, if it can be deduced that every 8th bit, for example, is always a "1", then that is helpful to someone cracking your ciphertext. Knowing patterns like this can give away the implementation of the algorithm, which in turn could give up more information about other bits that can be deduced. In this case, knowing that bit 8 is always "0" might give away that the plaintext is text (as opposed to binary).
OTP's are not always the best algorithm. Such is a double-edged sword.
If you were charged with a crime - say, possessing state secrets - and the prosecutor knew you used OTP, and the prosecutor was unscrupulous, he can make up a "key" to decrypt the ciphertext, and show made up state secrets in evidence against you.
You could do the exact same thing, except produce a different key to decrypt the ciphertext into a recipe for blackened chicken wings.
What you have both proven is that the evidence presented is doubtful without additional supporting evidence: The prosecutor will need your actual key, as well as the ciphertext and plaintext, and prove you were in possession of all three. In addition, he'll need to prove you possessed no other OTP key.
So in theory, you could leave two OTP keys completely visible in your My Documents folder, one decrypts to the state secrets, the other decrypts to the blackened chicken wings recipe. He'll have a lot of explaining to do in order to convince a judge and jury that a single ciphertext is BOTH the damning illegal state secrets, as well as a useful and tasty blackened chicken wing recipe.
With any other algorithm, the prosecutor needs only the cracked ciphertext (plaintext) - and the key is irrelevant. He doesn't even have to show that you possessed the key, or even the plaintext, since there can only be one key, which can only lead to the state secrets.
In cases like this, it is irrelevant whether or not your ciphertext is crackable, or the algorithm is crackable: even if it were, additional supporting evidence is needed. In fact, it would seem that a prosecutor would not want to mention anything about the ciphertext - even with the "actual" keys (note plural) in plain sight.
Besides the prosecutor scenario, this could be an employee/employer scenario - being in possession of health records. Or being in the middle of a nasty divorce.
It could also be the case that the ciphertext yields similar outcomes: for example, there are 10,000 OTP keys, each produces plaintext to a different key to your Netflix account. Someone trying to steal your Netflix account will have a better time with brute force than to figure out which of the 10,000 keys you're really using to hide your Netflix password.
Any time you have a scenario where having one ciphertext which produces multiple useful or intelligible plaintext, which OTP's can do, you have a use for OTP's (or a headache... if you were the one having to decide which is real and which is the red herring).
Full disclosure: I'm no lawyer. Nor do I have any experience in the field of law. So my answer relating to law is just an opinion.