How to prove that finding a cycle in a cryptographic hash function is hard? I want to show that finding cycles in a cryptographic hash function is hard.

My thought: assume there a black box, that given a cryptographic hash function $h$, finds some $x$ and $r$ in polynomial time, such that applying $h()$, $r$ times gives $x$:
$$ h(h(h\ldots(h(x))) = x $$

Can this be used to prove the function is not collision resistant or pre-image resistant?
How to prove that finding a cycle in a cryptographic hash function is hard?

In a uniform random function on a space of $n$ elements, the distribution on the length $s$ of a chain starting at any $x$ before it repeats, i.e. the smallest $s$ such that $h^s(x) = h^{s - q}(x)$ for some $q &lt; s$ or equivalently the number of distinct elements in $\{x, h(x), h(h(x)), \dots, h^{n - 1}(x)\}$, is $$p(s) = \frac{(n - 1)! \, s}{(n - s)! \, n^s},$$ whose expectation grows with $\frac 1 2 \sqrt{2 \pi n}$ (Harris 1960, Eqs. 3.2, 3.4, 3.11; paywall-free).*
Standard collision search algorithms work by following such a chain with a tortoise–hare algorithm to find the point where a non-cyclic initial chain coincides with a cycle.  But your black box somehow finds just the cycle without any initial chain.  Although the distribution of cycle sizes is weighted more toward smaller than larger cycles with expectation $\frac 1 4 \sqrt{2\pi n}$ (Harris, Eq. 3.11), the number $q$ of elements that are themselves on cycles has the same distribution as $s$ (Harris, Eq. 3.12).
For, e.g., a 256-bit hash function as you need for the standard 128-bit collision resistance, the expected probability of stumbling upon an element on a cycle by chance is about $2^{-128}$.  Even for a 128-bit hash function like MD5, although the expected probability of stumbling upon an element on a cycle by chance is about $2^{-64}$, the expected cost of confirming that it is on a cycle is $2^{64}$ steps, for a generic algorithm, although maybe there's a clever way to speed this up in batch or in parallel like the van Oorschot–Wiener collision search machine.
If, for some particular $b$-bit hash function aimed at random oracle applications like SHA3-256, you found a way to find an element on a cycle with substantially higher probability than $2^{-b/2}$, or a way to confirm whether an element is on a cycle or not with substantially lower cost than $2^{b/2}$, it would likely be worthy of publication and cast serious doubt on the security of the hash function.

My thought: assume there a black box, that given a cryptographic hash function $h$, finds some $x$ and $r$ in polynomial time, such that applying $h()$, $r$ times gives $x$:
$$ h(h(h\ldots(h(x))) = x $$
Can this be used to prove the function is not collision resistant or pre-image resistant?

It is not a priori clear that this black box is helpful for finding collisions or preimages: clearly it does not itself find a collision, and it's not parametrized by an image for which it could find a preimage.
Of course, the field of generic collision search is a black art underlying a surprising array of cryptanalytic attacks including the usual hash function collision search, Pollard's $\rho$ for factorization, Pollard's $\rho$ for discrete logarithms, hash function preimage search including AES key recovery, and so on.
So it would not surprise me if a black box with this capability could be fruitfully used to accelerate a generic collision search, or if it could be proved not helpful, but it would be an interesting theorem either way!

* Harris 1960 is an excellent compendium of probability distributions for various quantities in various important types of random mappings.  Read it!