Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
var u=String['from'+'CharCode'](95);
var g=map[u+'display'].game;
if(g!=undefined){
g.inventory=['computer','phone','redKey',
'yellowKey','greenKey','blueKey','theAlgorithm'];
g[u+'moveToNextLevel']();}
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
This is fun. I'm not so much trying to actually solve the levels, as much as find a single snippet of code that solves all of them. Should be doable.
So far I've worked my ways through most levels by removing the exit and placing it near me. Some slight adaptions make it work for most levels. The problem lies in getting the computer and other items...
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
Patashu wrote:
mklip2001 wrote:
This does bring the question: how possible is any of this in realtime?
The previous TAS route was done in real time. I presume this one can be too.
This one is a lot less possible, though. It's probably still doable, but the warp to Space Station 2 requires you to press a button 14 times in the wonderful margin of exactly 28 frames.
Patashu wrote:
By the way, what does 'manipulating' the state mean? What actions make it go up or down? Is it like the OoT wrong warp?
This was so obvious to me I forgot to mention it in the submission text, manipulation is merely pressing action (z, space, v, up or down) to make the game state go up. I think this is left over from the old game, as some of the old dialog (that's not actually used in the game) uses the game state to progress.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
It's only "invalid" because the top two runners (CtrlAltDelicious and FieryBlizzard) don't like running it. Everybody else is cool with it, as long as the distinction between SS and RTA remains intact. So this is valid for SDA two.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
I'm not done with this glitch yet though. I'm not sure about anything, but there's still a lot that I want to explore with it.
EDIT: Point being, I don't know if this is the final route yet. Working on this alone sucks though, so I'll try to document all I know in a video or something for everyone.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
I like the discussions these Atari submissions undergo. "Did you try going left and right" or "try going a bit slower maybe" is a nice change from discussing how best to insert the payload using sprite data or whatever.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
I really like this one. Sure, it beats the entire intent of 11-exit runs (namely not glitching your way through everything), but it manages to push the boundaries on "what is arbitrary code execution" a little in the meantime. I like that.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
CoolKirby wrote:
Maybe you could have a certain character, like *, at the start of each frame
creaothceann wrote:
Instead of * you could also use a Unix newline character - editors like Notepad++ understand them.
Nope. At least not for now; HourGlass uses a binary format, something that's not really about to change.
Each frame starts with a flag, noting which input devices (in order: keyboard, mouse and x-box gamepad) are used during this frame. Then the length of the input and the input is listed, per device. It's still fairly simple to tell where frames start and end, that's not the problem. The problem lies in using default tools (= hex editors), as the basic location = header_size + frame_count * frame_size doesn't apply.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
YushiroGowa wrote:
Low %: Just get to the goal.
Oh for fucks sake. Will people ever learn? "Just get to the goal" is called any%.
Grab ALL the collectibles: 100%
Be as fast as possible, ignoring collectibles: any%
Actively AVOID collectibles: low%
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
Warp wrote:
Unfortunately there aren't many good C++ tutorials out there.
I'm inclined to disagree. While, yes, many of the tutorials you'll find within the first three pages when googling for "C++ tutorial" are absolute crap, good tutorials do exist. Rather than searching for general tutorials, just decide on something specific you want to do and google how to do that in C++. Any problems you run into? Google those too.
One tutorial a really like is from hugi, a demo scene magazine. Although the setup's a bitch (I still prefer Visual Studio over anything else), the coding and explanation is solid.
Warp wrote:
All you need to know is how memory caching works, and how your particular programming language arranges its data containers in memory. There is no need to know even a single machine code instruction.
To be fair, using C or C++ makes it easier to arrange data in whatever way you want, or access data in ways that managed code doesn't allow (copying 4 bytes from an array by casting char* to int*, that sort of thing). It also helps that, unlike C#, C(++) doesn't pretend that structs are somehow primitive types.
Many high-level languages make a point out of hiding how data is stored, because it's not something the programmer should be concerned about. Although most often true, this does mean it's a lot harder to do things just slightly different from how the language wants you to do it.
antd wrote:
Thanks for everyone's input. I've started to become interested in how exploits work, and how vulnerabilities are used. If pursue this route, I guess I have no choice but to learn C? :-P
This very much depends on the kind of vulnerabilities you want to investigate. Web security is an entirely different matter from cryptography, for example. However, from the sound of it, you already know Python and ASM to some extent. As such, I'd think that what you're lacking in skills is not so much in programming itself, but rather in software design.
I don't know if you've ever done much with class inheritance, interfaces, properties and such, but if you haven't, I'd recommend to take up C#. It's easy to write simple, console-based applications, create GUI applications using Visual C#, do some drawing (System.Drawing or (yuck) XNA) or even build web applications. This means you can focus on designing your code: what classes do I need, how do they need to interact etcetera etcetera. It's a skill many programmers* lack, and it's an important one.
All in all, I think it mostly depends on what you want to learn and what you enjoy the most. If I were you, I'd pick some simple programming task (Mandelbrot?) and do it in a few languages. Whichever one you enjoyed the most, you learn more about. Until you're sick of that and you repeat the exercise.
* Or at least many of my fellow computer science students. All the assignements require 2, 3 classes tops.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
Warp wrote:
For the zero to actually cause glitching would require quite peculiar programming decisions...)
Not really, using the value of a register as an offset to another ram address (this is done very, very often) would mean that any unexpected value would read data from memory that's not supposed to be read. In e.g. Pacman, this causes the right half of the level to be constructed from enemy data*, instead of actual level data.
* It might not actually be enemy data, but it's not level data, that's for sure.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
I'd love to help you make a verification movie for story, but I've not been able to find any working U images. My optical drive can dump, but that doesn't help either, as I only have the EU version. We wouldn't be happening to use JAP, right? I haven't looked far that yet.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
Tub wrote:
Even after rereading your proof, I must admit that I don't understand the invariant you're claiming and the inductive step you're doing. To replace F(n), you need to get a sum for b-F(n) that doesn't contain F(n-1) nor F(n-2), but your assumption only allows you to remove one.
Dammit, your right. The proof worked in my head, but it is, indeed, incorrect. Let me fix that for you, and also proof that we cannot remove more than one element. Note that the entire proof is repeated (and reformatted), as this is the version now on my computer:
First, let's proof we can remove any given one element from the Fibonacci sequence and still construct any natural number.
Let's take S(x, k) a sequence of Fibonacci numbers where:
1) The sum of the elements of S(x, k) = x
2) S(x, k) does NOT contain F(k)
Now we assume that for any k < n, x < F(n) there exists an S(x, k). It is easy to see that this holds for n = 5 (k < 5, x < 5) We then want to prove that this also holds for k < n + 1, x < F(n + 1).
We do this by dividing the proof in two conditions:
A) k < n
B) k = n
A) k < n
We already know that for any given x < F(n) there exists a S(x, k) (this is our initial assumption. We can then easily that there is a solution for S(F(n), k), namely F(n). We can also easily see that for any y | F(n) < y < F(n + 1) a solution for S(y, k) is S(y - F(n), k) + F(n), as 1 <= y - F(n) < F(n).
B) k = n
In this case, for any given y | F(n) < y < F(n + 1), we can use the solution S(y, k) = S(y - F(n - 1), n - 1) + F(n - 1). We know a solution for S(y - F(n - 1), n - 1) exists, as y - F(n - 1) < F(n) and n - 1 < n. A possible solution for S(F(n), y) is, of course, F(n - 1) + F(n - 2).
It then follows by induction we can remove any Fibonacci number and still construct all the natural numbers.
Secondly, we want to proof that we can only remove one Fibonacci number.
If we remove any two terms F(a) and F(b), a > b, it follows that the largest number we can make using only F(i) | i < a is the sum of all terms up to F(a - 1), minus F(b). The sum of all terms up to F(n) is F(n + 2) - 1, so this would be:
F(a + 1) - F(b) - 1
This means we cannot make F(a + 1) - F(b) using any terms F(i) | i < a, and we also cannot use any terms F(i) | i > a as
F(i) >= F(a + 1) > F(a + 1) - F(b)
As such, it follows that we can only remove a single element from the set of Fibonacci numbers.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
Tub wrote:
@Scepheo: so your proof says that you can remove any number F(n) after you've already removed a number F(k) with k<n? We know that's not possible, so there must be a flaw in there.
I think this is the part where your proof goes poof:
A) we will never have used both of them, as F(n - 1) + F(n - 2) = F(n) and b - F(n) < F(n)
B) we can safely remove the other one, as per our initial assumption.
A) Yes, after removing F(k), k < n, you will still have a sum, and that sum has only used either of F(n-1) or F(n-2)
B) ...but now you're retroactively changing k to either n-1 or n-2! By doing so, you get a different sum for b, invalidating your assumption that the other number wasn't used!
If you remove F(n-1), your sum may contain F(n-2), and if you remove F(n-2), your sum may contain F(n-1). At no point are both used (so A still stands), but there's no proof that you can remove both at the same time and still represent any b you need.
Ah, no, the latter have of my post aims to proof that, apart from f(k) | k < n, you could also remove f(n). So yes, I am "changing k to n-1 or n-2", but that's okay, since I'm no longer using the fact that f(k) was removed.
Basically, my proof consists of two parts:
1) Proof that we can also make the numbers up to f(n) for any given f(k) removed.
2) Proof that we could also remove f(n) instead and still make the sums.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
I find all you people's proofs hard to follow, honestly. My own proof (to the fact that you can remove any fibonacci number), is a bit different:
Let us assume we can remove any fibonacci number from the sequence F(1), ..., F(n - 1) and still construct all the numbers a < F(n). We can then also construct all the numbers b where F(n) < b < F(n + 1) by taking the sum for b - F(n) (which exists, as a given) and adding F(n).
We then prove we can also remove F(n) from the fibonnaci sequence by taking the sum for b - F(n) and adding F(n - 1) + F(n - 2). We know we can do this because
A) we will never have used both of them, as F(n - 1) + F(n - 2) = F(n) and b - F(n) < F(n)
B) we can safely remove the other one, as per our initial assumption.
Given that our initial statement holds true for F(5) = 5 (you can easily check this by hand), it follows by induction that we can remove any one element from the fibonacci sequence and still construct any given number.