If you are doing it with a cheat then yeah - easier to alter than create something new in most cases. Cheats since... maybe the N64 have had nice check this area, compare it to this number/range, if it is within range then do something else options as well so if you can find something that is unique to shiny pokemon (does not have to officially do with anything, though certainly do look for those, but just something that reliably is a certain value or range when a shiny pokemon is there) you can set something else that is hopefully obvious (does not have to be related to anything, just something you can reliably find the location of).
Tools for assembly then...
Three main lines of tool
1) A disassembler. Takes the code and tries to convert it from the machine readable machine code and into the more human readable assembly code.
2) A debugger. Usually an emulator but can be on hardware for some setups (usually ones that run their own firmware in the background or whatever the devs are using for testing), which does include the 3ds.
These will have breakpoints, ability to view assembly in situ (the code having already been run/set up to run and thus ambiguity that might arise from static disassembly which has no context for the code is less), ability to view memory, cheat searches, graphics viewers, sound setup viewers , maybe some 3d settings viewers, maybe lua support and whatever else the dev cares to include as a useful feature.
I mentioned breakpoints above. Computers in their basic form (modern security can make it a bit quirkier) have three basic things a section can be used for -- reading data, writing data and executing code. Hence the big three types of breakpoint (ever wondered what the pause-break button on the keyboard is actually for/was for in days of old?) being break on read (bpr), break on write (bpw) and break on execute (bpe or sometimes boe). Run to line is a thing in some debuggers and is a special case of break on execute. Some will also allow you to log things instead (if an area is written every cycle but you only care about certain aspects then useful), or put some conditionals on the breakpoint (if data written is between this range).
https://www.romhacking.net/documents/361/ is for the GBA and a command line emulator but covers the basics of what is known as tracing (following data back from landing in memory where say a nice VRAM viewer might see it to the ROM or some place further back where it makes more sense to edit).
https://web.archive.org/web/20130215155212/http://labmaster.bios.net.nz/vba-sdl-h/ is said same emulator's usage guide.
The gold star in emulator debuggers is usually given to FCUEX which does the NES as it has all the nicest features.
https://fceux.com/web/help/Debugger.html including
https://fceux.com/web/help/CodeDataLogger.html but you might not be so lucky for the 3ds.
Some emulators will farm out such things to a popular open source debugging method known as GDB which can in turn be spoken to by stuff like ghidra (one of the big open source tools, your NSA tax dollars hard at work on that one)
https://wrongbaud.github.io/posts/ghidra-debugger/ radare2 (the other big open source tool these days)
https://book.rada.re/debugger/remote_gdb.html or IDA
https://hex-rays.com/ if you are feeling particularly flush (the free versions don't do anything but PC really so your 3ds' ARM stuff needs that, and probably a plugin to handle all the 3ds memory locations. It is one of the better tools out there though).
3) An assembler. Takes your assembly instructions and turns them back into the binary the machine needs to run. Not sure what we are suggesting for this one or if the GBA and DS stuff will do here (I usually use whatever GCC assembler is going with homebrew things like devkitpro but armips
https://www.romhacking.net/utilities/635/ also is good stuff, no real need to go find whatever ARM themselves provide but it has historically been a thing). One of the standalone debugging programs, or possibly even the emulators, might allow you to assemble something though.
A list of the instructions and maybe a programming guide or CPU listing (which will not have the memory locations for the console which Nintendo would have decided upon). I have not got anything quite as nice for the 3ds as I do for the GBA and DS (and other older consoles). Though usual places to look are emulators and their source code (by definition they have to know how the device works to emulate it, and emulating it necessarily involves replicating it), homebrew guides (
https://www.3dbrew.org/wiki/Main_Page maybe), interest groups (rare but have been known) and possibly leaked SDKs from the original console maker or similar (back in the 16 bit era and prior they were great for hardware listings, as time wore on then less and less and 3ds is not near the 16 bit era as instead most modern stuff focuses on libraries they provide with a superficial overview of specs and how to code to them).
http://problemkaputt.de/gbatek.htm#3dsreference (one of the main things I would link for the GBA and DS) does have a new section on 3ds stuff that is coming up quite nicely. For the GBA but nice intro to ARM assembly
http://www.coranac.com/tonc/text/asm.htm (the 3ds ARM11 has a fair few more features but still related),
https://blog.quirk.es/2008/12/things-you-never-wanted-to-know-about.html also has some stuff,
http://imrannazar.com/ARM-Opcode-Map is again for older than the 3ds but still good. I would also usually say go look at the first few chapters at least of art of assembly
https://www.plantation-productions.com/Webster/ and
https://stuff.pypt.lt/ggt80x86a/asm1.htm before returning to the PC, youtube videos are not much good for this sort of thing but
has some good stuff for a more gentle introduction, also while
it is ancient by today's standards then this amiga video is one of the clearer explanations I have ever seen.
Also I linked cheat making before but might as well have something more here
https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial https://doc.kodewerx.org/hacking_nds.html (if that site is down then search for enhacklopedia as there are loads of mirrors around the place) and for the sake of something 3ds then
https://github.com/iSharingan/CTRPF-AR-CHEAT-CODES/blob/master/ActionReplayCodeTypes.txt looks reasonable. You want to know the basics of cheat making for it you can find something that happens a result of/alongside the code you actually care about you can work backwards (or in some cases forwards) to the thing you actually care about (does not have to be a cheat -- if the OAM moves a 2d sprite when you jump then one way to get moon gravity as a result of that). Do also learn some of the tricks of the trade for cheats -- don't do the epic side quest to try to make 1 new ultimate end game bonus weapon, go to the first town, give yourself infinite money, buy something, search, buy, search, sell, search... until you find that and the ultimate weapon (and possibly bonus hidden/developer only/cut for being OP) will either be a different identifier (as in item identifier and count, usually seen if you can rearrange your bag) or in a nearby location (this cell is count for this weapon, this cell is count for this weapon and so on and so on). Similar thing applies to characters, stats, levels... Moon gravity was mentioned earlier but one of the main ways is to see if the game has double jump and set to cheat such that the double jump has not been done yet which in turn means you launch into the sky by holding jump/tapping jump.
Anyway I will call that my intro to assembly/debugging in general for today, I do have a bit more and some worked examples in
https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ as well but again more for the GBA and DS.
Edit. As far as forcing a shiny then I was not thinking you were wanting to as a thing for the final game. As a means to test code out and find suitable things to look at to determine shiny or not in memory to then such a thing would be invaluable -- you can do cheat searches for things that happen 1/255 or 1/some thousands (and you possibly needing multiple thereof) but it is quite tedious, and even more aggravating if you fat finger the wrong search option and have to restart.