When you talk about proving something, all that scientific method stuff comes into play, and part of what that means is that if you are going to accept objective standards of deciding what's true, you must accept the possibility that, upon investigation, those annoying facts turn out not to be on your side.
In your case, I think there are 2 things to be proved.
First, that the current codebase is "bad". What you probably can prove is that "the professional opinion of nearly all developers that examine this code is that it's bad".
Second, that the company would be better off rewriting the codebase. This is a problem because even if the first point is true, the second might not be. Also, you don't know enough to make this determination. This is management's job, and if you want them to respect your professional judgement about the first point, you should respect theirs about the second.
But they can't make the determination about the second point without information you provide. You need to communicate what you know about how the problems in the code will impact the business, and what you know about how a rewrite would impact the business. This is difficult, since both involve predicting a future that has a lot of uncertainty.
But you can try to state the problem in business terms. How much extra time is spent on changes and regressions? What would a rewrite cost? How quickly will the costs of the current system go up over time if not rewritten? What if there is an increase in usage, what's the chance of a disaster if the current code is kept? You can't really know any of this, but you can give a better guess than anyone else. Give a range, or something to communicate how accurately you think you can predict these things.
Most developers do not like maintaining lousy code. Which is why it can be unfortunate that code that is a no-brainer to rewrite from a developer perspective may not be worth rewriting from a business perspective.
For example, even if the rewrite ends up profitable, it might be worth less than the opportunity cost of spending the money elsewhere in the company. Or the bad codebase might take longer to change and have more regressions, but not enough to make a rewrite profitable. They may be looking to get bought out in the next few months, and spending money on a rewrite will show up on the books but buggy software won't.
Try to think about it from the business perspective, and don't cook the numbers to get what you want. A big rewrite is almost never a no-brainer from a business point of view. If you want to prove something not directly provable, try your best to disprove it. If you keep trying your best to come up with a way not to rewrite from scratch but nothing you come up with makes sense, maybe then it's really time to rewrite from scratch. And making that effort will show your management that you are serious about representing the company's interests, not your own (you are representing the company's interest, not your own, right?).
