Homebrew [Custom Launcher] Spider3DSTools released

[Idaho]

Learning is a magical thing.

Well for now the only thing I can achieve in C is a tic tac toe with no AI executing in the terminal console, not being pessimistic but if I were to learn those things I could only help when the new generation of handled would release...

 

[LoneGrenade]

Even so, you shouldn't have such a sense of entitlement when something made for developers gets released. If you want to use it, you should learn how to. I'm not trying to flame you, just saying, the person that can help you the most with this kind of stuff is yourself.

 

[gamesquest1]

things take time, this is brand new, experimental stuff.....ofc its for developers, if developers dont have the tools how do you expect anyone to do stuff.......unless your suggesting they should of been kept hidden because it wasn't a rom loader off the bat.......when things are shared, people can develop them, when things are kept private for the exclusive use of the few.....well we all know how that goes

difference is this is public, any dev wanting to use it can use it....many tools of the past where just for showing off, its not anyone's job to make anyone a CFW, but publicly shared tools and exploits opens the window for more devs to get involved than just the elite 4

 

[Idaho]

Even so, you shouldn't have such a sense of entitlement when something made for developers gets released. If you want to use it, you should learn how to. I'm not trying to flame you, just saying, the person that can help you the most with this kind of stuff is yourself.

Maybe I didn't make myself clear, I'm glad the devs can have things to work with, I'm just saying that by now the work to achieve a CFW on the 3DS could have been done (it has already been done by a few people and kept "secret") and therefore bring homebrews to the mass could have been achieved but for some reasons it hasn't and all we see is devs releasing things for other devs since years now and still nothing of practical use for the mass except paid solutions (and as a user my frustration around this is getting bigger everyday) .

I'm glad I bought a Gateway as I don't have to deal with those issues but not everyone can and we should have better ways than buying a blackboxed flashcart to have homebrews on our 3DS(hacking shouldn't look like USSR)...

My guess is that the 3DS scene will end up looking like the PS3 scene, and damn the PS3 scene is the biggest failure in term of forming a community around hacking and reversing a device, nobody want all that work being wasted on creating something not worth the efforts...

 

[shutterbug2000]

Hmm. Is anyone interested, who knows a thing or two about gameboy roms, take a look at this ram dump and tell me EXACTLY where the rom starts? Thanks!

This is the area around where the "MARIOLAND2" is located:

 

[LoneGrenade]

Maybe I didn't make myself clear, I'm glad the devs can have things to work with, I'm just saying that by now the work to achieve a CFW on the 3DS could have been done (it has already been done by a few people and kept "secret") and therefore bring homebrews to the mass could have been achieved but for some reasons it hasn't and all we see is devs releasing things for other devs since years now and still nothing of practical use for the mass except paid solutions (and as a user my frustration around this is getting bigger everyday) .

I'm glad I bought a Gateway as I don't have to deal with those issues but not everyone can and we should have better ways than buying a blackboxed flashcart to have homebrews on our 3DS(hacking shouldn't look like USSR)...

My guess is that the 3DS scene will end up looking like the PS3 scene, and damn the PS3 scene is the biggest failure in term of forming a community around hacking and reversing a device, nobody want all that work being wasted on creating something not worth the efforts...

The problem here is that there is no one willing to contribute to a community of leeches, there is a small group of developers that actually do all the work and a metric ton of people that just want hand outs.

They all feel entitled to anything that anyone in the scene creates, whether the dev made it for themselves or for other developers. If someone wants to share a preview of an incomplete work, people on this forum specifically will whine about how its not being shared with the rest of the community and how the scene wont grow because of "greedy devs" when even if they had access to it, they wouldn't be contributing. They would try to run it, find out it doesn't run ROMs, and then whine about it anyway.

Edit: Sorry for derailing this thread a little bit, but it's just something that kills me about this forum (beg, beg, beg, whine, whine, whine). Just try to LEARN a little bit and contribute what you can, if you can't contribute, try to learn from other's work, don't just use it and give up on learning about it.

 

[Deleted User]

Hmm. Is anyone interested, who knows a thing or two about gameboy roms, take a look at this ram dump and tell me EXACTLY where the rom starts? Thanks!

This is the area around where the "MARIOLAND2" is located:

0x028002AC, where the byte "0xC3" is.

 

[shutterbug2000]

0x028002AC, where the byte "0xC3" is.

Thanks!

 

[Deleted User]

Thanks!

No problem. Not only do the bytes there mostly match up with the beginning of the game's ROM file, but that address is also the right number of bytes (0x134) before the header starts (MARIOLAND2).

 

[Apache Thunder]

The above photo appears to show where it starts. the format of my rom compared to yours seems to have some slight differences. Might just be different fonts perhaps? The double pair of the odd looking A symbels are a definite match though.

EDIT: Seems I posted this a bit late.

 

[shutterbug2000]

Ok, figured I'd try to make it load the file in chunks. However(c n00b me kicking in), I can't figure out exactly what to do. Should I be loading into buffer then rom? That just doesn't really make sense. Ahhhhhh!!!!

 

[Rioluwott]

Deleted Wrong Thread

Sorry

 

[shutterbug2000]

Hmm. Let's say I have a 64 kb GameBoy rom, would this code work to load it? Because it isn't... No changes at all

int
uvl_entry ()
{
   
        unsigned int addr;
    void *this = 0x08F10000;
    int *written = 0x08F01000;
    int *buf = 0x18410000;
    int *read_len = 0x08F10020;
   
    int i;
    addr = 0x168002AC;
    GSPGPU_FlushDataCache(addr, 65535);
    GX_SetTextureCopy(addr, buf, 65535, 0, 0, 0, 0, 8);
    GSPGPU_FlushDataCache(buf, 65535);
    IFile_Open(this, L"dmc:/rom.nes", 65535);
    *((int *)this + 1) = 0x00000000; //Fseek to 0
    IFile_Read(this, read_len, buf, 65535);
    svcSleepThread (0x400000LL);
                GSPGPU_FlushDataCache(buf, 65535);
                GX_SetTextureCopy(buf, addr, 65535, 0, 0, 0, 0, 8);
                GSPGPU_FlushDataCache(addr, 65535);
                //flashes mostly black screen on the bottom screen for a few frames, this is so i know the program is running and not frozen
                GSPGPU_FlushDataCache(0x18000000, 0x00038400);
                GX_SetTextureCopy(0x18000000, 0x1F48F000, 0x00038400, 0, 0, 0, 0, 8);
                svcSleepThread(0x400000LL);
                GSPGPU_FlushDataCache(0x18000000, 0x00038400);
                GX_SetTextureCopy(0x18000000, 0x1F4C7800, 0x00038400, 0, 0, 0, 0, 8);
                svcSleepThread(0x400000LL);
    return 0;
}

 

[Apache Thunder]

This is just an educated guess, but I'm thinking the VC host app is actively replacing the rom you injected in to it. What you could try and do is inject it, have the program wait a bit, then dump memory to a file. if your rom is where it was suppose to be still, then it didn't get replaced and you just need continue working on how to get the rom injected correctly.

If not...then there's some kind of memory protection going on and you might have to patch something else in the running program.

You can also look at the new Pokemon injector that was released. I'm pretty sure it's open source and would be a good starting point on how you should be doing it.

 

[shutterbug2000]

This is just an educated guess, but I'm thinking the VC host app is actively replacing the rom you injected in to it. What you could try and do is inject it, have the program wait a bit, then dump memory to a file. if your rom is where it was suppose to be still, then it didn't get replaced and you just need continue working on how to get the rom injected correctly.

If not...then there's some kind of memory protection going on and you might have to patch something else in the running program.

Well, that's what I'm kinda thinking too. But, how come it crashes sometimes then after injection? That would seem to mean... it is still there.

 

[Apache Thunder]

Perhaps the rom is loaded in more then one location?

 

[shutterbug2000]

Perhaps the rom is loaded in more then one location?

You know. That could be it! Ok, how far is a normal applications ram access? Going to ram dump !

 

[Apache Thunder]

There's also the game inside the VC player to think about. I would assume when you boot up the virtual console game, that it immediately boots up the rom inside it. If you replace the rom in memory, the game simply crashes because it's suddenly not the same game anymore. You might need to find a way of "soft resetting" the VC program to properly reload the rom as it has been changed from it's original state.

Imagine Mario jumping around a level squishing Goombas. Then suddenly the memory is overwritten with a Castlevania rom or something. The VC app was actively loading that particular area of the rom into GPU for drawing sprites and stuff goes crazy as it's now loading random data that shouldn't be there because it's not the same game anymore, and now it's some random spot in the new rom.

Either Virtual Console or the game simply flips out because it wasn't booted properly and suddenly started at a memory offset it should not have. That's my guess on what's going on.

 

[shutterbug2000]

There's also the game inside the VC player to think about. I would assume when you boot up the virtual console game, that it immediately boots up the rom inside it. If you replace the rom in memory, the game simply crashes because it's suddenly not the same game anymore. You might need to find a way of "soft resetting" the VC program to properly reload the rom as it has been changed from it's original state.

Imagine Mario going jumping around a level squishing Goombas. Then suddenly the memory is overwritten with a Castlevania rom or something. The VC app was actively loading that particular area of the rom into GPU for drawing sprites and stuff goes crazy as it's now loading random data that shouldn't be there because it's not the same game anymore, and now it's some random spot in the new rom.

Either Virtual Console or the game simply flips out because it wasn't booted properly and suddenly started at a memory offset it should not have. That's my guess on what's going on.

Well, I use the reset option on the bottom screen, I would think that's enough... right?

 

[gamesquest1]

games have patches applied....it could be that these patches break other games.....suppose a way to check your method is working would be to inject the same game and see if it still plays....also see if you can locate the patch file in ram and blank it out