Homebrew [RELEASE] TWLTool - DSi downgrading, save injection, etc multitool

[smf]

FYI nobody is dropping or "picking up" 32 bit Windows compatibility in this thread, AFAIK TWLTool 1.6 code is fairly portable, it's just there's only a Windows 64 bit binary in the OP.

So you accept there is no real reason twltool needs 64 bit, but people just have to endure a barrage of insults if they ask for a binary.

other than that, there's no "relatively recent hardware limited to 32 bit" AFAIK.

Isn't one example enough to disprove your point about all hardware being able to run 64 bit? Or are you saying people deserve insults for not ditching 32bit windows in favour of 64bit linux?


I've only ever used twltool 1.6, it has a brilliant addition that it checks that the keys you have given are correct. Which was useful when I was getting the wrong CID from fwtool using an original sudokuhax v2 installation in conjunction with homebrew channel circa 2011 (I figured out later that if I use hbmenu instead then it works).

 

[JimmyZ]

So you accept there is no real reason twltool needs 64 bit, but people just have to endure a barrage of insults if they ask for a binary.

Isn't one example enough to disprove your point about all hardware being able to run 64 bit? Or are you saying people deserve insults for not ditching 32bit windows in favour of 64bit linux?

So you can't read, that's not my fault.

 

[JimmyZ]

I've only ever used twltool 1.6, it has a brilliant addition that it checks that the keys you have given are correct. Which was useful when I was getting the wrong CID from fwtool using an original sudokuhax v2 installation in conjunction with homebrew channel circa 2011 (I figured out later that if I use hbmenu instead then it works).

Original fwtool from Wintermute dumps CID directly from EMMC registers, there is a fork(the fork also enables NAND writes) which reads CID from RAM which is not very reliable, anyway no harm could be done even without the check, the "decrypted" NAND contains invalid data thus couldn't be mounted, you'll notice that by then.

 

[realWinterMute]

But dropping support for 32 bit Windows is a bit weird. Some relatively recent hardware is limited to 32 bit.

What hardware is that?

Original fwtool from Wintermute doesn't have the option to dump CID, there is a fork(the fork also enables NAND writes) which reads CID from RAM which is not very reliable, anyway no harm could be done even without the check, the "decrypted" NAND contains invalid data thus couldn't be mounted, you'll notice that by then.

Um https://github.com/WinterMute/fwTool/commit/7d159a73d1075db8b08b34d18f2e9ee4c72993f8

I still want to attempt to write nocash info footer to the dump. Still some more code required for that though.

 

[JimmyZ]

Um https://github.com/WinterMute/fwTool/commit/7d159a73d1075db8b08b34d18f2e9ee4c72993f8

I still want to attempt to write nocash info footer to the dump. Still some more code required for that though.

Oops I should have set a watch on that repo, should I submit a SHA1 PR now? I see the dsi-updates branch has been merged in libnds.

I heard some times the RAM address containing Console ID got polluted, so generating that footer might not always possible? generating the footer sometimes doesn't exactly sounds like a good idea.

 

[roygbiv]

This is a super useful tool. Thanks @WulfyStylez.

 

[Jayro]

What hardware is that?

I got a Netbook for Christmas in 2013... Pretty weird that the Atom chip inside it was 64-bit capable, but purposely crippled to 32-bit for some reason. And it didn't even utilize PAE, so I was stuck with 3.5GB of RAM out of a 4GB stick, and that really sucked. But now, 5 years later, 32-bit just seems silly. I've even dropped 32-bit with MediCat USB about a year ago or so, since it's designed for current bleeding-edge PCs.

 

[RealYoti]

Someone has fwTool 2.0.0 source code?

 

[Visual Studio]

Edit: Ignore this