iQue Player hacking possibility with ique_diag.exe?
- Thread starter HNKii
- Start date
- Views 53,826
- Replies 243
- Likes 7
Dusting off this old account to post here 
I recently noticed some iQue references in certain things, and noticed how the iQue Player, security-wise, sounded very familiar.. it looked like a prototype WiI!
Some further investigation showed that the founder of iQue also founded BroadOn (the company that did a lot of security-related stuff for the Wii; designed the Starlet, coded IOS etc).
More investigation (getting exceptions out of the iQue Player webservices) showed BroadOn was definitely involved here as well.
Check an SASK you have to hand. Then look at the page on wiibrew about NAND (128KB of boot1, then 1MB-128KB of two copies of boot2, stored in a modified WAD format).
Then double check the SASK and see how close the two are. 64KB of presumably boot1 (this is the same across all known SASKs! by the way, the boot1 key is different from the Wii's), 16KB of presumably boot2 header (ticket, certs, CRL, much like a WAD -- WADs can contain a CRL but no WAD ever did; and the "TMD" isn't a thing with iQue), then boot2 content (size described by the boot2 ticket); then 16KB of presumably system menu header, then system menu content.
And notice that two SASKs stop after the boot2 header (and even have zero content length in the ticket!) ; and only the latest 5 SASKs (1091, 1095, 1099, 1101, 1106) have a second boot-title.
I quickly hacked together a ticket dumper based on emoose's research (a couple of the fields are probably wrong though, I took a guess at what they were based on a few tickets): https://pastebin.com/2NHCde84
It can handle SASKs, ticket.sys files, raw ticket.sys tickets, and raw tickets.
Using it, you can see that with the SASKs with two titles, the contentIDs are different.
1091: first ticket has contentID=1091, second ticket has contentID=1092
1095: first ticket has contentID=1095, second ticket has contentID=1096
1099: first ticket has contentID=1095, second ticket has contentID=1100 (and this SASK only differs from 1095 starting at the second ticket!)
1101: first ticket has contentID=1095, second ticket has contentID=1102 (and parts of the first ticket and the first contents (starting at offset 0x1000 of the content) differ from 1099/1095!)
1106: first ticket has contentID=1095, second ticket has contentID=1107 (and parts of the first ticket and the first contents (starting at offset 0x15300 of the content) differs from 1101!)
I'm working on reversing the PC-side applications; that's about the only thing I can do, as I don't actually have an iQue Player. (Anyone willing to sell me one at a reasonable price? I'm located in the UK.)
I recently noticed some iQue references in certain things, and noticed how the iQue Player, security-wise, sounded very familiar.. it looked like a prototype WiI!
Some further investigation showed that the founder of iQue also founded BroadOn (the company that did a lot of security-related stuff for the Wii; designed the Starlet, coded IOS etc).
More investigation (getting exceptions out of the iQue Player webservices) showed BroadOn was definitely involved here as well.
Check an SASK you have to hand. Then look at the page on wiibrew about NAND (128KB of boot1, then 1MB-128KB of two copies of boot2, stored in a modified WAD format).
Then double check the SASK and see how close the two are. 64KB of presumably boot1 (this is the same across all known SASKs! by the way, the boot1 key is different from the Wii's), 16KB of presumably boot2 header (ticket, certs, CRL, much like a WAD -- WADs can contain a CRL but no WAD ever did; and the "TMD" isn't a thing with iQue), then boot2 content (size described by the boot2 ticket); then 16KB of presumably system menu header, then system menu content.
And notice that two SASKs stop after the boot2 header (and even have zero content length in the ticket!) ; and only the latest 5 SASKs (1091, 1095, 1099, 1101, 1106) have a second boot-title.
I quickly hacked together a ticket dumper based on emoose's research (a couple of the fields are probably wrong though, I took a guess at what they were based on a few tickets): https://pastebin.com/2NHCde84
It can handle SASKs, ticket.sys files, raw ticket.sys tickets, and raw tickets.
Using it, you can see that with the SASKs with two titles, the contentIDs are different.
1091: first ticket has contentID=1091, second ticket has contentID=1092
1095: first ticket has contentID=1095, second ticket has contentID=1096
1099: first ticket has contentID=1095, second ticket has contentID=1100 (and this SASK only differs from 1095 starting at the second ticket!)
1101: first ticket has contentID=1095, second ticket has contentID=1102 (and parts of the first ticket and the first contents (starting at offset 0x1000 of the content) differ from 1099/1095!)
1106: first ticket has contentID=1095, second ticket has contentID=1107 (and parts of the first ticket and the first contents (starting at offset 0x15300 of the content) differs from 1101!)
I'm working on reversing the PC-side applications; that's about the only thing I can do, as I don't actually have an iQue Player. (Anyone willing to sell me one at a reasonable price? I'm located in the UK.)
Nice work. You can get one of taobao, just make sure it has at least one full game besides the dr mario game, to ensure the ique been updated to use on a home pc.Dusting off this old account to post here
I recently noticed some iQue references in certain things, and noticed how the iQue Player, security-wise, sounded very familiar.. it looked like a prototype WiI!
Some further investigation showed that the founder of iQue also founded BroadOn (the company that did a lot of security-related stuff for the Wii; designed the Starlet, coded IOS etc).
More investigation (getting exceptions out of the iQue Player webservices) showed BroadOn was definitely involved here as well.
Check an SASK you have to hand. Then look at the page on wiibrew about NAND (128KB of boot1, then 1MB-128KB of two copies of boot2, stored in a modified WAD format).
Then double check the SASK and see how close the two are. 64KB of presumably boot1 (this is the same across all known SASKs! by the way, the boot1 key is different from the Wii's), 16KB of presumably boot2 header (ticket, certs, CRL, much like a WAD -- WADs can contain a CRL but no WAD ever did; and the "TMD" isn't a thing with iQue), then boot2 content (size described by the boot2 ticket); then 16KB of presumably system menu header, then system menu content.
And notice that two SASKs stop after the boot2 header (and even have zero content length in the ticket!) ; and only the latest 5 SASKs (1091, 1095, 1099, 1101, 1106) have a second boot-title.
I quickly hacked together a ticket dumper based on emoose's research (a couple of the fields are probably wrong though, I took a guess at what they were based on a few tickets): https://pastebin.com/2NHCde84
It can handle SASKs, ticket.sys files, raw ticket.sys tickets, and raw tickets.
Using it, you can see that with the SASKs with two titles, the contentIDs are different.
1091: first ticket has contentID=1091, second ticket has contentID=1092
1095: first ticket has contentID=1095, second ticket has contentID=1096
1099: first ticket has contentID=1095, second ticket has contentID=1100 (and this SASK only differs from 1095 starting at the second ticket!)
1101: first ticket has contentID=1095, second ticket has contentID=1102 (and parts of the first ticket and the first contents (starting at offset 0x1000 of the content) differ from 1099/1095!)
1106: first ticket has contentID=1095, second ticket has contentID=1107 (and parts of the first ticket and the first contents (starting at offset 0x15300 of the content) differs from 1101!)
I'm working on reversing the PC-side applications; that's about the only thing I can do, as I don't actually have an iQue Player. (Anyone willing to sell me one at a reasonable price? I'm located in the UK.)
If it hasn't had that update, does it just not show up when you connect it to USB?
I'd be interested in writing some of those other SASKs to NAND, but I guess it'd be best to have two carts for that. Has anyone tried dumping a full NAND image and then restoring it to the cart of some other iQue, by the way?
It wont show up as a usb device unless updated. I think someone on assembler games forums dumped the nand and rewrote it to the ique. He ended up bricking it. The memory cards arnt shareable. Meaning the ique will only work with the memory card it was assigned to.
It wont show up as a usb device unless updated. I think someone on assembler games forums dumped the nand and rewrote it to the ique. He ended up bricking it. The memory cards arnt shareable. Meaning the ique will only work with the memory card it was assigned to.
I'm aware the NAND has console unique crypto.
I meant, can you write one NAND image to another cart and use the second cart in the console where the first cart's NAND dump came from?
Im not sure about that other than the card would brick when being rewritten, so i assume it would also when doing it to a seperate card
Yeah, I gave some other "speculations" about Wii similarities some posts back (end of page 5 and 6 of this thread), I think you have the skills to solve this thingDusting off this old account to post here
I recently noticed some iQue references in certain things, and noticed how the iQue Player, security-wise, sounded very familiar.. it looked like a prototype WiI!
Some further investigation showed that the founder of iQue also founded BroadOn (the company that did a lot of security-related stuff for the Wii; designed the Starlet, coded IOS etc).
More investigation (getting exceptions out of the iQue Player webservices) showed BroadOn was definitely involved here as well.
Check an SASK you have to hand. Then look at the page on wiibrew about NAND (128KB of boot1, then 1MB-128KB of two copies of boot2, stored in a modified WAD format).
Then double check the SASK and see how close the two are. 64KB of presumably boot1 (this is the same across all known SASKs! by the way, the boot1 key is different from the Wii's), 16KB of presumably boot2 header (ticket, certs, CRL, much like a WAD -- WADs can contain a CRL but no WAD ever did; and the "TMD" isn't a thing with iQue), then boot2 content (size described by the boot2 ticket); then 16KB of presumably system menu header, then system menu content.
And notice that two SASKs stop after the boot2 header (and even have zero content length in the ticket!) ; and only the latest 5 SASKs (1091, 1095, 1099, 1101, 1106) have a second boot-title.
I quickly hacked together a ticket dumper based on emoose's research (a couple of the fields are probably wrong though, I took a guess at what they were based on a few tickets): https://pastebin.com/2NHCde84
It can handle SASKs, ticket.sys files, raw ticket.sys tickets, and raw tickets.
Using it, you can see that with the SASKs with two titles, the contentIDs are different.
1091: first ticket has contentID=1091, second ticket has contentID=1092
1095: first ticket has contentID=1095, second ticket has contentID=1096
1099: first ticket has contentID=1095, second ticket has contentID=1100 (and this SASK only differs from 1095 starting at the second ticket!)
1101: first ticket has contentID=1095, second ticket has contentID=1102 (and parts of the first ticket and the first contents (starting at offset 0x1000 of the content) differ from 1099/1095!)
1106: first ticket has contentID=1095, second ticket has contentID=1107 (and parts of the first ticket and the first contents (starting at offset 0x15300 of the content) differs from 1101!)
I'm working on reversing the PC-side applications; that's about the only thing I can do, as I don't actually have an iQue Player. (Anyone willing to sell me one at a reasonable price? I'm located in the UK.)
Given the SERVER file in the iQue@Home folder, would it, with a lot of research, be possible to create a custom server to download games? I don't have an iQue, but I find this really interesting and I installed the software.
- Joined
- Jan 28, 2014
- Messages
- 477
- Trophies
- 0
- Location
- Mario Kart Wii-DS Link Play Stadium
- XP
- 603
- Country
Awesome! Just as I expected, the iQue Player data/security system should be very similar to that of the Wii. After all, Yen helped Nintendo on hardware development for the original N64 all the way to Wii. Guess the team just recycled iQue Player protection as they didn't found anyone exploiting it.Dusting off this old account to post here
I recently noticed some iQue references in certain things, and noticed how the iQue Player, security-wise, sounded very familiar.. it looked like a prototype WiI!
Some further investigation showed that the founder of iQue also founded BroadOn (the company that did a lot of security-related stuff for the Wii; designed the Starlet, coded IOS etc).
More investigation (getting exceptions out of the iQue Player webservices) showed BroadOn was definitely involved here as well.
Check an SASK you have to hand. Then look at the page on wiibrew about NAND (128KB of boot1, then 1MB-128KB of two copies of boot2, stored in a modified WAD format).
Then double check the SASK and see how close the two are. 64KB of presumably boot1 (this is the same across all known SASKs! by the way, the boot1 key is different from the Wii's), 16KB of presumably boot2 header (ticket, certs, CRL, much like a WAD -- WADs can contain a CRL but no WAD ever did; and the "TMD" isn't a thing with iQue), then boot2 content (size described by the boot2 ticket); then 16KB of presumably system menu header, then system menu content.
And notice that two SASKs stop after the boot2 header (and even have zero content length in the ticket!) ; and only the latest 5 SASKs (1091, 1095, 1099, 1101, 1106) have a second boot-title.
I quickly hacked together a ticket dumper based on emoose's research (a couple of the fields are probably wrong though, I took a guess at what they were based on a few tickets): https://pastebin.com/2NHCde84
It can handle SASKs, ticket.sys files, raw ticket.sys tickets, and raw tickets.
Using it, you can see that with the SASKs with two titles, the contentIDs are different.
1091: first ticket has contentID=1091, second ticket has contentID=1092
1095: first ticket has contentID=1095, second ticket has contentID=1096
1099: first ticket has contentID=1095, second ticket has contentID=1100 (and this SASK only differs from 1095 starting at the second ticket!)
1101: first ticket has contentID=1095, second ticket has contentID=1102 (and parts of the first ticket and the first contents (starting at offset 0x1000 of the content) differ from 1099/1095!)
1106: first ticket has contentID=1095, second ticket has contentID=1107 (and parts of the first ticket and the first contents (starting at offset 0x15300 of the content) differs from 1101!)
I'm working on reversing the PC-side applications; that's about the only thing I can do, as I don't actually have an iQue Player. (Anyone willing to sell me one at a reasonable price? I'm located in the UK.)
Also, have you also considered the ISBN and game name of each game's ticket? The game name part can be confusing for anyone who doesn't know much Chinese as the names are store in GB2312 in hex (For instance, Super Mario 64 （神游马力欧） as C9F1 D3CE C2ED C1A6 C5B7, and instruction guide （操作指南） as B2D9 D7F7 D6B8 C4CF(You'll see these HEX values for any game manual title)
- Joined
- Jan 28, 2014
- Messages
- 477
- Trophies
- 0
- Location
- Mario Kart Wii-DS Link Play Stadium
- XP
- 603
- Country
I don't think the custom server is even necessary. All of iQue's encrypted game cache are downloadable straight from a browser: http://cds.idc.ique.com:16963/cds/download?content_id=x
(With X replacing the ID for the game data wanted).
We can basically make a file host for all those cache files, and that would probably be enough.
Extracting the game from the iQue Player using the diagnosis tool only gives you the same file as the one gained from downloading from iQue server. This is as if you ask to extract a Wiiware from the Wii and the Wii spits back a generic encrypted game data from the NUS.
Even if the iQue Player client is completely offline, as long as the cache files are located in the right directory, the client can still detect and retrieve the game (Provided that they are purchased first)
Last edited by HNKii,
Once
And yes, I know that wouldn't work...)/whatever, it might be an interesting idea to encrypt other N64 games and try to install those. Has anyone tried decompiling the .exes? Figuring out how that works would be really useful, and a lot of people would really like an English translation.
I don't think I can get an iQue Player myself, unless I can import one cheaply enough. But, you know, I like this stuff, so...
Last edited by Jhynjhiruu,
Similar threads
