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
The snack that smiles back, Ballsack! -
Xdqwerty
what are you looking at? -
Psionic Roshambo
-
-
-
-
-
-
-
-
-
-
-
-
-
@
Xdqwerty:
Although tomorrow is Labor Day which means I won't go to class which means I'll sleep well.
-
-
-
-
-
-
-
-
-
-
-
-
