Sad news...
Bought on the trading platform, similar to amazon.
Bought on the trading platform, similar to amazon.
Did you just analyse the firmware on a portable calculator?
Post automatically merged:
Honey, you should know better. People are just trolling. Perhaps there is some wishful thinking mixed into it.
However I say we remain positive and optimistic. Great things do happen when people are optimistic.
Much love.
He got pissed people demanding and not just wait. But moan and whine they dont get their cheap solution instantly
Did you just analyse the firmware on a portable calculator?
not all of us can be 1337 and do this ish in their head.
You have to focus harder my young Padawan. The force is strong in you TMnot all of us can be 1337 and do this ish in their head.
I did this dump of firmware. Unfortunately, if you write the dump in rp2040 zero, there will be similar behavior to the Chinese board, but the glitch doesn't work
finally one of my pico RP2040 arrives, that little bugger IS SMALL, is even smaller than the gemma I brought for my wife's console!!
well this night will start to playing with this micro.
well this night will start to playing with this micro.
How thin is the seeed compared to a hwfly?
Besides the buttons an usb-c port the metal shield will probably also need to come off for it to fit in a oled switch.
Besides the buttons an usb-c port the metal shield will probably also need to come off for it to fit in a oled switch.
Last edited by FruithatMods,
was upon a time the ghosip of a way to mod a switch using a raspberry pico so you don't need to pay 150+ for the chip only 4$ but seems never works really.
https://gbatemp.net/threads/pikofly-a-probably-fake-hwfly-modchips-or-not.622701/
https://gbatemp.net/threads/scene-d...ntendo-switch-involves-a-raspberry-pi.623082/
Post automatically merged:
yeah, the USB port is thick
without the USB port it's the thick exactly 3mm high
the board and port are 4.6 mm thick
so its for sure you need to remove the USB port.
Last edited by impeeza,
I am analyzing the dump. (edit: to clarify, the firmware.bin from firmware.rar)
I think it's either obfuscated or unfinished, because the firmware is dumb.
There is BKPT everywhere (including the main() function), and the HardFault handler is also a BKPT, meaning that the CPU will just instantly die after a clock init.
There has to be some other magic I didn't find yet. I'll keep updated once I figure out the correct way to load this dump in such a way as to make IDA happy (I don't understand how to use Ghidra even after reading the documentation, so I'm limited by the tools I have).
Update 1: someone took the effort to actually strip the binary of *any* useful data, so it's probably not fake, in the sense that the code definitely should do something considering its size, but it's definitely not just a lazy fake payload.
I'm recovering as much symbol data as possible, and keep editing this post on my progress, and post a reply instead if a big discovery gets made.
Update 2: the payload size is 85184 bytes, but RAM usage actually extends to 154024 bytes (minus 192 bytes for PicoSDK stuff). Some code seems to be in RAM, (4576 bytes to be exact). Some SDK code also seems to be present in RAM, which is quite odd. I think the payload is so small because they have probably modified the linker file which comes with the SDK, but also probably just copypasted some SDK functions and made them run from RAM instead.
This makes sense, they are probably using a modified version of copy-to-RAM -style payload with some modifications.
Update 3: they are using a very different version of the PicoSDK, so I'm having minor difficulties.
BUT!
I found the main() function! Time to reverse-engineer
Update 4:
Also, the chip is overvolted to 1.30V, and it's overclocked to 333MHz, which is rather high. No wonder people are reporting that it doesn't work... I'm having stability issues at 250MHz and 1.10V with my ntrboot cart emulator. Technically the chip should not be damaged, but this is *really* pushing it into the danger zone >.<
Update 5: There is some really suspicious code encryption and virtualization going on. I'm tired for now, I'll probably start a new reply if I do get more progress.
I think it's either obfuscated or unfinished, because the firmware is dumb.
There is BKPT everywhere (including the main() function), and the HardFault handler is also a BKPT, meaning that the CPU will just instantly die after a clock init.
There has to be some other magic I didn't find yet. I'll keep updated once I figure out the correct way to load this dump in such a way as to make IDA happy (I don't understand how to use Ghidra even after reading the documentation, so I'm limited by the tools I have).
Update 1: someone took the effort to actually strip the binary of *any* useful data, so it's probably not fake, in the sense that the code definitely should do something considering its size, but it's definitely not just a lazy fake payload.
I'm recovering as much symbol data as possible, and keep editing this post on my progress, and post a reply instead if a big discovery gets made.
Update 2: the payload size is 85184 bytes, but RAM usage actually extends to 154024 bytes (minus 192 bytes for PicoSDK stuff). Some code seems to be in RAM, (4576 bytes to be exact). Some SDK code also seems to be present in RAM, which is quite odd. I think the payload is so small because they have probably modified the linker file which comes with the SDK, but also probably just copypasted some SDK functions and made them run from RAM instead.
This makes sense, they are probably using a modified version of copy-to-RAM -style payload with some modifications.
Update 3: they are using a very different version of the PicoSDK, so I'm having minor difficulties.
BUT!
I found the main() function! Time to reverse-engineer
Update 4:
Code:
lbl_0:
011 00010 001 00001 - OUT X, 1 [2]
000 10001 001 00011 - JMP !X lbl_3 side 00 [1]
000 10100 000 00000 - JMP lbl_0 side 01
lbl_3:
101 00100 010 00010 - MOV Y, Y [8] # this one doesn't make senseUpdate 5: There is some really suspicious code encryption and virtualization going on. I'm tired for now, I'll probably start a new reply if I do get more progress.
Last edited by Sono,
i got the seed studio one also to play around with.
Final verdict on firmware.rar: I think it might be legit, but it's encrypted and virtualized, so they really don't want you to see into their secrets.
I don't think it's worth it to try and reverse-engineer it any further, considering all the problems surrounding this device.
I think the best idea would be to take the currently existing open-source solution, analyze it, and try recreating that instead of trying to recycle this leaked garbage.
I don't think it's worth it to try and reverse-engineer it any further, considering all the problems surrounding this device.
I think the best idea would be to take the currently existing open-source solution, analyze it, and try recreating that instead of trying to recycle this leaked garbage.
If you know micropython well, you can transfer the bootloader and get a glitch. I tried to disassemble the firmware in IDA and did not find anything good. Perhaps the problem is that picotools did not correctly read the firmware.
MicroPython is too slow for these kinds of tasks. I know, because I tried.
The firmware *is* read correctly, because everything makes sense, I recognize the presence of PicoSDK, I recognize what compile flags they used, and I recognize that they have intentionally encrypted part of the code, but also the exception handlers as well.
There is no way that the dump is damaged.
Maybe need Pico unique id?
https://stackoverflow.com/questions/72594333/arduino-rp2040-pico-unique-id
Similar threads
-
BakerMan
I rather enjoy a life of taking it easy. I haven't reached that life yet though. -
Psionic Roshambo
-
-
-
-
@
The Real Jdbye:
@SylverReZ if you could find a v5 DS ML you would have the best of both worlds since the v5 units had the same backlight brightness levels as the DS Lite unlockable with flashme -
-
-
@
BigOnYa:
A woman with no arms and no legs was sitting on a beach. A man comes along and the woman says, "I've never been hugged before." So the man feels bad and hugs her. She says "Well i've also never been kissed before." So he gives her a kiss on the cheek. She says "Well I've also never been fucked before." So the man picks her up, and throws her in the ocean and says "Now you're fucked."+2 -
-
-
@
BakerMan:
anyways, we need to re-normalize physical media+1
if i didn't want my games to be permanent, then i'd rent them -
@
BigOnYa:
Agreed, that why I try to buy all my games on disc, Xbox anyways. Switch games (which I pirate tbh) don't matter much, I stay offline 24/7 anyways.+1
-
-
@
cearp:
@BakerMan - you can still "own" digital media, arguably easier and better than physical since you can make copies and backups, as much as you like.+1
The issue is DRM -
@
cearp:
You can buy drm free games / music / ebooks, and if you keep backups of your data (like documents and family photos etc), then you shouldn't lose the game. but with a disk, your toddler could put it in the toaster and there goes your $60
-
-
@
rqkaiju2:
i like physical media because it actually feels like you own it. thats why i plan on burning music to cds -
-
-
@
SylverReZ:
@rqkaiju2, Physical media is a great source for archiving your data, none of that cloud storage shiz.+1 -
-
-
-
@
BakerMan:
guys, should i change my pfp to one of these or keep it the same?
(i guess i could change it to one of my other pfps too, but i just want to see what you guys think first) -
-
. Saves on time, soap, water and money having to wash them.