I assume you checked to see if there is an existing tool. I have seen some for other emulators of other platforms.
Anyway a savestate is nothing but a dump of the RAM, CPU registers, CPU state, IO, whatever the cartridge has here (some NES mappers will add more interesting things) and basically everything that is used in the runtime of a system. For a PC emulator then you get everything, for some consoles done internally then some things are write only and things get to be made up so we can skip that one for today.
For the most part on the NES then everything listed above is in some way in the main memory bus (other consoles might have things separately). To that end most emulators, flash carts and whatever else will dump everything listed above in order.
The differences then come in how much padding is put between sections (for some purposes in some languages/computers having a data section start on a particular alignment/multiple is faster so some will waste the space to achieve it, or indeed it might be that way in your emulator's memory*), byte order (less of an issue as you tend to want to mimic what is there but still could be one) and some things to come below that might be referred to as metadata or meta concepts.
Some emulators will add a small header/footer to note what ROM it belongs to and maybe some other metadata, some will add internal emulator states (occasionally even necessary in later devices where some kind of dynamic recompilation might be in action), and some will be geared to different flavours of the system (if the emulator supports both the famicom and FDS on top of the baseline western NES then it might make sense to gear savestates for that/any extras that will be present for that and load accordingly). Some emulators will also compress things (possibly with a flag/note to say this one is compressed so act accordingly) but that is less of a concern for the NES, and most times there will be an option somewhere to disable that (it makes it hard for savestate hackers to do things so it tends to then be optional) and even then most of the time it is a basic scheme rather than anything radically custom as it has to happen in real time and space savings are not going to be that great if you did go fancy.
*the average system in my experience has the ROM plus any save in a fixed location either before or after everything else. Consequently a quick and easy savestate might be dump memory as it is in the emulator rather than go section by section).
You can determine this all experimentally easily enough* and people have in the past (around here trying to convert flash cart savestates to emulator ones and vice versa). It is however noted FCEUX is open source (
https://github.com/TASEmulators/fceux , not sure if versions change things but it is less common) and chances are your target is as well (accuracy focused emulators often are). Your main problem might be different mappers if you get into the truly exotic stuff and one or the other emulators does not support it, anything in the seal of approval plus Tengen world should be fine though and it is more modern homebrew efforts and random pirate multicarts that will be the trouble.
*fill each independent area with some notable value series (DEADBEEF, D00GF00D
https://nedbatchelder.com/text/hexwords.html if basic AAAA.... BBBB.... CCCC... does not work or you face byte order issues).
If you wanted to learn programming then this is a wonderful learning project for that (simple enough but not so simple as to be boring, and with tangible results in the end) for pretty much any language you care to employ. Alternatively once you know where the sections are in the source you could probably halt the emulator, insert everything back in with a hex editor that supports memory editing (not all will but many do, including free ones), resume emulator and have it go from there.