I'll simply put the relevant steps/commands for their usage with PokemonSM and NTR Debugger here, but you can still read all the research that was done back in six gen times by opening the spoiler: 1 - Get NTR CFW loaded and start the debugger 2 - Connect to your 3DS debugger using the PC client 3 - Write the code of the battle video you want to dump on the Vs. Recorder. 4 - Start the video playing 5 - While the video is playing write the following command 6 - Video will be saved on the same folder as your NTR Debugger client. 7 - You can open this file with PkHeX to see the involved player's team. *Replace YOUR 3DS IP with the one that corresponds to yours. You can easily get it using third party homebrew like FTPbrony* *The number in bold is the process id that corresponds to the game and may vary between reboots, you can check which one is it by using the command listprocess() at the moment of dumping by looking at the one that corresponds to niji_loc* Original post and research: Warning: Spoilers inside! Time ago I asked if this was possible and it indeed was so I spent some time documenting how it worked, but since I did in a painful way that implied dumping heavy pieces of RAM and using an hex editor to choose the correct bytes corresponding to the battle video I just decided to play a bit more around it to document which offsets contains the correct data and how to dump them easier. All of this was done on a New3DS running NTR CFW and doing the dumps over an Alpha Sapphire card, but it should work the same for Old3DS and other versions of six generation games. Sorry if the formatting with spoilers is annoying, I find it much more cleaner this way How to recognize a battle video: Warning: Spoilers inside! After doing a few memory dumps and diving into them using and hex editor I found five regions, I refer to them as slots, that were likely to contain data related to battle videos. Offsets based on a 0x08000000 region dump of a Pokemon game: 1FBA70, 208E40, 2E74AC, 8D6D30 and 8DED48. Every battle video has always a size of 2E60 and they always start with the following hex values: 0X 81 E2 00 00 As far as I know X can be anything between 0-9. Experimenting: Warning: Spoilers inside! 1 - Clean boot of the game without any battle video uploaded and five stored on extdata: Slot 1 contains data similar to the latest video locally saved but the game crashes trying to read it. Slot 2 contains always a clean 1:1 of the battle video. Only Slot 2 data can be read by pkhex. Slot 3 and 5 are almost empty while Slot 4 contains lots of unknown data. 2 - Writting a battle code and waiting on preview: Slot 1 and 2 remains the same. Battle video is almost 1:1 copied to slot 4 and 5. Slot 3 contains traces of the video but PKHeX is unable to read it and the VS. Recorder cannot as well. 3 - Watching the battle video from the code: Slot 1 and 3 remains the same. Slot 4 and 5 are bloated with unknown data. Slot 2 now stores the clean 1:1 copy of the battle video playing. 4 - Going back with the preview still there: All remains the same. 5 - Closing the preview: All remains the same. 6 - Previewing a stored video: All remains the same. 7 - Watching a stored video: All remains the same except that the video currently played is now copied onto slot 2. 8 - Closing Vs. Recorder and opening again: All is back to the initial state except that now Slot 5 contains unknown data. 9 - Reading another battle code and staying on preview: All is the same as step 2. 10 - Playing the video: Slot 4 is full of crap. Everything remains the same except that Slot 2 now also contains a 1:1 copy of the video. 11 - Opening preview of another battle code: Slot 1 stays same as always. Slot 2 still contains copy of the most recent video played. Slot 4 and 5 are identical and readable with PKHeX. Slot 3 contains references to the actual preview but is no readable by anything. 12 - Watching the video: Slot 4, Unknown data, Slot 5, 3 and 1 the same. Slot 2 is a clean copy of the battle video. 13 - Uploading a stored battle video, closing and opening VS. Recorder: No difference in comparisson with step 1. Conclusion: Warning: Spoilers inside! Slot 1 -Always stays the same and stores a file similar to the most recent battle video stored on extdata but it's structure makes it unreadable for both VS. Recorder and PKHeX. Contains ekx data. Slot 2 - Stores a 1:1 copy of the currently played video. Stores that battle video until a new one is started. Of course this contains ekx data. Slot 3 - Contains several references to battle currently previewed/watched. While is unreadable by PKHeX and by the VS. Recorder it contains ekx data. Slot 4 and 5 - Sometimes stores nothing, sometimes stores almost 1:1 copies of the battle video previewed that can be read by PKHeX, not by VS. Recorder and sometimes apparently contains PSS passenger data. Not a trustable source. *I actually doubt this two ones are the only ones with this behaviour.* So the most trustable way to dump a battle video from a code is dumping Slot 2 while the video is actually playing. This will generate a 1:1 copy of the original file that can be read with PKHeX and even injected onto your own extdata. Commands for NTR Debugger: Warning: Spoilers inside! Slot 1 - data(0x81FBA70, 0x2E60, filename='Video1', pid=0x29) Slot 2 - data(0x8208E40, 0x2E60, filename='Video2', pid=0x29) Slot 3 - data(0x82E74AC, 0x2E60, filename='Video3', pid=0x29) Slot 4 - data(0x88D6D30, 0x2E60, filename='Video4', pid=0x29) Slot 5 - data(0x88DED48, 0x2E60, filename='Video5', pid=0x29) The pid may vary a lot. For me it's usually either 29 o 2b but the easier way to know is run the command listprocess() and search for pid that corresponds the process named "sango-X" on the list.