Kodewerx
https://www.kodewerx.org/forum/

Lunar: DS Codebreaker codes with NDS hacking tutorial video
https://www.kodewerx.org/forum/viewtopic.php?f=11&t=514		 Page 1 of 1
Author:  Parasyte [ Sat Jan 06, 2007 2:25 pm ]
Post subject:  Lunar: DS Codebreaker codes with NDS hacking tutorial video
Lunar: Dragon Song (US)

Enable Code
800085EF 414C4E45
F20AC4B4 223FC000

Infinite Gold
220B4824 02625A00


I also made a video to show how it was hacked. (I know, it's not much of a tutorial; the hack is over simplified. It's more of a demonstration for "how I did it.")

High quality MPEG4 (XviD): http://files.filefront.com/Tutorial_1___Lunar_DS_XviD/;6482829;;/fileinfo.html (~93MB)
High quality MPEG4 (Quicktime): http://files.filefront.com/Tutorial_1___Lunar_DS_High/;6482380;;/fileinfo.html (~86MB)
Low quality MOV (Quicktime): http://files.filefront.com/Tutorial_1___Lunar_DS_Low/;6482381;;/fileinfo.html (~18MB)

The tools used in the video are not currently available to the general public (with some exceptions like Xport and Renegade64), but could possibly reach public beta within the next few months. For anyone who remembers GCNrd, this software is the same idea, but designed for Nintendo DS; create codes and generally debug NDS executables and games.

We might have some more videos like this in the future. Hopefully not as boring, and with some demonstrations of some of the more interesting tools. But I think this is a good start. :)

Digg It: http://digg.com/programming/Tutorial_Vi ... do_DS_game
Author:  kenobi [ Sat Jan 06, 2007 3:04 pm ]
Post subject: 
Even if it's a basic hack, it's really a great vid, and some very nice hacking hardware you have there xD

I can't wait for the next ones !
Author:  Parasyte [ Sat Jan 06, 2007 3:12 pm ]
Post subject: 
I'm uploading a high quality XviD version right now, since some people don't like Quicktime. ;)
Author:  Kyle [ Sat Jan 06, 2007 3:52 pm ]
Post subject: 
Nice job!

I actually understood all of it. :)
Author:  James0x57 [ Sat Jan 06, 2007 4:14 pm ]
Post subject: 
Well, I'll get to watch it in 26 min.. I can't wait though, I'm excited! :D
Author:  Dualscreenman [ Sat Jan 06, 2007 4:49 pm ]
Post subject: 
/me wants an Xport...
Author:  James0x57 [ Sat Jan 06, 2007 4:58 pm ]
Post subject: 
That was great but what will we need to hack? Same stuff as in the vid? I can't drop $200+ to hack. :(
Author:  Dualscreenman [ Sat Jan 06, 2007 5:09 pm ]
Post subject: 
-Xport/parallel cable
-NDSrd
-Game

Alternately you can use:
-A ROM
-No$GBA emulator
-HasteDS (shitty search program that searches the RAM in the emulator)
Author:  Parasyte [ Sun Jan 07, 2007 12:16 pm ]
Post subject: 
Unfortunately, using ROMs always has and always will be illegal, and Martin Korth made his "no$" (term used very loosely) line of emulators "yes$" many years ago. (Software emulators should never, ever be an investment.) On top of that, it does not have perfect compatibility. And of course the free emulators are hardly usable.

It would be great if it was possible to write WiFi code with a small enough footprint to run on NDS alongside a game, but somehow I don't think it is. There's literally only about 4KB that I can use. With Xport, I have a pretty high transfer rate (currently up to about 273KB/s or about 2mbit ... approximately 2x faster than what Datel claims their own trainer can do with a USB connection) and a very small program footprint ~2KB.

The problem with my current setup is that it uses LPT. Almost no laptops contain LPT ports any more, and probably a few recent motherboard manufacturers have been dropping them from desktops as well. I can create a custom FPGA logic configuration to use USB instead of LPT, but that still leaves the price of the Xport hardware, and complicates the client software development.

Some other possibilities include:
PassMe Serial (far too slow transfer rate)
GBA flash cart (far too slow erase/write operation, no direct PC connectivity, many cards requiring different erase/write functions)
GBA media card adapters (file system handling will increase program footprint, no direct PC connectivity, many cards requiring different media access functions)

The pros for each method are about the same, so the only weight to put on them would be the cons, as displayed above. Questions, comments, criticisms?
Author:  James0x57 [ Sun Jan 07, 2007 7:13 pm ]
Post subject: 
We don't get paid to hack so I'd say run with whatever's cheapest.
Author:  Parasyte [ Sun Jan 07, 2007 7:52 pm ]
Post subject: 
Cheapest = WiFi.
WiFi = least compatible, due to the need of a larger program footprint.

Remember how GCNrd was with games like Resident Evil 4? Yeah, like that. Only worse.
Author:  Dualscreenman [ Sun Jan 07, 2007 8:12 pm ]
Post subject: 
Next cheapest would be media card adapters. You can get Supercards for ~$40 USD. Screw M3's, they are expensive. I'd opt for media cards. Both the Supercard and the M3 have some cheap RAM that they use to play GBA games from. (32 MB) You may be able to use that to store shit and ease the overhead.
Author:  kenobi [ Mon Jan 08, 2007 1:47 am ]
Post subject: 
I don't mind paying 200$+ for an Xport, however I have absolutely no soldering/whatever is needed skill, so I wouldn't be able to modify it myself.

And I don't like very much the other solutions (compared to the Xport one)... :/
However, if you really have to drop the Xport, I think the main goal would be to have the best compatibility, meaning the flashcard/mediacard could be the best choice.
Author:  James0x57 [ Mon Jan 08, 2007 5:39 am ]
Post subject: 
I'm not really sure what a program footprint is (I think you're talking about the part of the program uploaded to the game for control) but where would the program be written if you do it via wifi? Is the program somewhere else with Xport? How do these compare to where GCNrd is written?
Author:  Parasyte [ Mon Jan 08, 2007 9:46 am ]
Post subject: 
The program footprint is literally the size of all memory used by the program. With a footprint larger than about 4KB, you start running into the same problem with GCNrd: There just isn't a perfectly reliable area of memory that goes unused on all games. That means you will need to setup a "configuration file" of sorts that will help select the proper memory region for specific games. Meanwhile it would be much easier to just keep the program in static memory as much as possible to improve compatibility.

GCNrd uses static memory for these reasons, but the more important reason was because the debugger program was written almost entirely in C. The majority of it is NOT relocatable. If it were to use the same static memory scheme AND be relocatable, then games like RE4 could be fixed just by moving it to another location in memory.

Further more, if the program was run on the GBA ROM bus, for example, you'll get about zero memory conflicts. However, the GBA ROM bus is something on the order of 16 times slower than cached or TCM memory.
Running the program in uncached memory (like that typically used for AR/CB code engine) is about 2 times slower than cached or TCM memory. (This can be benchmarked very easily with NTRrd; ~26 second RAM dump from uncached memory. ~15 seconds from cached memory.)
Author:  Dualscreenman [ Mon Jan 08, 2007 11:06 am ]
Post subject: 
So if I understand correct, it would be possible to utilize the RAM present in the media-card based flashcarts but doing so would slow down operation. (2 minute memory dump.) That's a bit long, but for me personally it would be way better than landing bucks for an Xport.
Author:  Parasyte [ Mon Jan 08, 2007 3:59 pm ]
Post subject: 
That's about right. Yet another problem, though, is dealing with games which inexplicably give GBA bus access to a specific CPU.
Author:  James0x57 [ Mon Jan 08, 2007 6:14 pm ]
Post subject: 
Is it possible to do a dynamic program where what's in the footprint is what's needed at the time? Like my Super Spinner code, for example, the AR is what writes my requests but my requests are to replace the same spot of ASM each time with whatever I want at that time. So my thought is that the footprint would be like a fixed function that writes requests sent from the WiFi and branches to it when finished. Those requests would fill in the rest or part of the 4kb memory that the poke function isn't using.
So couldn't you do something like that? Just upload a poke command as the footprint and send in, via the poke, chunks of program at a time, and continue to replace that code based on what the computer user wants to do at the time?

That would be awesome but that would only work if my understanding of a footprint is correct (in that it's a program that handles requests from a computer similar to an AR footprint and codes).


Another idea would be to go with the configuration idea. With this it would be great to use two programs, one is a full blown debugger like GCNrd, and the other is a small one that lets you view the game's ram only. Because if the full version doesn't work because it needs to be relocated due to size, then with a smaller footprint you'd be less-likely to run into the problem in that no-longer 4kb area. While the small one's running, we'd just look for open area and simply add the first address of open area to the configuration file(and a tag of some sort that you'd select from a drop down list or something when booting for the problematic game). So when you select that tag, the program footprint gets plopped into the hole we found instead of the what-should-have-been 4KB space.


I really like the idea of hacking over the WiFi (for a number of reasons, cheap being at the top) so if there's any work-around for the crappy memory problem I would love to see that path taken.
I don't think there's anything I can do to help but if there is, let me know. Perhaps a better explination of one of the two ideas? I have a hard time explaining because of my visual thoughts so I would even go as far as drawing crappy diagrams of my thoughts if you're at all interested in exploring these possible posibilities..
Author:  Parasyte [ Mon Jan 08, 2007 8:25 pm ]
Post subject: 
The footprint is literally just the physical size of code and data. In other words, a selected area of memory allocated for the program's use. Yes, code and data can be swapped into memory only when needed, but it will come at a huge speed cost. You have to remember that the ARM9 runs at about 67MHz. That's about 15ns per clock cycle at 100% efficiency. Now keep in mind that it takes 4~8 cycles for each word copied into memory, and an additional 6~16 cycles for reads to the GBA bus (which has infinitely lower latency than WiFi) In all, you would be looking at a program that runs at about 5~64 times slower than optimal.

And that's not taking into account the extreme difficulty present in a task of squeezing a 32~64KB program down into 4KB using swappable memory regions.

Possible? Yes. Plausible? No.
Author:  James0x57 [ Mon Jan 08, 2007 9:24 pm ]
Post subject: 
I understand now, that sucks.
Well, I guess do whatever will work fastest then. If it costs $200+, I'm not gonna be able to jump in right away but I suppose I could save up. :(
It cost me about $100 to get what I needed to hack GCN but I was single, not in college, and was working constantly. heh damn.

I think it would be best to do what works fastest and has the fewest problems between games. I'll get the money eventually and I'm really looking forward to hackin some codes for the DS. Thanks Para.
Author:  Dualscreenman [ Tue Jan 09, 2007 7:03 am ]
Post subject: 
Even if it is slow and isn't compatible with all games, it would be great to have the option to use a flashcart. Heck, if you ran NDSrd out of the flashcart's RAM you could even add WiFi since you have 32 MB to consume in gluttony.
Page 1 of 1 All times are UTC - 8 hours [ DST ]
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/