Where did the LDN data key come from?
DRayX opened this issue · 9 comments
Where was the LDN data key (f1e7018419a84f711da714c2cf919c9c) extracted from? I can't find this key discussed anywhere else, and it isn't one of the keys expired by lockpick AFAICT.
I found it by reverse engineering the ldn sysmodule.
I see, so it's just like a static byte array in the binary?
Yes, sort of. There are two static byte arrays in the binary: 2b3ffd0a34ace2776f085f9987c2b93d and dad8fc8e2d04ad0672af4b5b485325a1. These are combined with XOR during key derivation. I don't know why Nintendo did this.
Oh, that is weird; maybe it's just a key + salt sort of thing to make them harder to find. Is the same true for the advertisement key and the hmac key?
Maybe, yeah, that's the only explanation that I can think of. It is the same for the advertisement key, but the hmac key is stored as a byte array in the es sysmodule instead.
I'm curious, why do you want to know the details?
I'm looking at re-implementing the LDN protocol as a native library (ideally cross-platform using nl80211 on linux, NDIS on Windows, TBD on Mac; I don't know much about system level Mac stuff), and I was curious where the constants in your LDN python implementation came from. Ideally, I'd prefer to avoid having keys cooked into the lib; I'd prefer they come from something like a lockpick key file, but lockpick doesn't (currently) extract these keys, so I was wondering how feasible it would be to go about doing so.
Ah that sounds like a cool project! Yeah, I don't think Lockpick parses any sysmodules. I guess that the only options are to provide them yourself, or let them be provided by the users of your library.
I chose the former for my python library for ease of use, but I understand that you might not want that. Other people are careful about hardcoding keys into their projects as well.
I hope that my python library and documentation are useful to you. 😊
Yeah, the Python library and documentation are phenomenal, much better than I usually see in homebrew / reverse-engineering projects like this (heck, they're better than half of professional protocol documentation I have to work with). Thank you so much for putting this all together, and being so responsive to my random questions :)
Yes, sort of. There are two static byte arrays in the binary:
2b3ffd0a34ace2776f085f9987c2b93danddad8fc8e2d04ad0672af4b5b485325a1. These are combined with XOR during key derivation. I don't know why Nintendo did this.
Looks like they changed this. I just opened the ldn sysmodule of the latest system version (17.0.1) in IDA and now the keys are stored in plain text. No XOR anymore.