I'd like a chance at this one too, if someone would be so kind as to pass along the source file with hb or similar...
Replying to:YolkaiI'd like a chance at this one too, if someone would be so kind as to pass along the source file with hb or similar...
I errr never really had SmileBASIC or 3DS. I came over from PTC and accidentally got attached doing work on the site and now I'm just a sort of tumor.
I can emulate SB, though, and this looked interesting, which is why I though I'd ask for the file. Thank you!
Replying to:YolkaiI'd like a chance at this one too, if someone would be so kind as to pass along the source file with hb or similar...
How are you emulating it? On a 3DS emulator? I don't know how any platform but the 3DS works with SmileBASIC so the program is designed specifically for SmileBASIC on 3DS. I have no clue how it'd hold up or if it'd run at all on other platforms.
Replying to:YolkaiI'd like a chance at this one too, if someone would be so kind as to pass along the source file with hb or similar...
With citra, yes.
I had no problems with getting it to run.
One thing you may have neglected to prevent is peeking at variables after execution, which can be perhaps be used to deduce the result of the password hashing and the contents of the label table... Anyway, it's put together well and I'll keep looking at it when I get home, assuming someone else hasn't cracked it by then.
Replying to:YolkaiI'd like a chance at this one too, if someone would be so kind as to pass along the source file with hb or similar...
Yeah, I did notice that but I wasn't sure how to prevent. The program is designed so that any discrepancies between the original code and the currently running code causes it to crash, and when a program crashes all its variables are still viewable. It's sort of inevitable with the current method I'm using, I'll have to come up with a different method entirely to prevent that.
Replying to:YolkaiI'd like a chance at this one too, if someone would be so kind as to pass along the source file with hb or similar...
Right, I guess I didn't realize the table would be constructed before a crash trying to use it. Still, you can prevent variables from being read after normal execution [by clearing them]. I just assumed the normal flow would be the most useful to read, but this could be a bad assumption.
Ooh this is very good wow. may have to spend some time on this.
potential spoiler
do GTD3H3RVNN54J3N7B5HLVLPG7S5PQBGN and ROOT have anything to do with the challenge, are they just part of the check algorithm or are they red herrings?
Replying to:IAmRalseipotential spoiler
do GTD3H3RVNN54J3N7B5HLVLPG7S5PQBGN and ROOT have anything to do with the challenge, are they just part of the check algorithm or are they red herrings?
There's no red herrings. Everything in the program is there for a purpose.
Replying to:IAmRalseipotential spoiler
do GTD3H3RVNN54J3N7B5HLVLPG7S5PQBGN and ROOT have anything to do with the challenge, are they just part of the check algorithm or are they red herrings?
inb4 actual poster answer
Spoiler
It's "part of the challenge" in the sense that they are the apparent part of it. Whether you need to do anything with them is not necessarily the case.
But, they are used by the program; it isn't a herring or anything.
Edit: poster is fast. could not obtain in before. Will delete if requested.
Replying to:YolkaiI'd like a chance at this one too, if someone would be so kind as to pass along the source file with hb or similar...
brute force attack on password reported a success... that contained a non-printing character. Oops.
Replying to:YolkaiI'd like a chance at this one too, if someone would be so kind as to pass along the source file with hb or similar...
So you bruteforced it? The hashing algorithm I used likely isn't very secure because, well, I just came up with it off the top of my head, so I'm sure there's a lot of collisions and several potential passwords that will actually work. If I have the free time I've considered bringing something like Blake2 to SmileBASIC which should solve that.
Replying to:YolkaiI'd like a chance at this one too, if someone would be so kind as to pass along the source file with hb or similar...
Right. There wasn't anything preventing me from copying the hashing code, replacing the table lookups with the absolute values from the method suggested above, and then throwing random values at it inside smilebasic. I did try to port it but I guess I did it wrong (or it abuses some SB arithmetic features that I didn't account for), I think I only produced the correct hash with single-character keys or something.
I don't know much about cryptography, so I can't really analyze it, but in the key I came up with the fourth character could be replaced by several multiples of 8 (Chr$(64), Chr$(88), Chr$(96), Chr$(128), ...) and still work, which was a little amusing.
Resorting to a... "black box" crack like this would still be a success on your side, but I did have to de-obfuscate the program to find the relevant parts... some of the jumps are even guessable, though e.g. @1510RETURN help confuse that. Since the values in the table are sequential based on location in the program, they could probably still all be deduced with a little patience (I opted for the easier method).
Reversing the hash... probably not an option, and still not really the problem.
Considering that the working part of the program can be lifted out once the table is known, I'd consider being able to perform basic de-obfuscation and obtaining the table as a partial success for programs of this type. Please correct me if I'm neglecting something.
I'll still see what I can do about (2).
Replying to:YolkaiI'd like a chance at this one too, if someone would be so kind as to pass along the source file with hb or similar...
Hashing algorithms are one-way functions and the algorithm is intended to be public as they can't actually be reversed. The issue is that with poor hashing algorithms, they have a lot of collisions, this means that a lot of possible inputs would yield the same output, making bruteforcing it not take a considerable amount of time. Again in the future I'll consider porting a serious hashing algorithm to SmileBASIC, something more cryptographically secure with much less collisions.
Replying to:YolkaiI'd like a chance at this one too, if someone would be so kind as to pass along the source file with hb or similar...
The issue with doing a quick integrity check is that if you've already replaced all the labels, you could just delete the integrity check code. And encrypting the table would require on-the-fly decryption which would introduce a ton of overhead in the program.
The core idea to this software is to calculate values during "lock time" (when the program is ran through the "locker" program) and then modify the code to incorporate those same values into the program at run time. The issue is that you can never simply do checks between these two values because it would introduce too much overhead, instead you need to find a way to rearrange the logic in the program to rely on those values to function.
The label method's probably not the best method because you can substitute in the table once you figure it out, I'll need to look into other methods... the annoying part is that I can't find any resources on anyone else trying to make similar software, so it's purely up to me to come up with these algorithms myself.
Replying to:YolkaiI'd like a chance at this one too, if someone would be so kind as to pass along the source file with hb or similar...
Mmm, I forgot that there are plenty of chances to halt the program while it has the table. That would break the prior check.
There was an on-the-fly chunk decryption-encryption of program data method that I thought would be interesting to implement in SmileBASIC. I'll see if I can find the paper, but you mentioned overhead, so maybe even that won't be feasible.