A Question and Something to Say

[DeadSkullzJr]

Config block 0x00030001 in the config savegame (/data/id0/sysdata/00010017)
I think the raw rtc is in the i2c registers.

Thanks, time to explore these boundaries.

With all due respect, there were certainly long-standing issues created across community GitHub repositories which ended up either closed or otherwise unresolved from not being able to pinpoint a cause, or being seemingly unrelated to Luma itself (which ended up being the case on Luma3DS's issue tracker).

At the time, it wasn't consensually concluded that there would be any direct ill-effect of adjusting the RTC manually, as you can see from ihaveahax's post. In this case, it was found to be a bad practice as more information about the 3DS was discovered. You're correct that TuxSH could have raised an issue with guide developers during some point in the past, but the timeline of these events makes this point somewhat dubious, as public knowledge was still in the process of being gathered and implemented. The cause of the bug was only recently discovered to be RTC manipulation, and TuxSH independently recommended against RTC manipulation based on his knowledge while not being aware that it was the catalyst of lumabug at the time of 10.3's release.

The cause of the issue was discovered within the last six months. I admit that I am not sure what issues from the Luma3DS repo you are referring to, since I do not track it; I am mildly interested.


There's nothing wrong with wanting the best out of a community. The main takeaway is that an instance of an error that flew under the radar isn't necessarily indicative of a longstanding community management error, especially given that it's often a small group of individuals with wildly varying degrees of knowledge. The community created spaces like 3dbrew to help close this gap.


To my knowledge, most users and developers had no reason to consider their action of resetting RTC "generally improper" usage. Of course, if TuxSH did explicitly recommend against it before 10.3's release, it would partially nullify that point.


Unfortunately, this is, and will almost always be, the case for reverse engineering a device that doesn't have manufacturer documentation or decades of history. It isn't necessarily a lack of passion, or else none of this would continue to exist in 2022. What happened here can be reasonably shown to be an instance of a spoken caution that wasn't necessarily caught by everyone until issues arose.

No harm done, so no need to apologise.

With all due respect, there were certainly long-standing issues created across community GitHub repositories which ended up either closed or otherwise unresolved from not being able to pinpoint a cause, or being seemingly unrelated to Luma itself (which ended up being the case on Luma3DS's issue tracker).

Seems I may have missed them, I don't check in daily but I do know multiple issues are closed in a single day quite often so I may have missed it by the sheer quantity of the amount closed. I didn't see this on ctr-no-offset either since that has no issues posted or any closed lol.

The cause of the issue was discovered within the last six months. I admit that I am not sure what issues from the Luma3DS repo you are referring to, since I do not track it; I am mildly interested.

Here:
https://github.com/LumaTeam/Luma3DS/commit/2a947b5c4201d4e6775e6685592e9142364bbd86
More specifically:

- Timeoffset nullification kept as a separate option for compatibility. RTC is supposed to be somehwat monotonic; using this option causes issues with SpotPass. IMHO GodMode9 should parse the cfg save file and do things *properly*

Unless this is something separate from the issue.

 

[DeadSkullzJr]

Decided to look into this, and figured since I am exploring this stuff, I might as well explain an easy fix for this for those that may ask in the future.

I know it was mentioned by @ihaveahax already but for the sake of keeping this all in one post, I mapped out the location of where this is at:

GodMode9:

SysNAND:

SYSNAND CTRNAND
└── data
    └── 00000000000000000000000000000000    //This will be random.
        └── sysdata
            └── 00010017
                └── 00000000
                    └── partitionA.bin

EmuNAND:

EmuNAND CTRNAND
└── data
    └── 00000000000000000000000000000000    //This will be random.
        └── sysdata
            └── 00010017
                └── 00000000
                    └── partitionA.bin

The address is 0xA9E8. The value is 64-bit and will be different across systems; there are no mathmatical solutions to determine the value to stick here, but I will say it's close to the value at address 0xA9E0 regardless of the system, and if I am reading the information right, that address is the "Leap Year Counter (read By PTM)". I recommend you do NOT manipulate any of the data manually here unless you know what you are doing. An update from @ihaveahax shows that the information seems to be "dynamic" depending on the system, even so, continue reading if you still wish to fix this.

For those that may want to fix this if you already set your offset to zero, it's super easy.

Steps:
1. Remove the bottom plate of your respective system.
2. Remove the battery and leave it out for a few seconds.
3. Stick the battery back into the system.
4. Place your bottom plate back onto your respective system.

I don't know how the original values are determined to begin with when these systems are manufactured and what not. The end result will be fixed values, and you don't need to be afraid of these values resetting as at some point you'll be replacing that battery anyways once the sucker starts losing its capability of holding a charge. These resets are normal behavior and is basic protocol for any system whenever the primary source of power is lost, a dying battery in majority of cases. Case in point this change is not permanent nor is damaging to anything, stuff like SpotPass may break from this but that should correct itself eventually (likely after 24 hours, you'll have to check on how that works yourself with some Googling).

Fun Fact: (Something I knew but something most may not)
Did you know that if you remove the battery from the system while it is still on the charger, the date, time, and real time clock data will remain intact? Pretty straight forward as to why this occurs, but for those who don't understand why, it's because the system draws enough power while being on the charger, making it capable of maintaining the information without a battery. Another neat thing is sticking the battery back into the system while it is charging forces the system to stop charging from the charger until you unplug it and plug it back in, a neat mechanism to prevent you from damaging the system or shocking yourself.

 

[Kwyjor]

You missed the entirety of my point. I asked my question and I did have something to say

Everyone asks questions and has something to say. I asked a question and had something to say. If everyone wrote subject lines like that then the forum would be completely impossible to navigate. Selecting an appropriate subject line can help direct people to whatever point you are trying to make. It's all the more unfortunate considering there might actually be useful information in this thread now and not just "a question and something to say".

 

[ihaveahax]

The address is 0xA9E8. The value is 64-bit and will be different across systems; there are no mathmatical solutions to determine the value to stick here, but I will say it's close to the value at address 0xA9E0 regardless of the system, and if I am reading the information right, that address is the "Leap Year Counter (read By PTM)". I recommend you do NOT manipulate any of the data manually here unless you know what you are doing.

There is no fixed offset for this block. The correct way to find the offset is to parse the header for block 0x00030001 (which is actually "User time offset").
Example if one was to use pyctr.type.config:

from pyctr.type.config import ConfigSaveReader

cfg = ConfigSaveReader.from_file('config')
cfg.set_block(0x00030001, b'\0\0\0\0\0\0\0\0')
with open('confignew', 'wb') as o:
    o.write(cfg.to_bytes())

If you want to programmatically change this with a 3DS program, use the libctru function CFG_SetConfigInfoBlk4. (Though there isn't really a need to change it *from* 0 since it will likely just trigger anti-timetravel again.)

 

[DeadSkullzJr]

There is no fixed offset for this block. The correct way to find the offset is to parse the header for block 0x00030001 (which is actually "User time offset").
Example if one was to use pyctr.type.config:

from pyctr.type.config import ConfigSaveReader

cfg = ConfigSaveReader.from_file('config')
cfg.set_block(0x00030001, b'\0\0\0\0\0\0\0\0')
with open('confignew', 'wb') as o:
    o.write(cfg.to_bytes())

If you want to programmatically change this with a 3DS program, use the libctru function CFG_SetConfigInfoBlk4. (Though there isn't really a need to change it *from* 0 since it will likely just trigger anti-timetravel again.)

Just looked into it, here is what I encountered which seems odd to me. So you mention there is no fixed address for this, it's apparent this seems to be more "dynamic" than I initially thought, and you are right, I examined another system and it turns out the data for this is not set in the address I mentioned yesterday (corrected my statement). What I don't understand however is how FOUR of my systems had that data in the same address but my other system had it some place else. Now I know this isn't like working with memory given the nature of how this is versus memory is entirely different, there are no pointers and what not jumping around here that I can tell, what I don't get is how and why this is like so for one of these units versus the other four I checked against.

The systems I checked against that had the same data in the same location:
- New Nintendo 2DS XL (USA) (SysNAND 11.5.0-38U, EmuNAND 11.15.0-47U)
- New Nintendo 3DS (Japan) (SysNAND 10.6.0-31J, EmuNAND 11.15.0-47J)
- New Nintendo 3DS XL (USA) (SysNAND 11.15.0-47U)
- Nintendo 3DS XL (USA) (SysNAND 11.15.0-47U)

The system I checked against that had the data in a different location:
- Nintendo 3DS (USA) (SysNAND 4.2.0-9U) (EmuNAND 11.15.0-47U)

 

[ihaveahax]

Just looked into it, here is what I encountered which seems odd to me. So you mention there is no fixed address for this, it's apparent this seems to be more "dynamic" than I initially thought, and you are right, I examined another system and it turns out the data for this is not set in the address I mentioned yesterday (corrected my statement). What I don't understand however is how FOUR of my systems had that data in the same address but my other system had it some place else. Now I know this isn't like working with memory given the nature of how this is versus memory is entirely different, there are no pointers and what not jumping around here that I can tell, what I don't get is how and why this is like so for one of these units versus the other four I checked against.

The systems I checked against that had the same data in the same location:
- New Nintendo 2DS XL (USA) (SysNAND 11.5.0-38U, EmuNAND 11.15.0-47U)
- New Nintendo 3DS (Japan) (SysNAND 10.6.0-31J, EmuNAND 11.15.0-47J)
- New Nintendo 3DS XL (USA) (SysNAND 11.15.0-47U)
- Nintendo 3DS XL (USA) (SysNAND 11.15.0-47U)

The system I checked against that had the data in a different location:
- Nintendo 3DS (USA) (SysNAND 4.2.0-9U) (EmuNAND 11.15.0-47U)

The reason could be as simple as that one module managed to create a config block before another, sort-of like a race condition. All the offsets are in the config savegame header, the format of which is documented on the 3dbrew page.

 

[Halvorsen]

Ok, thanks for the help, really appreciate it!

In case you're curious, the guide has now been updated