Homebrew Homebrew Development

  • Thread starter Thread starter aliak11
  • Start date Start date
  • Views Views 1,475,165
  • Replies Replies 6,048
  • Likes Likes 54
From what I can tell, there are lot of hardware reverse engineering and people just documenting what registers/addresses control which features of the hardware.

But the most effective way to document information is to get your hands on the beautiful Development/Debug hardware. ;)
that would be great .......now i have only to learn game programming , join wario world and have $3,905 for a PARTNER-CTR DEBUGGER/CAPTURE :creep:
 
i dint understand it quite well :wacko:
so you use the c/c++ to write the homebrew and then python to build it?

You can use any language you want, as long as a compatible ARM compiler is available. The Python script is only to build your launcher, you could rewrite this part in any language you want.
 
My small contribute to coding 3DS homebrew: https://github.com/nop90/3DS_Homebrew

Cool, thanks! Can't wait until I get off of work so I can mess with your stereoscopic functions a bit. I'll post my git repo too when I get something working.

Also, is the source released for that "3DS Fiddle" video that OP posted? I didn't see anything in the linked repos with I/O code.
 
My small contribute to coding 3DS homebrew: https://github.com/nop90/3DS_Homebrew

How do you compile this? I'm getting a launcher.dat but when I try to run it on my 3DS it just hangs without producing any results.

Cool, thanks! Can't wait until I get off of work so I can mess with your stereoscopic functions a bit. I'll post my git repo too when I get something working.

Also, is the source released for that "3DS Fiddle" video that OP posted? I didn't see anything in the linked repos with I/O code.

I don't think so. I tried looking for it too but I don't think it was released.
 
I'd also like to know how to compile it.

I would've thought it would be as simple as using the "build.py" structure that has been used for all other homebrew so far, but maybe there's something else different.
 
I would've thought it would be as simple as using the "build.py" structure that has been used for all other homebrew so far, but maybe there's something else different.

I think we have to edit a build script or makefile to include the different headers and source files he has compared to whichever other script.

Cool, thanks! Can't wait until I get off of work so I can mess with your stereoscopic functions a bit. I'll post my git repo too when I get something working.

Also, is the source released for that "3DS Fiddle" video that OP posted? I didn't see anything in the linked repos with I/O code.

https://github.com/insaneKane/3DS_Homebrew_Stuff2

I'm pretty sure that has the headers for I/O in it, Kane49 wrote the fiddler program. Link is from the python tools thread, which also has some early homebrew in it.
 
I think we have to edit a build script or makefile to include the different headers and source files he has compared to whichever other script.

I'd probably be able to figure it out if I weren't so sleep deprived. Gotta love being able to sleep for only an hour.
 
I'd probably be able to figure it out if I weren't so sleep deprived. Gotta love being able to sleep for only an hour.

I'm still really new to programming. STarted learning C like a month ago and was working two jobs and just havent had much time :[. The most complicated thing I've done is like a 100 line mini text rpg.
 
Im guessing you just copy over all the files into the source folder and thats it :)

It for some reason just runs the original homebrew even though those sources are deleted and the other ones added. As far as editing the build script, it's got a wildcard for .c and .h so that's a non-issue.
 
How do you compile this? I'm getting a launcher.dat but when I try to run it on my 3DS it just hangs without producing any results.

I last compiled and tried it yesterday night and today morning I changed some things before loading it on github, so I could have changed the wrong thing.

But probably the problem is that in this version of main.c i'm writing only on the first set of buffer, and without a set_buffer() function sometimes the code starts with the second buffer on.

Try writing something on the secon buffer too. Tonight I hope to complete the set_buffer() to have double buffering for advanced graphics.

Sorry for the inconvenience.
 
For Windows users who have no idea on how to use this and/or dont care to investigate:
1. Go here, in the right side click on the gcc-arm...win32.exe
2. Get Python version 2.7.6
3. Install Python in C:\Python27
4. Install arm toolchain in C:\Program Files\GNU Tools ARM Embedded\
5. Goto Computer > Properties > Advanced > Environment variables
6. In the list below search for Path, select it and press Edit/Modify
7. At the end add:
Code:
;C:\Python27;C:\Program Files\GNU Tools ARM Embedded\4.8 2013q4\bin
8. You can now make a simple batch file in the build.py folder with
Code:
python build.py
pause>nul
Note pause is not necessary if you are using this through cmd
 
How are they getting the code to run? Did they figure out how to sign it or are they using some exploit to load it? Is it the same as the exploit that Gateway used to get signed code to run?
 
How are they getting the code to run? Did they figure out how to sign it or are they using some exploit to load it? Is it the same as the exploit that Gateway used to get signed code to run?

It's unsigned code running in a way similar to how Gateway is run. We create a launcher.dat file from any of the source code shown here and launch it using the DS Profile exploit (using a different installer than that to Gateway's, since theirs reads only their encrypted code and none of this code is encrypted in the end).
 
It's unsigned code running in a way similar to how Gateway is run. We create a launcher.dat file from any of the source code shown here and launch it using the DS Profile exploit (using a different installer than that to Gateway's, since theirs reads only their encrypted code and none of this code is encrypted in the end).


So the gist of it is, you can get unsigned code to run, but you are limited to code that could actually be executed by a legit 3DS game (no OS-level kernel mode) and it requires 4.5 firmware or lower?
 
So the gist of it is, you can get unsigned code to run, but you are limited to code that could actually be executed by a legit 3DS game (no OS-level kernel mode) and it requires 4.5 firmware or lower?

I'm pretty sure we have full kernel access using this exploit, it just isn't really shown here. Theoretically we could create something like a Linux loader that boots the 3DS into Linux, change things around in RAM (and maybe ROM?) and other stuff. Basically, I'm pretty sure this exploit can be used to give us full access to the 3DS. But yes, it's limited to FW4.5.
 

Site & Scene News

Popular threads in this forum