Well, they can't ban 1-bit random number generators (e.g. coins) and with a bit of time, you can simulate any of dice used in RPGs.
24d10 becomes 0-240, so change it to 0-256 and you've got 8 flips (8d2?)
Distribution won't be correct but hey, 8 flips
24d10 is 24 independently rolled d10's, that means we convolute the uniform distribution with itself 24 times and the result will be nearly indistinguishable from a scaled bell curve.
Edit: Click the “Graph” button here to visualize: http://anydice.com/program/4ddf
For large dice counts like that, it's probably better to just use a manual table for a bell curve based on ~8-10 flips. No human player is going to care about result fidelity beyond a thousand possible results anyway.
That gets you to 4.48 amortized flips per d10.
Above 3d10 the rate of re-rolls increases; 20 flips for 6d10 gives a worse amortized cost than two sets of three.
This has the guaranteed correct distribution ('correct' being 'uniform'), too!
EDIT: I guess, to be more clear about the algorithm: flip 8 coins and convert this result to binary. If the result is greater than 240, flip the eight coins again. The number of total 8-coin-flips that need to be done on average is something like 1.062, and the likelihood that you need to perform n 8-coin-flips to receive a result ≤ 240 vanishes exponentially as (15/256)^(-n).
EDIT: I screwed up again, 24d10 is 24 dice with 10 values. Oops. Point is still roughly the same!
For the more common case of a d20, you could do 5 coin flips, but doing 6 instead gives you much more wiggle room. In that case, you only have to ignore values [60,63] so you only have a 1/16 chance of needing to redo the coin flips. It would be tedious but doable (particularly if you had some system where you could prepare rolls while waiting for your turn).
d4 = 2 flips guaranteed, definitely not bad. d6 = 3 flips expected. d8 = 3 flips guaranteed. d10 = 4 flips. d12 = 4 flips.
For something more typical but still nasty, a Fireball with 8d6 would take ~24 coin flips. Also, if I were a prison DM in this situation, I would probably take the time to homebrew the system so it only uses power of 2 rolls, i.e. d2, d4, d8, d16, and maybe d32. I would probably do d16 instead of d20 since d32 would be rolling 5 rolls quite often and a d16 is closer to a d20.
Overall, the difficulty would not be the coin flips but doing the math to keep track of everything.
Even if they restrict you from doing that, another option would be to do some sort of manual pseudo-rng. That option would probably be faster if you have access to a scientific calculator.
You could even insure an even distribution and have like 1-6 in there 4 or 5 times (if it's a d6), and don't return the slips back to the pile until the pile is depleted.
Or you can do what I've done for testing pen and paper game designs where a die wasn't handy, and do the above and write the series of results down in a list on a separate paper, and then refer to the next number in the list when you're playing.
I even did it where I put the numbers into several 4 by 4 square grids, and would simulate different games by picking the next number by from the grid but going from different directions (left, right, up, down, etc).
Some people get really mad with true randomness and think the system is rigged. Something I've learned when designing video games. Settlers of Catan have Dice Cards they sell for people who hate that "the 4 alwaaaaays gets rolled and my 8 didn't get rolled once, that's bullshit!"
d4=2 bits+1, d6=3 bits rerolling 0/7, d8=3 bits+1, d10=4 bits rerolling 0/11-15, d12 similar, d20=5 bits rerolling 0/21-31. I suspect that most gamers could pick that up pretty quickly with just a bit of practice.