How to identify offsets:
I have upgraded my console from 8.1J to 9.2J. Now, of course, the offsets are different than they were.
First boot into NTR CFW and enable the debugger.
Use listprocess() to get the id of the nim process. It is still 0x25 for me.
Code:
pid: 0x000dat00025, pname: nim, tid: 0004013000002c02, kpobj: fff7b7a0Now use memlayout(0x25) to get the memory layout of the nim process.
Code:
> memlayout(0x25)
null
valid memregions:
00100000 - 00302fff , size: [B]00203000[/B]
08000000 - 08000fff , size: 00001000
0ffff000 - 0fffffff , size: 00001000
1ff80000 - 1ff81fff , size: 00002000
1ffaa000 - 1ffaafff , size: 00001000
end of memlayout.Use the data() command to get a full dump of nim's memory.
Code:
> data(0x00100000, [B]0x203000[/B], filename='data.bin', pid=0x25)
null
packet: cmd = 9, dataLen = 2109440
dump saved into data.bin successfully
finishedNotice that the first argument to the dump() function is the start of the largest memory block assigned to nim, and the second (in bold) is the size of the block. This will save the full block to a file 'data.bin' on your internal micro SD card.
Copy the dump to your computer and open it with your preferred hex editor (I will use HxD).
The first URL we will patch is the ECommerce URL, or https://ecs.c.shop.nintendowifi.net/ecs/services/ECommerceSOAP
Use the Find -> Text string function (CTRL+F) to search for the URL.
This URL starts at 0x4E1BC and ends at 0x4E1F9 of our dump.
Remember that our dump started at 0x00100000. So now we add the addresses of our dump and the start of the URL to get 0x0014E1BC.
Go back to the debugger to confirm your address at this point.
Code:
> data(0x14E1BC, 0x3E, pid=0x25)
null
packet: cmd = 9, dataLen = 62
68 74 74 70 73 3A 2F 2F 65 63 73 2E 63 2E 73 68 6F 70 2E 6E 69 6E 74 65 6E 64 6F 77 69 66 69 2E 6E 65 74 2F 65 63 73 2F 73 65 72 76 69 63 65 73 2F 45 43 6F 6D 6D 65 72 63 65 53 4F 41 50
finishedWe can see that the data is identical to what we have selected in the dump.
Now you can overwrite the URL with your own ECommerce URL.
Code:
write(0x14E1BC, tuple(map(ord, "http://YOURECOMMERCEURL/\0")), pid=0x25)Note that your URL must be shorter than the existing url and end in a \0, which signifies the end of a string.
Repeat this process for the other instance of the ECommerce URL by using the Find function to find the next instance of it.
Repeat this process also for the NetUpdateSOAP URL, or https://nus.c.shop.nintendowifi.net/nus/services/NetUpdateSOAP
Thank you so much for the detailed instructions!
In fact I have experience playing around with Xbox 360 Development Kit, so I fully understand your idea.
Hope this can help other people with EUR 3DS consoles.
I'm another 9.2 upgrade success story thanks to [user]Oishikatta[/user] and [user]yifan_lu[/user]. If either of you find yourself in San Francisco, I owe you a beer! Thanks so much for making this happen for me and others in this thread.
I had an issue as the update was downloading. The system restarted twice with an error before the update finished downloading. So I had to reconnect via the debugger a couple times and rewrite Oishikatta's url to the 3DS's ram. What's nice is that the update continued where it left off downloading every time I reentered the update screen. So after three(!!!) attempts, it did finish successfully and I wound up on 9.2 instead of with a N3DS-shaped brick. Thanks guys!!
I had an issue as the update was downloading. The system restarted twice with an error before the update finished downloading. So I had to reconnect via the debugger a couple times and rewrite Oishikatta's url to the 3DS's ram. What's nice is that the update continued where it left off downloading every time I reentered the update screen. So after three(!!!) attempts, it did finish successfully and I wound up on 9.2 instead of with a N3DS-shaped brick. Thanks guys!!
When I do the data command to dump the memory addresses, it writes the file to the computer not to the internal SD card. I think you might just be mistaking the dumping of the process when you use the NTR menu.
Also couldn't the URL be the same size, as long as it's not any longer? Not saying the \0 isn't a great way to go, but it should work as long as it's the same length as the original.
Right, I did it differently myself than I wrote in the guide. It is much more convenient having the file dumped directly to the computer; forgot to say that though.
Yes, you could use the same length. For simplicity I said shorter.
By looking at the filename you had in HxD, it looked like you used the NTR function. I just wanted to make sure the steps were correct for others so they didn't think they were doing something wrong when they couldn't find the file.
As for the shorter URL, yeah it's certainly simpler. I figured the only issue that could come up is if someone had a longer URL than https://ecs.c.shop.nintendowifi.net/ecs/services/ECommerceSOAP. But really the chances of that is... uh not likely.
As for the shorter URL, yeah it's certainly simpler. I figured the only issue that could come up is if someone had a longer URL than https://ecs.c.shop.nintendowifi.net/ecs/services/ECommerceSOAP. But really the chances of that is... uh not likely.
yifan_lu could you help me with the CommonETicket response for JP 9.2 to US 9.2?
This is my request:
This is my request:
Code:
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:nus="urn:nus.wsapi.broadon.com">
<SOAP-ENV:Body>
<nus:GetSystemCommonETicket xsi:type="nus:GetSystemCommonETicketRequestType">
<nus:Version>1.0</nus:Version>
<nus:MessageId>xxx</nus:MessageId>
<nus:DeviceId>xxx</nus:DeviceId>
<nus:RegionId>JPN</nus:RegionId>
<nus:CountryCode>JP</nus:CountryCode>
<nus:Language>ja</nus:Language>
<nus:SerialNo>xxx</nus:SerialNo>
<nus:TitleId>0004001000021200</nus:TitleId><nus:TitleId>0004001000021500</nus:TitleId><nus:TitleId>0004001000021700</nus:TitleId><nus:TitleId>0004001000021800</nus:TitleId><nus:TitleId>0004001000021B00</nus:TitleId><nus:TitleId>0004001000021E00</nus:TitleId><nus:TitleId>0004001000021F00</nus:TitleId><nus:TitleId>0004001000024000</nus:TitleId><nus:TitleId>0004009B00011402</nus:TitleId><nus:TitleId>0004009B00011602</nus:TitleId><nus:TitleId>0004009B00011D02</nus:TitleId><nus:TitleId>0004009B00011E02</nus:TitleId><nus:TitleId>0004009B00015302</nus:TitleId><nus:TitleId>0004001000021000</nus:TitleId><nus:TitleId>0004001000021100</nus:TitleId><nus:TitleId>0004001000021400</nus:TitleId><nus:TitleId>0004001000021900</nus:TitleId><nus:TitleId>0004001000021A00</nus:TitleId><nus:TitleId>000400100002C000</nus:TitleId><nus:TitleId>0004001020021300</nus:TitleId><nus:TitleId>0004001020021D00</nus:TitleId><nus:TitleId>0004001020024100</nus:TitleId><nus:TitleId>000400102002CF00</nus:TitleId><nus:TitleId>000400102002D100</nus:TitleId><nus:TitleId>000400102002D300</nus:TitleId><nus:TitleId>000400102002D500</nus:TitleId><nus:TitleId>0004003000008B02</nus:TitleId><nus:TitleId>0004003000008F02</nus:TitleId><nus:TitleId>0004003000009002</nus:TitleId><nus:TitleId>0004003000009202</nus:TitleId><nus:TitleId>0004003000009302</nus:TitleId><nus:TitleId>0004003000009602</nus:TitleId>
</nus:GetSystemCommonETicket>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>changing region possible?
He already did release: https://gbatemp.net/threads/creating-a-north-american-non-xl-new-3ds.381775/page-8#post-5425577
My issue is that I don't have the client cert for getting the official NUS responses, so I can't make my own CommonETicket response.
Edit: Client cert was in the ram of the ssl process, that was kind of an obvious place for it...
*removed client cert
And the CommonETicket response for 9.2U:
-removed because partial
Edit2: After sending that response, I got another request for more CommonETickets...
Code:
<nus:TitleId>0004003000009702</nus:TitleId><nus:TitleId>000400300000BD02</nus:TitleId><nus:TitleId>000400300000C802</nus:TitleId><nus:TitleId>000400300000C902</nus:TitleId><nus:TitleId>000400300000CB02</nus:TitleId><nus:TitleId>000400300000CC02</nus:TitleId><nus:TitleId>000400300000CE02</nus:TitleId><nus:TitleId>0004003020009402</nus:TitleId><nus:TitleId>000400302000C803</nus:TitleId><nus:TitleId>0004009B00012302</nus:TitleId><nus:TitleId>0004009B00013302</nus:TitleId><nus:TitleId>000400DB00017302</nus:TitleId><nus:TitleId>000400DB20016302</nus:TitleId>Edit3: I have merged all of the required responses. http://pastebin.com/cVswFk4m
Offsets for 9.2J: 0x14E4F4, 0x14E1BC, 0x14E533
I have added the 9.2U files and etickets to my server.
Code:
connect('3ds ip', 8000)
write(0x14E4F4, tuple(map(ord, "http://us92.jp81to92update.tk/\0")), pid=0x25)
write(0x14E1BC, tuple(map(ord, "http://us92.jp81to92update.tk/\0")), pid=0x25)
write(0x14E533, tuple(map(ord, "http://us92.jp81to92update.tk/\0")), pid=0x25)Reminder that by not using your own server you send your console's serial, device id/token, etc... over the internet. I do not log them.
After running the update to 9.2U, my 3DS rebooted perfectly fine into 9.2J.
No trust issues
For the normal 8.1J -> 9.2J, it should be as simple as booting NTR, running the 3 commands to patch URLs, and updating: http://gbatemp.net/threads/guide-upgrading-8-1-0-0j-to-9-2-0-20j.384960/page-6#post-5420331
Several people have said they used my url successfully now, are you having issues with it?
What you see in your NTR debugger window should look somewhat like this:
Code:
> connect('192.168.1.116', 8000)
null
Server connected.
> write(0x...
null
finished
> write(0x...
null
finished
> write(0x...
null
finished
patching smdh
starting applet: 0004001000020000
expand pool addr: 0700d000, size: 00005000
FSUSER_OpenDirectory failed, ret=c8804478
Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
Server disconnected.As long as all 3 write commands show "finished", you should be good to enter system settings and update. (Be sure to patch then enter, do not exit and reenter.)
Also you should have a backup of your nand made by gateway's launcher just in case.
Are you saying that http://us92.jp81to92update.tk now hosts the US responses and I could patch the nim of my jp 9.2 n3ds to there and VOILA! they would be NA now? Because that would be really great (and would save a lot of time).
Also, considering we have to transfer the secureinfo, do you or does anyone else know what would happen if I gave a secureinfo from one ds to two n3ds? (My main concern being that while I'm not planning on using the old 3ds anymore, the new ones are both going to see some use and I'm worried of possible ban/internet complications).
So wait a minute, are people changing their Japan consoles into US ones now or is this something else? My end goal is to play the US Majora's Mask that I bought on my (now) 9.2J. Although I'm not sure if my cartridge requires a 9.4 update on top of not being able to load a language file or something
-
Xdqwerty
what are you looking at? -
realtimesave
-
Psionic Roshambo
-
-
@
SylverReZ:
@Psionic Roshambo, JonTron's back yet again until he disappears into the void for another 6 or so months.+1 -
-
-
-
-
-
-
-
-
-
-
-
-
@
Xdqwerty:
@realtimesave, hey there buddy chum pal friend buddy pal chum bud friend fella bruther amigo pal buddy friend chummy chum chum pal
-
@
Xdqwerty:
@realtimesave, hey there buddy chum pal friend buddy pal chum bud friend fella bruther amigo pal buddy friend chummy chum chum pal
-
-
-
-
-
-
-
-
-
