Hacking Booting CFW successfully

[pastaconsumer]

My ultimate end goal is to hopefully make either a launcher.dat or boot.bin that runs ctrsrv regardless of if a button is pressed/held. Hell, if it works, I'll try to make a mini GUI where you can select whether or not you want to load ctrsrv mode. But it's probably going to be a very, very long time before I can get that...

 

[WulfyStylez]

My ultimate end goal is to hopefully make either a launcher.dat or boot.bin that runs ctrsrv regardless of if a button is pressed/held. Hell, if it works, I'll try to make a mini GUI where you can select whether or not you want to load ctrsrv mode. But it's probably going to be a very, very long time before I can get that...

That's a really simple patch. Just tweak this branch in their arm9 code: http://puu.sh/gSuvw/8fef58a61c.png

 

[pastaconsumer]

That's a really simple patch. Just tweak this branch in their arm9 code: http://puu.sh/gSuvw/8fef58a61c.png

Damn son... How do you do that??? Do I use the full, or can I use the Freeware version? I am EXTREMELY sorry for being such a noob to this.

 

[WulfyStylez]

Damn son... How do you do that??? Do I use the full, or can I use the Freeware version?

IDA is generally a tool for analyzing (and sometimes debugging) binaries. You'll need separate knowledge of how patching works to go beyond just seeing how things work. I'd link one, but I can't for the life of me think of any handy resources for that sort of thing. It's often the same process as cracking software, though.

 

[nop90]

here is the idb file for IDA Pro and its for the boot file of the palantine cfw exploit. http://www.filedropper.com/boot_2

The parts with the firm patches and the arm11 hach are not correctly decompliled. There is a lot of work to do on this file.

Damn son... How do you do that??? Do I use the full, or can I use the Freeware version? I am EXTREMELY sorry for being such a noob to this.

Before starting to learn Reverse Engineering you should have good programming skills and a knowledge of ASM. To be very good at debugging is a big help, you cold ask to some frinds of yous to study som c code with strange bugs and try to find where they are (boring? .. yes it is, but RE is worst.)

My testbook for starting RE many yeasr ago was the +ORC tutorials "How to crack". Tools used are no longer available (winice was my first love) so you can't test many of the thing explained, but it's a good starting point if you don't know someone that can train you directly.Don't know if there ara more recent tutorials so well explained, maybe some younger dev can give you a hint.

But don't expect RE is an easy matter.

I'm close to the solution, but my progress on boot.bin are very slow, I can't loose too many hours of sleep if I don't want to be a zomby at work. At the moment I know what's not working and found that someone else studied and solved the same problem (look here or here). I'm porting this solution to the boot.bin, but I cant only make a copy and paste, mostly because xerpi to lauch the linux image needs only a CPU interrupt hooked, but for booting the firmware you need to make jump both CPU to the FIRM boot entrypoint at the same moment.

Attahed you can find a cleaned version of boot.bit. It isn't so much better, just removed not useful code to speed up the arm11 hack and should make a little more probable that the arm11 interrupt is hooked before the CPU hangs. Really, it's not the solution.

 

[williamcesar2]

why don't you use the bootstrap ? To fix boot.bin sounds like an impossible task

 

[nop90]

why don't you use the bootstrap ? To fix boot.bin sounds like an impossible task

Because I like challenges and learning. I started something and I don't want to quit as long as i think I can do it.

I don't think it's impossible. Maybe it's not worth to spend all this time on something that is already enough usable, but I don't work for profit.

 

[johovahs]

Attahed you can find a cleaned version of boot.bit. It isn't so much better, just removed not useful code to speed up the arm11 hack and should make a little more probable that the arm11 interrupt is hooked before the CPU hangs. Really, it's not the solution.

I am curious to know if you are still testing out the modified files you did to boot it more successfully? I know the last I heard in this thread was your son was not too successful on his console.

 

[nop90]

I attached it 4 post before. try it yourself. IMHO only a little improvement.

 

[Koryushin]

Hi, I tried your modified boot.bin on a Classe 6 samsung SDXC 32Go on my 3DS XL (EUR), and i didn't notice some improvement.
I noticed 3 differents states:
- Both screen black many times, and had to turn off the 3DS.
- Green Upper screen and no flash on bottom screen, had to power off the 3DS.
- And finally green upper screen, flash on bottom screen, and boot to CFW.

First state happend 3/5 times. Second state happend 1/5 time and third state 1/5 time.
I did a lot of try to have a good point of view.

Hope that'll help.

PS: sorry for my bad english

 

[nop90]

... and i didn't notice some improvement.

Probably not enough, as I already said.

But it can be of some use for the aspirant reverser: search the differences from the original to know where is the buggy part

 

[nop90]

-deleted-

 

[bannana2]

The parts with the firm patches and the arm11 hach are not correctly decompliled. There is a lot of work to do on this file.



Before starting to learn Reverse Engineering you should have good programming skills and a knowledge of ASM. To be very good at debugging is a big help, you cold ask to some frinds of yous to study som c code with strange bugs and try to find where they are (boring? .. yes it is, but RE is worst.)

My testbook for starting RE many yeasr ago was the +ORC tutorials "How to crack". Tools used are no longer available (winice was my first love) so you can't test many of the thing explained, but it's a good starting point if you don't know someone that can train you directly.Don't know if there ara more recent tutorials so well explained, maybe some younger dev can give you a hint.

But don't expect RE is an easy matter.

I'm close to the solution, but my progress on boot.bin are very slow, I can't loose too many hours of sleep if I don't want to be a zomby at work. At the moment I know what's not working and found that someone else studied and solved the same problem (look here or here). I'm porting this solution to the boot.bin, but I cant only make a copy and paste, mostly because xerpi to lauch the linux image needs only a CPU interrupt hooked, but for booting the firmware you need to make jump both CPU to the FIRM boot entrypoint at the same moment.

Attahed you can find a cleaned version of boot.bit. It isn't so much better, just removed not useful code to speed up the arm11 hack and should make a little more probable that the arm11 interrupt is hooked before the CPU hangs. Really, it's not the solution.

 

[bannana2]

Its frustrating when you know the solution and can see all the pieces to the puzzle but can't put it together. You have Superior knowledge on this matter, but I believe I can help you, but don't know how to communicate it with you.

 

[williamcesar2]

Its frustrating when you know the solution and can see all the pieces to the puzzle but can't put it together. You have Superior knowledge on this matter, but I believe I can help you, but don't know how to communicate it with you.

PM!