Jump to content

Wherigo Emulator


EANicolas

Recommended Posts

Hello Geocachers

At the moment I'm creating a Wherigo Cache with the official Wherigo Builder from Groundspeak.

I heard that you can somehow play a Wherigo in the Emulator that you don't have to go outside. If this is still the case, how can I prevent my Wherigo from that? And if not i'd be happy if you'd confirm that this problem occurded only some years ago.

Greetings from Switzerland

EANicolas

Link to comment

This has always been the case with Wherigo and I don't think it can ever go away. This is why:

 

You can do several things to prevent people from playing a cartridge in the emulator. You could ask a question that verifies someone is reading a sign. You could define an active, hidden zone that you know a player must pass through, but people dragging David (I believe that was the Lackey's name) around on the emulator won't. On the code side, you could check for altitude or the device's name ("desktop" is the emulator). There is also an author script for this in the pinned Author Script Index thread, if I remember correctly. At one time, the trend was to display the coordinates in an image, but those too can be extracted from a cartridge if someone has a good about of programming experience.

 

If you finish your cartridge in Groundspeak's Builder and port it over to Urwigo, Urwigo has some very nice emulator protection. It is by no means infallible, mind you. It took me two hours to come up with a way to modify the cartridge to allow it to be played in the emulator, though doing so required some technical knowledge. I'm getting better with finding and hacking the questions' answers as well, as this requires a small additional effort per question.

 

So there has to be some other way, right? I don't think so, not if you want to include a final zone in the cartridge. You see, when you load a Wherigo cartridge into a Player, one of the first things a cartridge does is register all its zones with the Player application. Thus, the Player knows where your final zone is at the start of the cartridge. A specially-created Player could then display a list of zones' names and coordinates.

 

-----

 

Do you follow me so far? I needed to say all of the above before I make my suggestions. Frankly, asking a simple question will usually deter most people from playing it in the emulator. For those with a little technical knowledge, make the answer be a number and compare it to a number. That will get most people right there. You could use Urwigo's protection if you think you have several very technical people in your area. Don't stress yourself out too much because I do not believe there are many people that would or could try to hack the cartridge. And you might also end up blocking some people trying to play with the emulator on a netbook in the field (because they don't have a cell phone or GPSr that can play Wherigo)--yes, I've heard of a few people doing this as well.

 

On one of my cartridges, I was downright evil. I created a cartridge that seemed easy to hack. If you played it in the emulator, it would refuse some questions' answers no matter what you would type, but it seemed an easy to get around check. However, this was a trap. If the check was circumvented, I would have the real check occur right after, doing something obscure you wouldn't notice in the compiled code. However, the real check would let people think they hacked the cartridge. It would just bring them to a plausible, but fake final location. It would even be named FINAL. If you tried extracting the images, I had an image with the fake final's coordinates ready for you. I was pure evil for my own entertainment. I knew going into the experiment no one in my area hacks cartridges or would probably try, so doing all this was just a fun little experiment for me.

Link to comment

Thank you for your long answer. Now I understand how to do it :)

But now the next question: How do I have to do it, if i want to give the Wherigo player only 20 seconds to go to the next Zone. The time should start if the player leaves zone 3 and the time should stop if he arrives at zone 4 in time. If he is to slowly, then he has to go back to zone 3 and do it again.

How can I do this?

I hope you can help me again.

Greetings

EANicolas

Link to comment

My "long answer". If you hang around here for any length of time, you'll discover that what I lack in brevity, I try to make up for in being thorough.

 

In short (ha, ha), you use timers. When a player exits a zone (there's an event for that), start the timer and disable the previous zone (to prevent the timer from being reset). Put the "you failed" message and code in the timer's "tick" event. Put the success code in the next zone's proximity event and make sure you stop the timer.

 

You can play with the source of a cartridge where I experimented with timers, Run to "The Outback" (most of my cartridges are open source). In this cartridge, a player must arrive at each zone on the trail in time. If s/he does not, the player must return to the previous zone and try again. I ran, jogged, and walked on this trail to get the times right. Later, when the associated geocache was published, I was curious how the group would play the cartridge, so I tagged along. They parked a mile away and brought bikes. I remember running myself ragged trying to keep up--and that was just on the greenway before the trail! The trail this cartridge is on is a highly technical mountain bike trail. That was the only reason I was able to keep up! Thus, never again will I accompany people on any timed cartridge I create.

 

But, anyway, take a look at the timers on this cartridge. I forgot whether I used author script or not (I created the cartridge a few years back), but it seems you might be able handle it if I did.

Link to comment

But if i try it this doesn't work. So now I have a few questions.

1) Why do I have to use the event "When the player is within proximity to a zone" and not "When the player enters a zone"?

2) What's the difference between " within proximity to a zone" and " whithin distance to a zone"?

3) When should I activate the Zone 4? When I am leaving zone 3 or when I enter zone 3.

4) The timer has to be 0 if I leave zone 3 and if i am in time the timer should still be 0 and then i have to press stop timer on the event " when the player enter a zone". And if I am to slow then the timer goes from the number 0 to 1 and shows a message. And then when I have to go back to zone 3 and therefore i have to activate zone 3 and display and put the story back to number 4 (which is the number story has when you first enter zone 3).

Is this correct or where is the fault?

 

:)

Link to comment

1) This is partially due to Garmin's mess-up as their Wherigo Player will require the player to get to zero meters/feet before the Player registers the player as being inside the zone. I'm still not sure how anything but the iPhone Wherigo Player handles proximity versus entry. I encourage proximity for compatibility's sake.

 

2) When a player approaches a zone there are two events, "distant" and "proximity". Distant is further out and is less frequently used. One thing about distant is you can have a zone become visible only when someone is that far away. Also, in the code, when someone leaves a zone, this can also fire. Setting the timer to begin when a player exits this zone (after entry) might be a good idea.

 

3) I would suggest when the player enters the third zone. This way, when the person is ready to get to the next zone, s/he will be able to tell in which direction s/he should start running.

 

4) You lost me at "The timer has to be 0 if I leave zone 3". I would have expected you to say, "The timer has to be 20 when I leave zone 3." This is the way I envision it: The timer starts at 20 seconds. When the player exits the third zone, start the timer. If the timer ticks, disable the fourth zone, tell the player s/he needs to return to the third, and enable the third zone. The timer is always reset when you call its Start event. When the player is within proximity (12 feet / 4 meters) to the fourth zone, start the timer and continue with your story. Again, I use proximity because, from experience, it feels like someone wants to make me suffer if I have to zero out to register my entrance into a zone.

Link to comment
Is earwigo or urwigo now better to prevent the Wherigo from being hacked or played in the emulator?

I'm not sure (and I don't even know how one would determine "better"), but any security measure is a question of how much effort is required to overcome it, not whether the security can be made absolute. As we've seen from the previous posts in this thread, the anti-emulation features of both Earwigo and Urwigo can be (and have been) hacked, if the user is sufficiently determined.

 

I would not let a small difference in the number of hours required to cheat on the cartridge be the main factor in deciding which builder to use. If this is a really big issue for you, combine the builder's protection with a trick like the invisible zone. If it's a bigger issue than that, then Wherigo is probably not for you.

Link to comment

For the general population, though, just asking some obscure question about a sign in the location is enough to deter them from playing in the emulator. You then have the added benefit of your cartridge being able to support those who still don't have a real Wherigo Player, but who are honestly trying to get by in their own way. I have some admiration for those people.

 

Personally, I'd prefer it if a cartridge allows someone to play partway through the story, just long enough for the player to see what the cartridge is about and become interested in playing it in the field.

 

Well, anyway, if you need more help or would like to ask something more, feel free to search the forum or ask.

 

(I'm going to have to update my Earwigo experience later, when I get some free time.)

Link to comment

Dear Wherigo Creators ;)

Now I've got a new problem.

The task (when the player clicks on this task) obviously doesn't work on garmins, but it works on iPhones and Androids. But most Cacher have a Garmin, so what can I do that my task work? (It's a Input task where the players have to put in a number)

Greetings from Switzerland

EANicolas

Link to comment

Ask the question when the person arrives at wherever the number is. Thus, the "Get input from a player" will be within the zone's proximity or enter event. Don't forget to deactivate the zone as soon as possible because if a Garmin Wherigo Player displays another input while the person is looking around, it will turn the device off. For example, if you have the input trigger when the player enters the zone, the player will move around while looking for the object with the number. The Garmin GPSr will move the player outside the zone, then back in at a later time, causing the same input to display, which in turn will cause the device to power off. Thus my suggestion to deactivate the zone as soon as possible so this problem will not occur.

 

Greetings from the east coast of the United States. It is hot over here!

Link to comment

Hi Nikolas, we have made the german Wherigo handbook, i think this helps a lot.

Here are listed important things too, you better never use, such as working with onclick events.

http://www.das-Wherigo-handbuch.de

"Eine Cartridge erstellen" > "Dinge, die vermieden werden müssen, da sie zu Fehlfunktionen bzw. zu Abstürzen führen"

Besides there are a lot of small and easy examples including urwigo source (Urwigo Builder > Programmierbeispiele/Codesnipsel). Especially the chapter "inputs" i think is what you are looking for.

Use an item with a command and then link it with an input.

Link to comment

Hello ;)

Now I think this is my last question and then my Wherigo is complete.

What do I have to do that the catridge is finished and the player gets an unlock code.

Do I have just to write a code in the final words or is this a special function where every player automaticly gets a different unlock code and if so how can I do this.

Greetings.

EANicolas

Link to comment

If you're using Groundspeak's Wherigo Builder, add something like the following in a message box:

Your completion code is: ]] .. Player.CompletionCode .. [[.  Please write it down for later.

 

Yes, the square braces are important to have in this manner. This is because you're tricking the builder into running code within its message box.

 

Other people tend to create a completion code item with the code as its description and stick the item in the player's inventory upon cartridge completion. I like this approach more because such an item will survive the cartridge being saved and resumed. Thus, a player can resume the cartridge to retrieve the completion code when s/he is logging online.

 

Make sure you also mark the cartridge as complete. This will be important later on because, when a Wherigo API comes out, Wherigo Players will be able to unlock the cartridge automatically for you.

Link to comment

Well, your cartridge listing had been marked as open source (bottom left size on the listing page). However, I couldn't download the GWZ when I clicked on the "Request Source" link. I thought you had meant for the cartridge to be open source, hence the confusion.

 

You can do anything with a GWZ because it contains everything needed to build the cartridge: images, audio files, and the source code. People typically make their cartridges open source for one of two reasons: they don't mind others learning how to create Wherigo cartridges from their cartridge, or they based their idea on (or downloaded and modified) an open source cartridge (and, hence, the Creative Commons "share and share alike" line). I have to admit, though, someone could download the GWZ and figure out where the associated cache is located. However, if you know enough about cartridge files, you can circumvent emulator protection or just extract the final coordinates directly from the compiled cartridge (emulator protection or asking the right questions usually prevents most people from hacking a cartridge).

 

As a general rule, I try to have all my cartridges open source so people can learn from what I've done. Besides, there are times I do some strange stuff with my cartridges.

Link to comment

Just contemplating... Another trick to deterring emulation or decompiling could be to encode the final message with a keyword using, for example, vigenere, where the keyphrase could be something one needs to find at a location. The decryption key doesn't need to be in the cartridge, just decrypt the text with whatever keyphrase they supply. If they're wrong, they'll get gibberish. If they're right, they'll see the final message.

 

Getting more complex, you could use the LUA inline parser command (which isn't supported in the smartphone apps, however), and perhaps base64 encode that source code, and apply the encryption. Then, there's even an inherent verification if the supplied keyphrase is valid or not - either the decrypted/unbase64'd LUA code will execute or it won't. If it does, then the final task/message/whatever is executed properly; otherwise, dead end for emulators or couch players.

 

Just some thoughts :)

 

eta: spawned from the efforts a friend of mine put into making his cartridge as protected as possible; but I still managed to decompile it and solve it - only because he used the inline LUA execute command, which the iPhone app doesn't support, and heavily encrypted his inline code mathematically; so since I couldn't play the Wherigo, I made the difficulty into solving his encryption to find the cache ;) He was fine with it, and it was a learning process for both of us, heh

Edited by thebruce0
Link to comment
Just contemplating... Another trick to deterring emulation or decompiling could be to encode the final message with a keyword using, for example, vigenere, where the keyphrase could be something one needs to find at a location.

Earwigo's "obfuscation" of strings (I refuse to say "encryption") uses, in effect, a Vigenère cipher function call. Unfortunately I wrote it a long time ago on an ASCII-only project, so it only encodes A-Za-z0-9 and some punctuation. The "keyword" is actually public in that the decryption routine is included in the source file at compilation time. But if anyone is determined enough to use that code and then work out where in the cartridge the string that they're looking for starts (that's a cool thing above Vigenère, of course), then they deserve the find just for that. :)

 

(Someone used the emulator to complete an Earwigo-created cartridge that used my "no emulator" code. He didn't read the source; he decompiled the Lua, found the "if emulator then exit" code, and patched out the "exit" part. In his defence, his GPSr was an Etrex, so he couldn't have walked the cartridge in the field anyway.)

Link to comment

The bad thing about enjoying hacking cartridges is that you can't reveal all the fun ways you've come up with. If you do, the Builder developers or cartridge authors will try to add something to prevent you from using a particular attack vector. They've done a good job at setting the challenge level. Supposing I had more time, this might turn into a fun game. I suppose if cartridges could only be downloaded to a smartphone this would matter less to me (because the last time I connected my iPhone to my computer was when I bought it).

Link to comment

Yeah, I don't buy the "if anyone is determined enough...they deserve the find" - there are many owners who would greatly disagree :P

 

All it takes is one 'determined' user to make an accessible way for anyone to crack a cartridge. The problem is, being a self-contained code, the source should not contain every necessary part for a valid decode/decrypt. The key shouldn't be in the cartridge. Algorithm, sure, but ultimately, the only 'check' for a valid decrypt should be either whether code executes correctly (parser determines validity) or a message is understandable (player determined validity).

Heck, most any encryption can be broken using a quick google for an online tool, but at least it doesn't only take a quick decompile to disable a check, or to locate the hidden message in the source.

 

In short, there are any number of cheat-deterrents from simply hiding coordinates in the source to encrypting inline code, but to what degree someone needs to go to "earn" the find by hacking/cracking is quite subjective. So that's up to the coder and cache owner :P

IMO, the most secure option is the obfuscation and/or protection where there's no built-in 'check' for a valid decrypt. It either works or it doesn't, and they're left to either brute force, or reverse engineer the decryption. Or, you know, just go and do it :) (thankfully most opt for the latter)

Edited by thebruce0
Link to comment

Simulation protection is the most unnecessary and stupid invention in the Wherigo world. No one has an advantage, not the player and not the owner. Quite the contrary...without this silly thing the player can learn something or after he has solved he can replay the game at home, perhaps to go other ways or make other decisions at a virtual stage ad so on. It is really enough to include the reality and ask for some things there. Besides the protection sometimes produces errors on the oregon. One day, I have made the experience for myself, after I have started the cartridge, satellites were good, the bu..sh.. message appears "Better play outside" :mad:

Link to comment

I'd prefer to see emulator protection that allows someone to play a trial version of a cartridge. Don't put the protection at the front. Instead, give someone a taste of the cartridge before slamming the door--and do it gently.

 

Yeah, that was odd, jonny65, to see the message on an Oregon. I wonder what caused that? Oh, and watch what you censor, please. I'm the oddball here because I don't even swear when I talk.

 

We'll have to wait for Wherigo v2 to solve the emulator problem fully. I'd prefer to use v2's ability to use the Wherigo API to get the final location from the cartridge's online settings information. Besides, running a v2 cartridge on a v1 emulator will crash the emulator. But, anyway, that's all up in the air at the moment. But who doesn't have ideas for Wherigo v2?

Link to comment

Protection was put in there for a reason - some people put a whole lot of work into longer, complex wherigos, expected to provide a solid experience. But without protection, it's unbelievably easy simply to view the cartridge and pick out the final coordinates. And if one doesn't care about logging them on Wherigo.com, no need to even mark it completed. Just go grab the final.

Ultimately, again, it's entirely up to the Wherigo maker to decide how much protection to incorporate into the cartridge.

Link to comment

Just go grab the final.

 

If he want to do this, its his own decision, why should I force him to do something he doesn't want ? There is an easier way : Just log a Wherigo somewhere in the world. Increases the statistic of Wherigo founds very quickly :lol: But for what ?

 

The player who wants to play a Wherigo and have fun with it, loads the cartridge and plays. Perhaps 1 out of 100 or less solves it or a part of it (until he has to answer a real question) in emulator. So what ?

A good Wherigo integrates the reality or uses real stations, so it is impossible to cheat anyway. Thats more than enough of "protection". And 95% of the wherigos in the world you never will play. Wouldn't it be nice to play some of them in emulator for a few clicks and get some ideas or only just for fun ? I think so

Anyway, there is still no reason.

Link to comment

Just go grab the final.

 

If he want to do this, its his own decision, why should I force him to do something he doesn't want ?

Sure, but that is your choice, as the CO. Not every CO thinks like that. =P

 

There is an easier way : Just log a Wherigo somewhere in the world. Increases the statistic of Wherigo founds very quickly :lol: But for what ?

If I understand what you're saying, that doesn't mean anything for someone who just wants to increase their find count on geocaching.com. You don't have to solve a Wherigo to log a find on a Wherigo listing on gc.com; you only have to sign the physical logbook.

The discussion of hacking wherigos is very similar to the discussion of 'cheating' on 5 difficulty puzzles, for instance. Groundspeak (rightly) can't really enforce rules about what constitutes cheating, but the CO has every right to decide what they do with their listing, or puzzle, if what they believe to be cheating has become rampant. Many COs will archive their puzzle cache if the answers are swirling around in the public, effectively ruining the challenge of the puzzle. Some don't care, some do.

 

A good Wherigo integrates the reality or uses real stations, so it is impossible to cheat anyway.

Nope, because if I just want to sign the log, I don't have to do all the steps in 'reality' to get the final coordinates of the physical container - if there's no protection of that information in the cartridge - no matter how "good" a Wherigo is ;)

 

Wouldn't it be nice to play some of them in emulator for a few clicks and get some ideas or only just for fun ? I think so

So do I. I like to actually complete wherigos without 'cheating'. Unfortunately, there are many who will do what they can just to get the final coordinates. Some COs want to retain the appearance and challenge of whatever they've set up (puzzle or Wherigo or whatever), and if a vast majority of "finds" didn't actually do what was intended, it can (depending on the CO) alter the perception of the listing, whether it be difficulty, fun, challenge, time, uniqueness, etc...

 

Once again, no one can say what's "right" or "wrong" about protection from cartridge hacking - it's entirely up to the CO to decide how much work they want to put into making it hack-proof, because yes, there are people who'd rather just log the cache than be forced to do all that work if they know how to bypass it. (and I know first hand that there are people who will gladly skip stages of a multi-cache and just go to the final if they have those coordinates, instead of doing all that work)

And this is also touching on elements of why ALRs are no longer allowed for most cache types.

Edited by thebruce0
Link to comment

Here's an example of a cartridge you do have to do in reality:

At each step, a question is asked of the surroundings. One question could be a number on a bench. Another could be multiple choice about what's there. The cartridge keeps track of the answers provided and uses them to calculate the final cache's coordinates. In the case of the multiple choice answer, each answer could be tied to a different number. Due to the calculation at the end, the final cache's location is never stored within the cartridge. Doing this would take a little experience and programming to do, but it is cheat proof if done correctly.

 

That's the best part of what I was suggesting earlier: put the emulator check somewhere within the cartridge and not right up front. At least, that way, I can get a cartridge's flavor. That's one of the best things I've unintentionally found about helping others with their cartridges: I am exposed to all sorts of ideas. Since I have the source code, I don't have to worry about protection (or providing a wrong answer), so I can taste the full experience the author is trying to provide. This, in turn, could influence me to create a cartridge spawned from an idea I had while playing theirs. Since no one else in my area is creating cartridges, I'm unable to get ideas from playing them in the field. At least, with sticking emulator protection somewhere in the cartridge, I can get an idea of the cartridge's story, supposing there is one.

Link to comment

Here's an example of a cartridge you do have to do in reality:

At each step, a question is asked of the surroundings. One question could be a number on a bench. Another could be multiple choice about what's there. The cartridge keeps track of the answers provided and uses them to calculate the final cache's coordinates. In the case of the multiple choice answer, each answer could be tied to a different number. Due to the calculation at the end, the final cache's location is never stored within the cartridge. Doing this would take a little experience and programming to do, but it is cheat proof if done correctly.

Right, that's basically what I was referring to -- if there's no verification in the cartridge itself.

Is the user told whether the final calculated coordinates are actually correct? If so, then it can be reverse engineered (mathematical calculations aren't hard to reverse, especially if you get the decompiled source code).

ie, there can't be a validity check in the cartridge at all, else it's hackable.

Link to comment

If so, then it can be reverse engineered (mathematical calculations aren't hard to reverse, especially if you get the decompiled source code).

 

:blink::rolleyes:

Who should do this ? You ? Ok you are right, if the final contains 5000 dollars and the first finder gets it. :lol:

 

Ok, how about a compromise ... if it is not absolute necessary *), Wherigo owners should make no protection.

I want to convince programmers that it is more useful for others without that "feature" and questions from the reality are much better and enough ! Newbies can learn something and players who solved the cartridge can play it again at home (with the real codes they got during the walk). Sometimes there is more than 1 way to the final, so they can "walk" the other one.

 

*) I think this are nearly all wherigos B)

Link to comment

If so, then it can be reverse engineered (mathematical calculations aren't hard to reverse, especially if you get the decompiled source code).

Who should do this ? You ? Ok you are right, if the final contains 5000 dollars and the first finder gets it. :lol:

 

Ok, how about a compromise ... if it is not absolute necessary *), Wherigo owners should make no protection.

I want to convince programmers that it is more useful for others without that "feature" and questions from the reality are much better and enough ! Newbies can learn something and players who solved the cartridge can play it again at home (with the real codes they got during the walk). Sometimes there is more than 1 way to the final, so they can "walk" the other one.

 

*) I think this are nearly all wherigos B)

 

"questions from the reality are much better and enough" - I completely agree, for an ideal world. However, I know from experience that there are both 1) cachers who will decompile difficult Wherigo cartridges (whether to skip the activity, or for the FTF), and 2) owners who do want to make it as difficult for those people to do so as possible.

 

What we want, or wish for an ideal experience really is irrelevant. All my comments above were discusssing were possible ways to make protecting content more complex, for those that wish to do so... to make it as hard to hack (or 'cheat', to some) cartridges as possible. I'm not saying every Wherigo needs uber-protection. You're more than welcome to continue making fun cartridges that ask for real-world answers, yet still hide the final coordinates within the cartridge without protection. :) For most people (owners and players) that's enough. For others, it's not...

Link to comment

We just finished building and publishing our first Wherigo using the online tool earwigo. Does the "block the player from being played in emulator" work and if so what exactly does it do? The reason I ask is that there is a really smart computer program guy in our area. He takes great joy in hacking puzzles and wherigos and takes a running tab on those he finds through his methods. He used a alternative Java program to run the Wherigo that plays similar to emulator. Now I don't have a huge problem with him hacking it, but for the future I want to make this cartridge as hard to hack as I can. Is there any way of doing this through the Lua code?

Link to comment

We just finished building and publishing our first Wherigo using the online tool earwigo. Does the "block the player from being played in emulator" work and if so what exactly does it do? The reason I ask is that there is a really smart computer program guy in our area. He takes great joy in hacking puzzles and wherigos and takes a running tab on those he finds through his methods. He used a alternative Java program to run the Wherigo that plays similar to emulator. Now I don't have a huge problem with him hacking it, but for the future I want to make this cartridge as hard to hack as I can. Is there any way of doing this through the Lua code?

The simple answer is that, though not easy, it's possible to decompile a cartridge and read quite a bit of the data. It's also possible to mess with the cartridge with a hex editor (my favorite method, actually), though you have to know what you're doing and what you're looking for. You can make things harder to find in code and generally fool both attempts.

 

For a truly hack-proof cartridge, ask the player questions along the way. Store the player's answers in different variables. When the story or tour ends, construct the final zone's coordinates based solely off the content of those variables.

 

 

::: Takes moderator and PR hat off and locks it tightly away and leans forward :::

 

If you'd like my personal advice, though, I'd suggest you mess with him. Make the cartridge look ordinary. Put in the usual emulator prevention and even add a zone called Geocache or Final Zone or something that'll stand out. Add a picture and even text with the coordinates if you'd like. All of those will take him to a plausible area. Hide something there. Put only a note within the container and make it read, "Now that you're out here, why not play the cartridge normally?" The cartridge, instead, will construct the final zone or change the final zone's coordinates based off player inputs. This is the fox method of hack prevention: make the person do the normal hacking work to think he succeeded only to discover it was a carefully-laid trap to get him out to where the cartridge is. If he continues to hack the cartridge even after that, I'd say you wasted enough of his time and extracted your pound of flesh that he deserves a little reward. Just remember to change up your next cartridge so he never knows if what he has is right or wrong.

 

Why, yes, I can be downright devious. Thank you very much for the compliment.

Link to comment
We just finished building and publishing our first Wherigo using the online tool earwigo. Does the "block the player from being played in emulator" work and if so what exactly does it do? The reason I ask is that there is a really smart computer program guy in our area. He takes great joy in hacking puzzles and wherigos and takes a running tab on those he finds through his methods. He used a alternative Java program to run the Wherigo that plays similar to emulator. Now I don't have a huge problem with him hacking it, but for the future I want to make this cartridge as hard to hack as I can. Is there any way of doing this through the Lua code?

I know of one case where a software person who only had an Etrex hacked Earwigo's emulator protection. He found out what the compiled Lua code for the protection source code looked like and patched it in binary.

 

The way in which Earwigo protects against the emulator is right there in the Lua source code of your cartridge that Earwigo generates. So it's no great secret. There are two ways round it:

- Patch the binary, as above

- Use a different emulator. (For example, DesktopWiG is not quite an emulator, but can be made to run a bit like one.) Earwigo currently only detects the Groundspeak emulator.

 

Otherwise, consider using Ranger Fox's suggestion. I have seen a cartridge that did this - if run in the emulator it gave you one of six possible fake finals, all custom-encrypted by the cartridge author (who is also a great programmer). Some of these were 10 miles away, ha ha.

 

The bottom line is that it's not possible to absolutely prevent anyone from cheating if they're prepared to put in a lot of effort. My slightly off-beat suggestion would be to enlist your local expert and get him to show you how to make your cartridge hard to hack. (Google "Frank Abagnale" :D)

Link to comment

I've got the hack-proofing reverse engineered such that earwigo's method is ineffective. And as I mentioned earlier, I had a friend who encrypted LUA source code itself with a complex mathematical algorithm, which was run inline (thus making the cartridge incompatible with the iPhone Wherigo app). I managed to crack that, and let him know how along the way, which he appreciated (and it was fun :) ).

 

So yes, I'd say there is no way to completely hack-proof a cartridge.

As I mentioned above, if the cartridge contains the final coordinates, or is able to verify or validate coordinates, then they are retrievable - obviously it may take more work depending on how hidden the coordinates are, or how munch skill the hacker has.

 

And this is why as I mentioned above, the only way to make a cartridge "hack proof" is to not include final coordinates in the cartridge, even if there are also red herrings, fake coordinates. Make the player become the validator. By that I mean... for example, provide only the encrypted solution - make it so that the user has to enter a decryption key, such as the answer to a field question, but don't code a check function, only a decode function. If they get the answer wrong, they'll only see gibberish (the app itself won't know if the answer is wrong). The player can see whether the solution is valid or not. If someone were to hack it, they'd only be able to find that encrypted message, and track the source code to see what sort of encryption it is. But without the key, they'll never get the answer. Their next and only course of action would be to take the cipher elsewhere and try to crack that, without the key or by trying to determine it. But that's beyond Wherigo cartridge hacking.

 

Example (and this is a very weak one, since a vigenere is an easily crackable cipher):

If I were to provide the "win scenario" as displaying the vigenere encoded message "Ibvutr pftd zv scepeih uitqsg npis vty edc xwnnty xnie tpxr yk tce", and the question "What is the colour of the sign?" then that's as far as hacking can get. No final coordinates are in the cartridge (other than possible red herrings). So if the person on site answers the question wrong, the vigenere cipher would display gibberish, and they could try again. If the hacker knows it's vigenere, they need to do exactly the same thing at that point, if they want - try to determine the key (or, you know, just go there properly and answer the question first hand).

 

tl;dr:

What's important is the concept - if the app can "decompile" the cartridge to execute it and somehow confirm to the player what the final coordinates are, then the hacker can "emulate" that decompiler and "cheat" to get it. Doesn't matter how complex the encryption or misleading the content. The only "hack-proofing" which disallows that is to not include the answer in the cartridge at all (or any validation of an answer).

 

However, that's on the high end of amount of work required to foil hack attempts. Do you really want or need to go that far? *shrug*

There are people who will hack.

There are people who will simply use other people's scripts, and if they don't work, give up.

And there hackers ranging from people who only open files in notepad or a hex editor, to people who decompile, analyze, reverse engineer, etc etc. Just decide how far you want to go, how difficult you want to make it to hack.

If you don't care, then don't do it :)

 

Keep in mind, hackers (both ethical and unethical) enjoy the mystery and the puzzle... the harder you make it for a hacker to achieve success, the more likely they'll work even harder to crack it :) (and that's why I didn't give up on my friend's mathematical encryption algorithm, which he hand-coded in LUA, until I decoded his inline source code. If he'd encrypted it with a method requiring a key from a field question, I likely wouldn't have been successful)

Edited by thebruce0
Link to comment

This is for Ranger Fox: I've been trying for hours to get the Wherigo builder to work. I watched the video of your presentation in Canada. I can't get even a simple two zone Wherigo to save/compile. I keep getting the error message:

 

Error making the cartridge

An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)

 

Can you tell me what I'm doing wrong???

 

Thanks, Cachundheit

Link to comment

This is for Ranger Fox: I've been trying for hours to get the Wherigo builder to work. I watched the video of your presentation in Canada. I can't get even a simple two zone Wherigo to save/compile. I keep getting the error message:

 

Error making the cartridge

An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)

 

Can you tell me what I'm doing wrong???

 

Thanks, Cachundheit

That's the 64-bit issue. It could be that your computer is 32-bit and you copied the 64-bit fix to your computer. Try reinstalling and only applying the map fix.

 

To tell if your computer is 32- or 64-bit, check your c:\ drive. If you see a folder called "Program Files (x86)" and one called "Program Files", it's 64-bit. If you just see "Program Files", it's 32-bit and you should not have copied the 64-bit fix.

 

Greetings from Geowoodstock XV. Or, at least, the morning after.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...