Hacking Fake Update Server

  • Thread starter Thread starter digitydogs
  • Start date Start date
  • Views Views 9,362
  • Replies Replies 56
digitydogs said:
Exactly its easily done via a proxy or by altering the DNS server on your networks hosts file.

Oh, wow *facepalm* I should have thought of that. This is now getting way more interesting. I'd assist if I had enough network knowledge (but it's mostly Unix for me) but I would be willing to host test servers and updates. In fact, I've picked up on a couple channel projects and I'll go ahead and design an elf/dol forwarder channel with a nice theme for this 'hack' once you come up with a title.
PS: NetwiirkHack?

EDIT:
I went ahead and did a black-and-white-coffee-fueled-I-am-just-showing-off-quick-sketch of a channel concept. Many things are missing, like the proper credits (if done), colors, backgrounds, and a few other things. The channel would simply be an elf/dol forwarder with a proper banner. Quite simply, you would install the channel using the network setup, put a configuration file on the SD card (To point it to the homebrew. I won't provide the HBC installer, as that is illegal, but I would provide the conf and simple folder structure) along with the desired homebrew, and then launch the channel. (correct me if I messed up somewhere digitydogs)
Wii%20Concept.png
 
Yes, you can spoof the IP of the Nintendo Wii update servers, or even redirect traffic to an IP of your choice -- but correct me if I'm wrong: it doesn't mean the Wii will install your unsigned code.
 
knigitz said:
Yes, you can spoof the IP of the Nintendo Wii update servers, or even redirect traffic to an IP of your choice -- but correct me if I'm wrong: it doesn't mean the Wii will install your unsigned code.

Yeah, that was my worry about this. I'm guessing 3.2 or lower users might be able to.
 
@shadow wolf... There wouldn't be a channel needed for this it would operate on the systems normal update....

@knigitz... We already know the root certificates, title and TMD keys used to sign. Shouldn't be hard to re-use these to sign our own copies.
 
And if Nintendo was really smart, they would check an encrypted checksum hosted on their own servers to ensure the code is properly signed AND that the files are not modified when installing any IOS. If they did this over a secure connection and required both sides to authenticate properly it would really slow down your guys plans.

Also, I'm pretty sure they could use some low level protocols to verify their source which hosts the IOS is indeed real and not faked, and also check for certificates and such. (I believe some network protocols allow for things like this?)

Just saying.

Posts merged

digitydogs said:
@shadow wolf... There wouldn't be a channel needed for this it would operate on the systems normal update....

@knigitz... We already know the root certificates, title and TMD keys used to sign. Shouldn't be hard to re-use these to sign our own copies.

You're talking about signing for games, no? Not so much signing an IOS to install without first using the Twilight Hack method to install unsigned code to launch and install other unsigned code through...? Like I said, correct me if I'm wrong and I will stand corrected.
smile.gif
 
If they did this we would just alter our server to match. as long as packet sniffing and programmers exist there will always be a workaround. Especially since we already have hacked wii's that we can use to analize any process they start. But in the meantime, STOP GIVING THEM IDEAS!

And no i mean we have the Certs sigs and title and tmd sigs used on the updates themselves.
 
digitydogs said:
If they did this we would just alter our server to match. as long as packet sniffing and programmers exist there will always be a workaround. But in the meantime, STOP GIVING THEM IDEAS!

And no i mean we have the Certs sigs and title and tmd sigs used on the updates themselves.
Well, then I stand corrected on that part.
smile.gif
 
knigitz said:
And if Nintendo was really smart, they would check an encrypted checksum hosted on their own servers to ensure the code is properly signed AND that the files are not modified when installing any IOS. If they did this over a secure connection and required both sides to authenticate properly it would really slow down your guys plans.

Also, I'm pretty sure they could use some low level protocols to verify their source which hosts the IOS is indeed real and not faked, and also check for certificates and such. (I believe some network protocols allow for things like this?)

Just saying.

Posts merged

digitydogs said:
@shadow wolf... There wouldn't be a channel needed for this it would operate on the systems normal update....

@knigitz... We already know the root certificates, title and TMD keys used to sign. Shouldn't be hard to re-use these to sign our own copies.

You're talking about signing for games, no? Not so much signing an IOS to install without first using the Twilight Hack method to install unsigned code to launch and install other unsigned code through...? Like I said, correct me if I'm wrong and I will stand corrected.
smile.gif

if you are thinking for the big N to make them hack proof , I guess you made the wrong turn and came to Hacking Town , so do me a favor before you end up flaming the forums please go to the Big N forums and brag about your ideas there , maybe the will have an opening job for you as a security guard or somthing to make you happy , peace out
wink.gif
 
any way to make a quick test about this, like puting something in the PC and make the Wii just try to read it??
 
digitydogs said:
And no i mean we have the Certs sigs and title and tmd sigs used on the updates themselves.

Yes, we have what we need to trucha-sign stuff. This won't be of any help on a vanilla post 23oct-Wii without HBC -- since it wont run trucha-signed binaries anymore -- which sort of prevents this from excluding twilight hack out of the picture completetly.

The patching on the fly from a spoofed update server will still be really nifty if realized, since that would prevent all the facepalms for "oooh fuck, i updated by mistake(yea right), and now HBC doesn't work anymore ... *sniff* *sniff*" kind of posts. You'll still need to be already jailbroken though.
 
digitydogs said:
@shadow wolf... There wouldn't be a channel needed for this it would operate on the systems normal update....

@knigitz... We already know the root certificates, title and TMD keys used to sign. Shouldn't be hard to re-use these to sign our own copies.

But...that is where I am heading. We can always install channels via the system update (Mii Channel for example) so we can always fudge an update and install this channel to install the HBC or run desired homebrew. I'm just saying...
 
digitydogs said:
Exactly its easily done via a proxy or by altering the DNS server on your networks hosts file.

A HOSTS file does not list a DNS server, and technically it is not your "networks" HOSTS file. It is your client's HOSTS file. A HOSTS file sort of "replaces" a DNS server. For name resolution it is possible for a client (i.e. a computer) to read a HOSTS file (located on the computer) before contacting a DNS server to resolve an FQDN (fully qualified domain name) to an IP address.

AFAIK we have no idea if the Wii uses a HOSTS file (highly unlikely), and if it did how would you alter it without homebrew enabled?

A proxy is also not really what would be used in this case.

An alternate DNS server on the network can easily be used to redirect the Wii to a different IP address for updates. Run a DNS service on a computer on your LAN and configure the Wii to use that computer as your DNS server.

This is what was done for the PSO hack on the GameCube. It's fairly simple to write a PC application that will accept the Wii's DNS query and return the IP address that you want the Wii to connect to for updates. I've done it before for a PSOLoad replacement I wrote for the GC.
 
Running a local DNS server is what i was referring to (shouldn't have said HOSTS) . A few posts before that i explained it better. A proxy server would also work on the local network because i would just point the nintendo server addy to another local computer, though i do think the local dns server is a better/simpler route. Thanks for the input though, Always interested in other points of view... never know what i might miss
smile.gif
I'm rather bad with actual programming, think you could write us up a version for the wii and just have a small box pop up asking what addy to redirect to? this would save the trouble of using a full fledged DNS server, and help towards the end of being able to package all of this without illegal code in it, as i plan (assuming i can get it all working) to release everything but the actual update content in the future (using free or Open source software for the server backend ).
 
This might be possible if you make the dns for the wii update site point to your computer or something of the sort.
 
Packet Sniff info courtesy of Wiili.org...


Packet Info
Flags: 0x00
Status: 0x04 Encrypted
Packet Length: 1418
Timestamp: 11:59:22.562047600 11/19/2006
Data Rate: 22 11.0 Mbps
Channel: 7 2442 MHz
Signal Level: 41%
Noise Level: 0%
802.11 MAC Header

Version: 0
Type: � Data
Subtype: �00 Data Only
Frame Control Flags: �000001
0... .... Non-strict order
.0.. .... WEP Not Enabled
..0. .... No More Data
...0 .... Power Management - active mode
.... 0... This is not a Re-Transmission
.... .0.. Last or Unfragmented Frame
.... ..0. Not an Exit from the Distribution System
.... ...1 To the Distribution System

Duration: 223 Microseconds
BSSID: 00:18:39:87:19:8D
Source: 00:17:AB:42:A4:8F
Destination: 00:18:39:87:19:8B
Seq. Number: 764
Frag. Number: 0

802.2 Logical Link Control (LLC) Header

Dest. SAP: 0xAA SNAP
Source SAP: 0xAA SNAP
Command: 0x03 Unnumbered Information
Vendor ID: 0x000000
Protocol Type: 0x0800 IP

IP Header - Internet Protocol Datagram

Version: 4
Header Length: 5 (20 bytes)
Type of Service: �000000
000. .... Precedence: Routine
...0 .... Normal Delay
.... 0... Normal Throughput
.... .0.. Normal Reliability
.... ..0. ECT bit - transport protocol will ignore the CE bit
.... ...0 CE bit - no congestion

Total Length: 1374
Identifier: 8918
Fragmentation Flags: �0
0.. Reserved
.1. Do Not Fragment
..0 Last Fragment

Fragment Offset: 0 (0 bytes)
Time To Live: 64
Protocol: 6 TCP - Transmission Control Protocol
Header Checksum: 0x13EF
Source IP Address: 192.168.2.32
Dest. IP Address: 209.67.106.201
No IP Options

TCP - Transport Control Protocol

Source Port: 56974
Destination Port: 80 http
Sequence Number: 3416390245
Ack Number: 1771989307
Offset: 5 (20 bytes)
Reserved: �0000

Flags: �1000
0. .... (No Urgent pointer)
.1 .... Ack
.. 1... Push
.. .0.. (No Reset)
.. ..0. (No SYN)
.. ...0 (No FIN)

Window: 32768
Checksum: 0x9AD3
Urgent Pointer: 0
No TCP Options

HTTP - Hyper Text Transfer Protocol

Command: POST
URI: <a href="http://nus.shop.wii.com:80/nus/services/NetUpdateSOAP" target="_blank">http://nus.shop.wii.com:80/nus/services/NetUpdateSOAP</a>
Version: HTTP/1.1<CR><LF>
Host: nus.shop.wii.com<CR><LF>
Accept: text/html, image/gif, image/jpeg, */*<CR><LF>
Content-type: text/xml; charset=utf-8<CR><LF>
Content-length: 1046<CR><LF>
User-Agent: wii libnup/1.0<CR><LF>
SOAPAction: "urn:nus.wsapi.broadon.com/GetSystemUpdate"<CR><LF><CR><LF>
Line 1: <?xml version="1.0" encoding="UTF-8"?><LF>
Line 2: <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"<LF>
Line 3: xmlns:xsd="http://www.w3.org/2001/XMLSchema"<LF>
Line 4: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><LF>
Line 5: <soapenv:Body><LF>
Line 6: <GetSystemUpdateRequest xmlns="urn:nus.wsapi.broadon.com"><LF>
Line 7: <Version>1.0</Version><LF>
Line 8: <MessageId>13198105123219138</MessageId><LF>
Line 9: <DeviceId>4362227772</DeviceId><LF>
Line 10: <RegionId>USA</RegionId><LF>
Line 11: <CountryCode>US</CountryCode><LF>
Line 12: <TitleVersion><LF>
Line 13: <TitleId>0000000100000001</TitleId><LF>
Line 14: <Version>2</Version><LF>
Line 15: </TitleVersion><LF>
Line 16: <TitleVersion><LF>
Line 17: <TitleId>0000000100000002</TitleId><LF>
Line 18: <Version>33</Version><LF>
Line 19: </TitleVersion><LF>
Line 20: <TitleVersion><LF>
Line 21: <TitleId>0000000100000009</TitleId><LF>
Line 22: <Version>516</Version><LF>
Line 23: </TitleVersion><LF>
Line 24: <Attribute>1</Attribute><LF>
Line 25: <AuditData></AuditData><LF>
Line 26: </GetSystemUpdateRequest><LF>
Line 27: </soapenv:Body><LF>
Line 28: </soapenv:Envelope><LF>
Extra bytes (Padding):
.....S:. 00 00 00 00 FD 53 3A 96
FCS - Frame Check Sequence
FCS (Calculated): 0xF9FE0CA3

Second
Packet Info

Flags: 0x00
Status: 0x04 Encrypted
Packet Length: 1544
Timestamp: 11:59:22.642730600 11/19/2006
Data Rate: 22 11.0 Mbps
Channel: 7 2442 MHz
Signal Level: 50%
Noise Level: 0%

802.11 MAC Header

Version: 0
Type: � Data
Subtype: �00 Data Only
Frame Control Flags: �000010
0... .... Non-strict order
.0.. .... WEP Not Enabled
..0. .... No More Data
...0 .... Power Management - active mode
.... 0... This is not a Re-Transmission
.... .0.. Last or Unfragmented Frame
.... ..1. Exit from the Distribution System
.... ...0 Not to the Distribution System

Duration: 213 Microseconds
Destination: 00:17:AB:42:A4:8F
BSSID: 00:18:39:87:19:8D
Source: 00:18:39:87:19:8B
Seq. Number: 1857
Frag. Number: 0

802.2 Logical Link Control (LLC) Header

Dest. SAP: 0xAA SNAP
Source SAP: 0xAA SNAP
Command: 0x03 Unnumbered Information
Vendor ID: 0x000000
Protocol Type: 0x0800 IP

IP Header - Internet Protocol Datagram

Version: 4
Header Length: 5 (20 bytes)
Type of Service: �100000
001. .... Precedence: Priority
...0 .... Normal Delay
.... 0... Normal Throughput
.... .0.. Normal Reliability
.... ..0. ECT bit - transport protocol will ignore the CE bit
.... ...0 CE bit - no congestion

Total Length: 1500
Identifier: 37015
Fragmentation Flags: �0
0.. Reserved
.1. Do Not Fragment
..0 Last Fragment

Fragment Offset: 0 (0 bytes)
Time To Live: 241
Protocol: 6 TCP - Transmission Control Protocol
Header Checksum: 0xF48E
Source IP Address: 209.67.106.201
Dest. IP Address: 192.168.2.32
No IP Options

TCP - Transport Control Protocol

Source Port: 80 http
Destination Port: 56974
Sequence Number: 1771989307
Ack Number: 3416391579
Offset: 5 (20 bytes)
Reserved: �0000

Flags: �1000
0. .... (No Urgent pointer)
.1 .... Ack
.. 1... Push
.. .0.. (No Reset)
.. ..0. (No SYN)
.. ...0 (No FIN)

Window: 5714
Checksum: 0xC5FF
Urgent Pointer: 0
No TCP Options

HTTP - Hyper Text Transfer Protocol

Version: HTTP/1.1
Status: 200
Reason: <CR><LF>
Date: Sun, 19 Nov 2006 19:59:19 GMT<CR><LF>
Server: Apache/2.0.48<CR><LF>
Content-Type: text/xml; charset=utf-8<CR><LF>
Transfer-Encoding: chunked<CR><LF><CR><LF>
Line 1: 546<CR><LF>
Line 2: <?xml version="1.0" encoding="utf-8"?><soapenv:Envelope xmlns:soapenv="http://sc
Line hemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" x
Line mlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><GetSystemUpd
Line ateResponse xmlns="urn:nus.wsapi.broadon.com"><Version>1.0</Version><DeviceId>43
Line 62227772</DeviceId><MessageId>13198105123219138</MessageId><TimeStamp>1163966359
Line 696</TimeStamp><ErrorCode>0</ErrorCode><ContentPrefixURL>http://nus.cdn.shop.wii
Line .com/ccs/download</ContentPrefixURL><UncachedContentPrefixURL>http://ccs.shop.wi
Line i.com/ccs/download</UncachedContentPrefixURL><TitleVersion><TitleId>000000010000
Line 0002</TitleId><Version>97</Version><FsSize>21839872</FsSize></TitleVersion><Titl
Line eVersion><TitleId>000000010000000B</TitleId><Version>10</Version><FsSize>1654784
Line </FsSize></TitleVersion><TitleVersion><TitleId>000000010000000C</TitleId><Versio
Line n>6</Version><FsSize>1654784</FsSize></TitleVersion><TitleVersion><TitleId>00000
Line 0010000000D</TitleId><Version>10</Version><FsSize>1654784</FsSize></TitleVersion
Line ><TitleVersion><TitleId>0000000100000100</TitleId><Version>2</Version><FsSize>65
Line 536</FsSize></TitleVersion><TitleVersion><TitleId>0000000100000101</TitleId><Ver
Line sion>4</Version><FsSize>229376</FsSize></TitleVersion><UploadAuditData>1</Upload
Line AuditData></GetSystemUpdateResp
Extra bytes (Padding):
....J... 00 00 00 00 4A F8 DE C7
FCS - Frame Check Sequence
FCS (Calculated): 0xB61CB005

Firmware Update
First Part

* SOAP SERVER ADDRESS:
<a href="http://nus.shop.wii.com:80/nus/services/NetUpdateSOAP" target="_blank">http://nus.shop.wii.com:80/nus/services/NetUpdateSOAP</a>

* SOAPaction:
urn:nus.wsapi.broadon.com/GetSystemUpdate

Message

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<GetSystemUpdateRequest xmlns="urn:nus.wsapi.broadon.com">
<Version>1.0</Version>
<MessageId>13198105123219138</MessageId>
<DeviceId>4362227772</DeviceId>
<RegionId>USA</RegionId>
<CountryCode>US</CountryCode>
<TitleVersion>
<TitleId>0000000100000001</TitleId>
<Version>2</Version>
</TitleVersion>
<TitleVersion>
<TitleId>0000000100000002</TitleId>
<Version>33</Version>
</TitleVersion>
<TitleVersion>
<TitleId>0000000100000009</TitleId>
<Version>516</Version>
</TitleVersion>
<Attribute>1</Attribute>
<AuditData></AuditData>
</GetSystemUpdateRequest>
</soapenv:Body>
</soapenv:Envelope>

Response

<?xml version="1.0" encoding="utf-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<GetSystemUpdateResponse xmlns="urn:nus.wsapi.broadon.com">
<Version>1.0</Version>
<DeviceId>4362227772</DeviceId>
<MessageId>13198105123219138</MessageId>
<TimeStamp>1163966359696</TimeStamp>
<ErrorCode>0</ErrorCode>
<ContentPrefixURL>http://nus.cdn.shop.wii.com/ccs/download</ContentPrefixURL>
<UncachedContentPrefixURL>http://ccs.shop.wii.com/ccs/download</UncachedContentPrefixURL>
<TitleVersion><TitleId>0000000100000002</TitleId>
<Version>97</Version>
<FsSize>21839872</FsSize>
</TitleVersion><TitleVersion>
<TitleId>000000010000000B</TitleId>
<Version>10</Version>
<FsSize>1654784</FsSize>
</TitleVersion>
<TitleVersion>
<TitleId>000000010000000C</TitleId>
<Version>6</Version>
<FsSize>1654784</FsSize>
</TitleVersion>
<TitleVersion>
<TitleId>000000010000000D</TitleId>
<Version>10</Version>
<FsSize>1654784</FsSize>
</TitleVersion>
<TitleVersion>
<TitleId>0000000100000100</TitleId>
<Version>2</Version>
<FsSize>65536</FsSize>
</TitleVersion>
<TitleVersion>
<TitleId>0000000100000101</TitleId>
<Version>4</Version>
<FsSize>229376</FsSize>
</TitleVersion>
<UploadAuditData>1</UploadAuditData>
</GetSystemUpdateResponse>
</soapenv:Body>
</soapenv:Envelope>

Unfiltered

1.043622277721319810512321913811641804558190http://nus.cdn.shop.wii.com/ccs/downloadhttp://ccs.shop.wii.com/ccs/download00000001000000029721839872000000010000000B101654784000000010000000C61654
84000000010000000D1016547840000000100000100265536000000010000010142293760

* FIXED:
Version: 1.0
DeviceID: 4362227772
MessageID: 13198105123219138
TimeStamp: 1163966359696
ErrorCode: 0
DownloadURL: <a href="http://nus.cdn.shop.wii.com/ccs/download" target="_blank">http://nus.cdn.shop.wii.com/ccs/download</a> (Cached)
DownloadURL: <a href="http://ccs.shop.wii.com/ccs/download" target="_blank">http://ccs.shop.wii.com/ccs/download</a> (Uncached)

0000000100000002/tmd.97 Filesize: 21839872
000000010000000B/tmd.10 Filesize: 1654784
000000010000000C/tmd.6 Filesize: 1654784
000000010000000D/tmd.10 Filesize: 1654784
0000000100000100/tmd.2 Filesize: 65536
0000000100000101/tmd.4 Filesize: 2293760


Other

By using packet sniffing, it has been found that these are a few of the Wii update links (all in .bin format)...

<a href="http://ccs.shop.wii.com/ccs/download/000000010000000b/00000008" target="_blank">http://ccs.shop.wii.com/ccs/download/00000...00000b/00000008</a> <a href="http://ccs.shop.wii.com/ccs/download/000000010000000b/00000009" target="_blank">http://ccs.shop.wii.com/ccs/download/00000...00000b/00000009</a> <a href="http://ccs.shop.wii.com/ccs/download/0000000100000002/00000009" target="_blank">http://ccs.shop.wii.com/ccs/download/00000...000002/00000009</a> <a href="http://ccs.shop.wii.com/ccs/download/0000000100000002/0000000a" target="_blank">http://ccs.shop.wii.com/ccs/download/00000...000002/0000000a</a>
 

Site & Scene News

Popular threads in this forum