Broke my journey up the M6 to find the 2021-08-29 54 -2 geohashpoint, which was deep in the brambles alongside the
towpath about 90m South East of the cache location. On the way back up to the road, quickly stopped to find this cache. SL, TFTC!
I (Dan Q) am driving my partner’s brother Robin from near Oxford to near Penrith on this day, so I expect to
pass close by this geohashpoint on the M6 twice; at around 13:00 going North then about 15:00 going South. It looks like there’s on-street parking on nearby Ashford Avenue (N 54° 1.71′,
W 2° 48.370′), so I’m thinking we can pull over there, walk to Deep Cutting Bridge, follow a path about 700m Northwest down into the canal cutting, then follow the canal back Southeast
to the hashpoint. Robin’s never been geohashing before, so we’ll see what he makes of it.
The biggest risks to this plan are likely to be (a) if we run late setting off, hit traffic, or are otherwise delayed then we may have to cancel our plans in order to stay on-schedule,
and (b) based on local photos it looks like the towpath floods and/or gets incredibly boggy in wet weather!
Expedition
This all went pretty-much to plan. We parked on Ashford Avenue and walked to the bridge, then onto the long path down. We soon got bored of this trail and took a short-cut down the
cutting slope, then proceeded back under the bridge while Robin told me about how he rowed along this stretch of canal during his recent Lands End to John O’Groats journey.
On the other side of the bridge we discovered that the hashpoint was about 25 metres up a steep bank covered with thorny plants. Not wanting to be defeated at this point, Robin boosted
me up onto the bank and I scrambled painfully through the brambles to reach the hashpoint, which coincided with a tree overlooking the cutting.
Returning to the car we stopped by geocache GC6WMEW, from whose GZ one can just about see the tree that
marks the hashpoint. We added a “The Internet Was Here” sign to the gate at the path down to the towpath and continued our long journey North-and-back-again.
I’m spending the day helping my partner’s brother Robin move from Oxfordshire to Cumbria, then heading back South to Lancaster to try to find the 2021-08-29 54 – 2 geohashpoint before finally heading to Preston to visit my family. In short, its a day with
lots of roads! We stopped at the services to let Robin empty his bladder and I took the opportunity to make an easy find of this cache. TFTC!
Finding this cache finally “completes” for the Constellation series, which I began back in 2014! Okay, that’s not quite true because GC1TPTP (Constelations 9) could yet return to service and then I’ll need another trip to get that one… but it still
feels good to come back and wrap up what I started so long ago.
The blackberries are plentiful down this path and I found my stomach rumbling: time to go home for a proper breakfast. The cache container itself is in plain sight – looks like its camo
wore off long ago! – but is otherwise looking great. TFTC, and the series as a whole.
I was glad to be cyclecaching today when I reached this one, because the edge of the village was a perfectly innocuous place to be seen to pull over with my bike and sit down for a
rest. The passing motorists seemed completely uninterested (although possibly glad that they didn’t have to overtake me) as I found and retrieved the cache.
The retrieval was an adventure in itself! I was very glad to have brought my tough geotweezers with me, because a narrow but sturdy tool was absolutely essential for gradually working
the cache out of its hiding place. Returned it as-found, so I certainly hope that the next cacher is equally well-equipped!
My fourth cache of the day was easy to find… but hard to retrieve the logbook from! The inner bag contained not only the logbook and pencil but also some geotreasure, and this had
settled into a configuration that made it almost impossible to fit through the neck of the cache container! After some massaging and poking (including through the hole in the bottom of
the container) I was able to persuade the logbook to come out, sign it, and move on.
A shame that this one was still absent as I toured the area – attempting to “finish” the Constellations series I first attempted many years ago! Hopefully if it returns I’ll be able to
come down again.
Seven and a bit years ago my old geocaching buddy presquevu and I attempted half of the Constellations
series (which was in a bit of a different configuration back then) and this morning I finally decided to cycle to Standlake to complete it. In the meantime, though, this cache has
sprung up, so I decided to pick it up as well.
I spent about 10 minutes hunting for this cache before I saw it: turns out I’d been mostly looking up the wrong part (and, perhaps, looking “up” too much and “away” not enough). Luckily
it was quiet today – I didn’t see another soul at this early hour – so I was free to hunt in peace without need for stealth skills. This allowed me to detach the front light from my
bike and scan it around the search area to try to catch a glint of the container’s reflection under the dim cover of the surrounding foliage.
Continuing my morning quest to complete the Constellations series after a seven year pause, this was my second cache of the day. I’d cycled right past it on my way to Constellations 2,
where I’d begun my trail, so now I turned around to come back and find it. I briefly stopped at a bench on the way back along.
Found the cache quickly with the help of the hint; however this cache is in very poor condition: the container is waterlogged and the logbook beginning to disintegrate.
A little over seven years ago, presquevu and I enjoyed a walk around here and found what are now
Constellations 3, 4 and 5, among other caches which are no longer around. This morning, I decided, would finally be the time that I’d complete
the circuit! Nowadays I live just on the other side of Stanton Harcourt, so I took the excuse of a Saturday morning’s exercise to cycle down to Standlake and proceed up the path to this
first cache.
Apparently presquevu and I walked right past this one without making an attempt to find it back in April
2014: we were possibly distracted at the time and not paying full attention to the GPSr as we walked the path from Medley Brook to the
footbridge over the Windrush. This time, though, I honed right in on the hiding place and managed to retrieve the cache with a minimum of nettle stings and thornpricks.
As others have noted the cache container is looking a little worse for wear and has a significant hole in it. However, the waterproof logsheet is holding up remarkably well and was
still definitely signable. TFTC.
tl;dr? Just want instructions on how to solve Jigidi puzzles really fast with the help of your browser’s dev tools? Skip to that bit.
This approach doesn’t work any more. Want to see one that still does (but isn’t quite so automated)? Here you go!
I don’t enjoy jigsaw puzzles
I enjoy geocaching. I don’t enjoy jigsaw puzzles. So mystery caches that require you to solve an online jigsaw puzzle in order to get the coordinates really
don’t do it for me. When I’m geocaching I want to be outdoors exploring, not sitting at my computer gradually dragging pixels around!
Many of these mystery caches use Jigidi to host these jigsaw puzzles. An earlier version of Jigidi was auto-solvable with a userscript, but the service has continued to be developed and evolve and the current version works quite hard to
make it hard for simple scripts to solve. For example, it uses a WebSocket connection to telegraph back to the server how pieces are moved around and connected to one another and the
server only releases the secret “you’ve solved it” message after it detects that the pieces have been arranged in the appropriate relative configuration.
If there’s one thing I enjoy more than jigsaw puzzles – and as previously established there are about a billion things I enjoy more than jigsaw puzzles – it’s reverse-engineering a
computer system to exploit its weaknesses. So I took a dive into Jigidi’s client-side source code. Here’s what it does:
Get from the server the completed image and the dimensions (number of pieces).
Cut the image up into the appropriate number of pieces.
Shuffle the pieces.
Establish a WebSocket connection to keep the server up-to-date with the relative position of the pieces.
Start the game: the player can drag-and-drop pieces and if two adjacent pieces can be connected they lock together. Both pieces have to be mostly-visible (not buried under other
pieces), presumably to prevent players from just making a stack and then holding a piece against each edge of it to “fish” for its adjacent partners.
Looking at that process, there’s an obvious weak point – the shuffling (point 3) happens client-side, and before the WebSocket sync begins. We could override the
shuffling function to lay the pieces out in a grid, but we’d still have to click each of them in turn to trigger the connection. Or we could skip the shuffling entirely and just leave
the pieces in their default positions.
And what are the default positions? It’s a stack with the bottom-right jigsaw piece on the top, the piece to the left of it below it, then the piece to the left of that and son on
through the first row… then the rightmost piece from the second-to-bottom row, then the piece to the left of that, and so on.
That’s… a pretty convenient order if you want to solve a jigsaw. All you have to do is drag the top piece to the right to join it to the piece below that. Then move those two to the
right to join to the piece below them. And so on through the bottom row before moving back – like a typewriter’s carriage return – to collect the second-to-bottom row and so on.
How can I do this?
If you’d like to cheat at Jigidi jigsaws, this approach works as of the time of writing. I used Firefox, but the same basic approach should work with virtually any modern desktop web
browser.
Go to a Jigidi jigsaw in your web browser.
Pop up your browser’s developer tools (F12, usually) and switch to the Debugger tab. Open the file game/js/release.js and uncompress it by pressing the
{} button, if necessary.
Find the line where the code considers shuffling; right now for me it’s like 3671 and looks like this:
return this.j ? (V.info('board-data-bytes already exists, no need to send SHUFFLE'), Promise.resolve(this.j)) : new Promise(function (d, e) {
Set a breakpoint on that line by clicking its line number.
Restart the puzzle by clicking the restart button to the right of the timer. The puzzle will reload but then stop with a “Paused on breakpoint” message. At this point the
application is considering whether or not to shuffle the pieces, which normally depends on whether you’ve started the puzzle for the first time or you’re continuing a saved puzzle from
where you left off.
In the developer tools, switch to the Console tab.
Type: this.j = true (this ensures that the ternary operation we set the breakpoint on will resolve to the true condition, i.e. not shuffle the pieces).
Press the play button to continue running the code from the breakpoint. You can now close the developer tools if you like.
Solve the puzzle as described/shown above, by moving the top piece on the stack slightly to the right, repeatedly, and then down and left at the end of each full row.
Update 2021-09-22:Abraxas observes that Jigidi have changed
their code, possibly in response to this shortcut. Unfortunately for them, while they continue to perform shuffling on the client-side they’ll always be vulnerable to this kind of
simple exploit. Their new code seems to be named not release.js but given a version number; right now it’s 14.3.1977. You can still expand it in the same way,
and find the shuffling code: right now for me this starts on line 1129:
Put a breakpoint on line 1129. This code gets called twice, so the first time the breakpoint gets hit just hit continue and play on until the second time. The second time it gets hit,
move the breakpoint to line 1130 and press continue. Then use the console to enter the code d = a.G and continue. Only one piece of jigsaw will be shuffled; the rest will
be arranged in a neat stack like before (I’m sure you can work out where the one piece goes when you get to it).
Update 2023-03-09: I’ve not had time nor inclination to re-“break” Jigidi’s shuffler, but on the rare ocassions I’ve
needed to solve a Jigidi, I’ve come up with a technique that replaces a jigsaw’s pieces with ones that each
show the row and column number they belong to, as well as colour-coding the rows and columns and drawing horizontal and vertical bars to help visual alignment. It makes the process
significantly less-painful. It’s still pretty buggy code though and I end up tweaking it each and every time I use it, but it certainly works and makes jigsaws that lack clear visual
markers (e.g. large areas the same colour) a lot easier.
I happened to be passing through with a little time to spare so I thought I’d take another run at this one. Unfortunately my first attempt had seen me make my notes on the back of my hand (and I’ve washed them since then!) so I’d have to
collect the clues again. At least I already had the one from the church (thanks, CO!), so I parked at the Village Hall and went about (re)
collecting the others.
To my surprise, the pub seems have repainted its windows since my last visit: clearly in a specific effort to fool and confuse geocachers! Luckily I knew broadly where I was looking so
I wasn’t caught out.
Soon I was on my way to the cache. The hint was definitely needed as I hadn’t expected a container of this design in a location like this one! SL. TFTC, and special thanks to the attentive CO who provided an
extra hint for people who, like me, got stuck outside the locked church.
I needed to divert from my journey from Summertown to Eynsham anyway to stop at the nearby Sainsburys, so I took the opportunity for a quick stroll down to find this cache. Do you think
the nearby gate is always left locked-open? That seems surprising! A relatively quick find although some stealth skills were needed. SL,
TFTC.