You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm right now writing a pattern that has a struct, only a part of the file, encrypted with AES-128, and thinking about the lzma and the hashes thought it would be a good idea.
IV, Key, and other parameters could be taken from other structures, known files, files requested to the user, or directly asked to the user (I think this is what the in variable does? still getting the gist of the language).
As an example you have a pattern for XCI, that could see if prod.keys can be used, if not ask the user for the key, derive everything, decode the PFS0/NCA/so-on and on.
The text was updated successfully, but these errors were encountered:
I do like the idea though in general. It would again be an ImHex extension and not directly part of the language but I believe it would fit in with the others yeah. I'd be happy to merge a PR implementing it (would be a great first contribution), otherwise I'll probably get around to doing it eventually 👍
Sorry if this is not the proper repo.
I'm right now writing a pattern that has a struct, only a part of the file, encrypted with AES-128, and thinking about the lzma and the hashes thought it would be a good idea.
IV, Key, and other parameters could be taken from other structures, known files, files requested to the user, or directly asked to the user (I think this is what the
in
variable does? still getting the gist of the language).As an example you have a pattern for XCI, that could see if
prod.keys
can be used, if not ask the user for the key, derive everything, decode the PFS0/NCA/so-on and on.The text was updated successfully, but these errors were encountered: