No plug-ins required

While messing around with The Cheat, I accidentally discovered a way to make yourself invincible. Unfortunaly, the memory addresses Nova uses seems to vary between copies (I don't know anything about how programs use memory) so I can't give you the exact address of the variable you need change. However, I can tell you how to find out:
Open up Nova and buy some Equiment, say 30 tons. Tab out of Nova and open up The Cheat. Search for a 16-bit unsigned integer with a value of 30. You should get numerous results. Go back into Nova and sell say 20 tons to leave you with 10. Go back to The Cheat and search again for a value of 10. Repeat this process until you only get 1 result. Click Add Variable. This is the address where Nova stores how much Equipment you have. To get the address we're looking for you simply have to add 2 to that address. It should begin with 02 and end in 086, eg. 0250E086 or 0217F086. I think by default the value of this address is 0. If you change it to 1 or higher, missiles will pass straight through you. With a value of 64 or higher you will be completely invincible.

(EDIT): I should note that doing this may inexplicably cause otherwise peaceful warships to turn hostile by simply targeting them.

This post has been edited by Guy : 17 March 2005 - 04:32 AM

...

While interesting, there are easier ways to cheat with Nova than by using a RAM editor.

True, but I posted this because it's something you can't do with plugs. Also, once you've worked everything out it actually becomes easier to do it this way than by quiting Nova and modifying a file and launching it again. In the middle of a battle and find you're running out of ammo? Can't help that with a plug.
But I was actually thinking this stuff would be useful for developers. Testing out those new ships and weapons you've added is just a click away. No problems with the item not being available or being too expensive or something.

Thats gross. I hate you.

NebuchadnezzaR, on Mar 18 2005, 01:17 PM, said:

Thats gross. I hate you.
View Post

:huh:

NebuchadnezzaR, on Mar 18 2005, 01:17 PM, said:

Thats gross. I hate you.
View Post

I keep waiting for the punch line.

That's supposed to be a joke, right?

Now that's hacking.

I didn't think MacOSX (which is a quite secure system) would allow a program to peek and poke at memory owned by a another process, even if you allow it, especially given the separate adress spaces for different processes. At least I hope you can't do so if you're not the SuperUser (root) (or someone who can sudo, i.e. an admin, which comes to the same thing) or the user who launched the process.

It's a little too hardcore, risky, and unadaptated to beginners for me to put it in the debugging techniques of my guide, if you don't mind.

As someone who programs, I'd say it's probably in a place of memory that's dynamically allocated (given it's too general stuff to be in a local variable on the stack, and I don't think such data is in a global var, as are too many such things for them to be stored in global vars), probably with NewPtr or malloc (I don't think it's in a relocatable block). Such functions return the program a block of memory (in fact a pointer, that is an address, to the beginning of the block), of size asked by the program, where it can store data of that size; usually the results vary from call to call, depending on previous allocations, memory usage otherwise by other programs, and of course computer model, system, version, etc... For the program, it doesn't change anything where this memory actually is, the important is that there is a certain amount of free memory there that the program uses.

EDIT: deleted stuff I thought harmless.

This post has been edited by Zacha Pedro : 24 March 2005 - 08:50 AM

I'll just stick to making cheat plug-ins when I need invincibility. Though this would be way cooler.
And Zacha, I am either too dazed or don't know enough to tell; are you insulting me? Not personally, I mean me as part of a larger group. I take no offense, I just find it funny that I might see an insult where there is none, or not see one when I should because I am lacking certain knowledge.

Zacha Pedro, on Mar 21 2005, 01:38 PM, said:

Now that's hacking.

I didn't think MacOSX (which is a quite secure system) would allow a program to peek and poke at memory owned by a another process, even if you allow it, especially given the separate adress spaces for different processes. At least I hope you can't do so if you're not the SuperUser (root) (or someone who can sudo, i.e. an admin, which comes to the same thing) or the user who launched the process.

It's a little too hardcore, risky, and unadaptated to beginners for me to put it in the debugging techniques of my guide, if you don't mind.

As someone who ACTUALLY programs, it's probably in a place of memory that's dynamically allocated (given it's too general stuff to be in a local variable on the stack, and I don't think such data is in a global var, as are too many such things for them to be stored in global vars), probably with NewPtr or malloc (I don't think it's in a relocatable block). Such functions return the program a block of memory (in fact a pointer, that is an address, to the beginning of the block), of size asked by the program, where it can store data of that size; usually the results vary from call to call, depending on previous allocations, memory usage otherwise by other programs, and of course computer model, system, version, etc... For the program, it doesn't change anything where this memory actually is, the important is that there is a certain amount of free memory there that the program uses.

It's amazing how some of us, plug-in developers, are completely experts on a variety of programming and computing subjects including many outdated ones such as ResEdit (especially DITL editing) and the resources (especially their load order, stuff from the plugs overriding stuff from the data files overriding stuff from the Nova application (such as built-in DITLs) is in fact a feature of resources), hexadecimal, technical limitations, IDs, etc... and yet some of the same people just don't know the realities of programming...
View Post

Well having only just started learning Java this year, I think I fall into that category. A lot of what you say doesn't mean a lot to me but I'll just note that once you've worked out all the addresses they don't change between launches. They only vary between different copies of the program.
I'll agree it's pretty risky, but it's just like the pilot file editor everyone's always wanted. I haven't had a look at bits yet but I've worked out quite a bit of stuff, including the date - now you really can go back in time!

Oops, looks like I wrote stuff that could be misinterpreted. And this is not the first time. Next time I'll reread myself four times before writing anything (begins rereading this post four times).

Oh, yes, in Java all that memory stuff is taken care of for you. I don't think the adress should change between launches: indeed this adress is in the program's adress space and I can't think of any runtime change that could change the adress.

It's actually not as risky as you'd think. The most you can do with this is freeze up your system, however, because of the way OSX/BSD is written, data in memory won't adversely affect system files; everything will be peachy upon restart. The only time memory overflows are dangerous are when it is affecting disk-based memory, not RAM.

~ SP

I don't think it's dangerous for the computer or the system, but rather for our pilot. You may very well end up corrupting that poor pilot to death (litterally, in a way). And, of course, crash Nova.

Space Pirate... I think it does that by not allowing such a hack in the first place. Since the hack does something on windows, its assumed it can ruin stuff, too. What if you manage to miraculously over write the address for where the program will save the file on to the hard drive or something? Couldnt it just stomp on whatever was there and not realise it?

I mantian that RAM editing hacks are gross voodoo tricks and anyone that partakes in such aggregious actions should be dealt with accordingly (burnt at the stake).