Open Cydget opened 8 years ago
"and it gives me no errors" Are you sure?
Due to hardly any space available, the max-URL-length is rather small(last time I tried anyway). Another thing... You're missing "http://" there.
It did not give me any errors while compiling it. But when running it with aireplay it does. I tried using tinyurl to give me a smaller url(http://tinyurl.com/pskllxm), and that works when compiling and using aireplay, but on the 3ds it freezes with a wierd bottom screen. Just to make sure, the urlneeds to be point to the otherapp payload not the ropbin one right?
You have to host the otherapp payload yourself, no HTTP redirection can be used.
Thanks, for the info. Im going to look into setting up apache now. Also, do you know the exact size of how small the url has to be?
Don't remember, but a build error is supposed to occur when it's too long.
Im probably just going to host it as http://192.168.0.8/a.bin Hopefully thats not too long.
So, it seams to launch the payload but instead of going to homebrew launcher it says debug *hax 2.5 beta 2015-10-31 19:58:43 hello 3dc452e0 got APT:A lock handle ? 00000000, 00028004,00030005
and the bottom screen is stuck at blue
How many times did you try?
6 or so. Once it go stuck a bit further it got stuck again and gave a bit of a different error *hax 2.5 beta 2015-10-31 19:58:43 hello 38c452e0 got APT:A lock handle ? 00000000, 00028004,00030005 got handle : fs:USER 00190006 got handle : ns:s 001a0007 got handle : ir:rst 001b0008 got handle : am:sys 001c009 got handle :ptm:sysm 001d000a
and the bottom screen is still stuck at blue
The payload is hosted at http://192.168.111.123/a.bin so I dont think it is too long
Not sure why it would hang at that point(gsplcd).
I have been testing this using the game 1.1.2 so far to save on demo uses, but I just tried this using the demo twice. On the demo it doesnt get past the line 38c452e0 in the above error.
I have also tested Cydget's build but then with the payload referencing a N10.2.0-28E and pcap for eurdemo and I can say I get the same debug screen:
(bottom screen is all blue)
It works fine with SD loading, so it's probably just the HTTP download code that doesn't work correctly(if you all setup the latter correctly of course). I don't remember ever testing *hax payload with HTTP loading in the first place.
Sad to say, this issue links back directly to the issue in which the conclusion was that the demk has no SD access... So SD loading is not an option here.
Do you think this will have a quick fix in a few days, or do you have to completely redesign the payloadurl argument?
No idea, didn't get around to debugging it yet.
Not sure what's going on, some sort of weird cache / timing issue perhaps. With a bkpt right before the final blx: when I dumped the payload-buffer in memory, it matched the payload on my server exactly except that the first 0x1000-bytes were invalid. However, the data actually in .text was completely correct. And as expected, removing the bkpt and continuing execution worked fine.
And of course, without any breakpoint it crashes as described by the above comments.
EDIT: NVM. "first 0x1000-bytes were invalid" That's where the paramblk is at this point, so that's normal.
Probably cache related somehow, but I don't really understand why that would only happen with HTTP loading.
So it works if you add a break point in the middle of it? How could I go about doing that?
That's just with my debugging stuff, no idea how this could be fixed if at all.
So, I just got it to work twice in a row a minute ago. What I did was compile the pcap with make clean && make "PAYLOADURL=http://192.168.111.6/g.bin" "BEACON_BYTEID=0x1" and used smash run instead of group smash. I also used smash version 1.0.0. Im going to try a few more times, to confirm that it works. Sometimes weird problems require simple solutions. Update: Works consistly on smash vversion 1.0.0. Also, just tried with smash version 1.1.2 and it does not work. (Maybe it wasnt setting it to smash run group that made it work)
"I also used smash version 1.0.0. " <- That could be why it worked.
It might be a combination, because Im now testing the 1.0.0 version using group smash 0x0, and both times I tried It freezes top sceen is black bottom is gray lines that are almost white. I can hear the homemenu music in the background, and If i press A it goes straight back to homemenu and smash is not open. Update: definatly a combination. It will not work without using smash run group on 1.0.0
The main reason why Im trying to get payloadurl to work is for the demo, but I just realized that the demo dosent have smash run enabled/included. Do you think there is another way to replicate this on the demo? On a unrelated note, I really wish that it could load from wii controller mode. That way people might be able to get the controller app and have an entry point for $2. I know that that probably is not possible. just an idea...
"get the controller app" Another vuln would be needed.
Don't know if the *hax payload would ever be usable with the demo.
So, I have compiled the pcaps with the command make clean && make "PAYLOADURL=smealum.github.io/ninjhax2/JL1Xf2KFVm/otherapp/N3DS_U_21504_usa_9221.bin" and it gives me no errors. But when I run the pcap with sudo ./aireplay-ng --interactive -r "./pcap_out/smashbros_gameusav112_beaconhax.pcap" -h 59:ee:3f:2a:37:e0 -x 10 wlan1
It says
The interface MAC (00:21:27:D7:73:F4) doesn't match the specified MAC (-h). ifconfig wlan1 hw ether 59:EE:3F:2A:37:E0 End of file.
I have tried compiling the normal pcap files with make clean && make "PAYLOADPATH=/smashpayload.bin" and it works fine.
Another thing to note is that when compiling with make clean && make "PAYLOADURL=smealum.github.io/ninjhax2/JL1Xf2KFVm/otherapp/N3DS_U_21504_usa_9221.bin" It says Host MAC address: 59:ee:3f:2a:37:e0 so Im not sure if the mac address needs to be changed when running aireplay