Knowing where a particular game stores a piece of data so as to be able to edit it can be quite difficult without some sort of reference. Given that the game you are working on is pretty popular, perhaps there is some documentation on where in the game such information is stored. If not, you may be in for a long search, depending on the size of the ROM (I don't know off hand how big SMB3 is).

If you can't find any information on the location of the tile property table (provided there is such a thing and it's not hard coded or something), then you'll have to start looking for it. The fist thing I would recommend is looking up any and all info you can find on the contents and layout of the ROM. For instance, due to the existiance of a level editor, the location of the level data is clearly known and is proably documented somewhere. Clearly, where the levels are stored is not the place where the information you're looking for is stored.

You can also find information on where the graphics are stored, even if it's not documented, by using an NES graphics tool to locate them. Read all the SMB3 hacking docs you can, even if they have nothing to do with what you're trying to find, because they are likely to give you pleanty of places not to look. For instance, a music hacking doc will tell where the music is located, so you know not to look there.

Once you've mapped out as much about the ROM as you can, you'll be left with a list of unknown data which is what you will have to search through. Just changing things at random is fairly inefficient, but an automated proccess that does basically just that called "ROM corruption" can be effective sometimes. You may want to look into that. (There are utilites and documents about it in the RHDN database).

A more determinstic (non random) method involves dissasmbly of the ROM. By dissasembling the ROM, you can determing which parts of the ROM are data and which are code. Some of the more sophisticated EMUs out there can produce data files that can be used by the dissasembler to determin what is data and what is code. If you're using one of these, you could simply look at the file and (provided it's format is readable) see what is code and what is data. (I don't know off hand what EMUs have such a feature. You'll have to look for yourself.)

When using a traditional dissasembler, you can find out what is data or code by looking at the outputed ASM code. Chunks that all dissasemble cleanly are likely to be code and blocks that have lots of bytes that the dissasmbler doesn't understand as code are data. However, not all code that the disassembler manages to interepret as code really is. If you know ASM, you can usually spot such code just by looking at it, if not, it may not be so easy to tell the difference. One way to tell is code that if run, would eventually run into an illegal instruction. The other way to tell is code that does meaningless things, like reapeadedly changing the value of a register, but never doing anything productive with it.

Either way, you should be able to compile a list of what parts of the game are code. When looking for data, this gives you even more places not to look. Once you've eliminated all the places you can, then you have to start experimenting. Using either a hex editor or a ROM corruption tool, you can change various bits of unknown data and see if any of them effect the properties of the map data. If you manage to find such an address, you can then work on figuring out the format of the table.

Another thing you can do is make an educated guess about the location of the data. For instance, the size of the table is likely to be a multiple of the number of tiles. For instance, if there are 128 tiles, the table may occupy 128, 256, or a similar number of bytes. If you know the location of known data of a similar type (for instance, map data), you may want to look at chunks of unknown data in nearby locations.

You can also go through chunks of unknown data and look at them with a hex editor to find parts that "look" like the kind of data you are looking for. In this case, most of the tiles are simply graphics that can't be walked on and have no special properties, therefor, most of the table will (proably) be filled with one value while the rest of it will have other values in a pattern similar to the layout of the special tiles in the area the tiles themselves are stored. By going through unknown sections of data with your hexeditor, if you spot an area that looks promising, you can edit it and see if it works.

You could also try code tracing to try and find the code that uses the table and get the location from it, but that is a fairly advanced method and requires knowledge of ASM.

Best of luck.