Just notice that in emulation, the program frequently does R/W to SYSCFG before the decryption, and 0x40004014 is SYSCFG_DBGFORCE. I'm not familiar with RP2040, could anyone tell me if is this an anti-debugger or sort of thing? just a guess
Code:
IO_MEM[SYSCFG] write：pc:200200CA addr:40006014 size:4 value:4
IO_MEM[SYSCFG] write：pc:20020132 addr:40006014 size:4 value:2
IO_MEM[SYSCFG] write：pc:200200DE addr:40007014 size:4 value:4
IO_MEM[SYSCFG] read：pc:20020148 addr:40004014 size:4
....
IO_MEM[SYSCFG] write：pc:200200CA addr:40006014 size:4 value:40
IO_MEM[SYSCFG] write：pc:20020138 addr:40007014 size:4 value:20
IO_MEM[SYSCFG] write：pc:200200DE addr:40007014 size:4 value:40
IO_MEM[SYSCFG] read：pc:20020148 addr:40004014 size:4
It looks to be the opposite, some sort of software debug port for the processor :
https://raspberrypi.github.io/pico-sdk-doxygen/syscfg_8h_source.html
Since the pico has 2 cores, maybe the debug/watchdog monitor is running on the other core?
@thesjaakspoiler Thx for the info! But I still suspect it's an anti-debugger because the program only read the value of SYSCFG_DBGFORCE. So I guess it is detection or something? Besides, it is weird that the address 0x40006014 and 0x40007014 are not documented in RP2040 datasheet (maybe i miss sth?).
SYSCFG_DBGFORCE_OFFSET is an offset so I think you can set it to whatever you want it to.
I also don't know the details but the following forum post talks about running a debugger over USB on 1 core that debugs another core. If you use an external debugger (like another pi) then you physically connect the 2 boards but with the pico you can also 'wire' 1 core to the other and have the processor deal with it like an external debugger is used.
Here they set it to 0x40004014 :
https://forums.raspberrypi.com/viewtopic.php?t=313226
My guess is that the author of the original used this method to debug the pico without the need for any additional hardware Why use an external debugger if you have 1 core to spare and the USB connection available?
That you see code for core 0 and 1 might be because the core might be something generic that can run on both cores.
I also don't know the details but the following forum post talks about running a debugger over USB on 1 core that debugs another core. If you use an external debugger (like another pi) then you physically connect the 2 boards but with the pico you can also 'wire' 1 core to the other and have the processor deal with it like an external debugger is used.
Here they set it to 0x40004014 :
https://forums.raspberrypi.com/viewtopic.php?t=313226
My guess is that the author of the original used this method to debug the pico without the need for any additional hardware Why use an external debugger if you have 1 core to spare and the USB connection available?
That you see code for core 0 and 1 might be because the core might be something generic that can run on both cores.
Yeah I've used that to debug zero
https://github.com/majbthrd/pico-debug
But you need to build official OpenOCD to make it work or you will have an error
Those addresses are documented, every peripheral MMIO page gets three extra pages from the base address for atomic IO; they're all writes to the DBGFORCE register. Specifically, on each core, it writes a data bit in SWDI by triggering a falling edge on SWCLK. The sequence is something like
(atomic) OR swclk
(atomic) OR swdi
(atomic) AND ~swclk i.e. set swclk to 0
<and then it reads the entire register, presumably masking all bits except swdo. maybe they check that swdo = swdi?>
Assuming they're attached to the core (otherwise it doesn't do anything(?)) it's probably just trying to interfere with someone attaching something to the SWD pins on the RP2040.
edit, you can read section 2.1 of the rp2040 datasheet if you need to know atomic write mappings
https://forums.raspberrypi.com/viewtopic.php?t=324901 here it talks about DBGFORCE , it probably prevents debugging
Not any more than just strapping two together would be, or using any other hardware debugger.
Still pursuing unique id. Managed to debug the actual get_unique_id call in the main function and it seems if ID is altered (at least the way I did it) it adds additional data to it:
vs unaltered
So it adds additional:
Tried with different picos to confirm and different injected IDs its always the same.
Will test with pico example and that other program that which accepted injected id to see are there the same results
Edit: Tested and nop there are no anomalies like this in pico-example or that other program. Everything fine. Also double check that program with the injection and it works.
The only thing is that program if ID is not correct then it adds some data to it, but if its correct (injection) then it shows normal ID string without any additional data (so its reversed than this above)
Pico example shows normal ID strings no matter is it injected or not
(that other program I'm referring is this https://forums.raspberrypi.com/viewtopic.php?t=336409 and it accepts injected ID)
Code:
INJECTED ID
0x10000718 in ?? ()
(gdb) x/s $r0
0x20041fa0: "\346a\034\267\037\062h)\bG\003\265P\002"
Code:
ORIGINAL ID
0x10000718 in ?? ()
(gdb) x/s $r0
0x20041fa0: "\346aA\004\003y\247\071"
Code:
\bG\003\265P\002Will test with pico example and that other program that which accepted injected id to see are there the same results
Edit: Tested and nop there are no anomalies like this in pico-example or that other program. Everything fine. Also double check that program with the injection and it works.
The only thing is that program if ID is not correct then it adds some data to it, but if its correct (injection) then it shows normal ID string without any additional data (so its reversed than this above)
Pico example shows normal ID strings no matter is it injected or not
(that other program I'm referring is this https://forums.raspberrypi.com/viewtopic.php?t=336409 and it accepts injected ID)
Last edited by renoob,
Official firmware updated to FW 16.0.0!
Source: https://switchbrew.org/wiki/16.0.0
Code:
System Titles
New sysmodule ngc was added (0100000000000050).
All sysmodules were updated (excluding stubbed-lbl).
Most SystemData were updated, except for: Chinese and Korean dictionaries, Dictionary, AvatarImage, UrlBlackList, ControllerIcon, ApplicationBlackList, FunctionBlackList.
Most applets were updated, except for: cabinet, controller, netConnect, swkbd, miiEdit, starter, maintenance.
NPDM changes (besides usual version-bump):
boot2.ProdBoot now has access to ncm.
friends no longer has access to csrng.
nifm now has htc:nd access.
nifm, ldn, ns: pl:u access was replaced with pl:s.
ns now has access to ns:am2 and ns:su (for GetService).
nim no longer has access to spl:.
vi now has pl:u access.
glue now has hosted-service pl:u access (moved from sdb) and access to svcCreateSharedMemory.
fatal had access for the following removed: nvdrv:s, pl:u, vi:s.
sdb had access for pl:u (hosted-service) and svcCreateSharedMemory removed.
qlaunch, playerSelect, photoViewer, myPage: access to ngc:u was added.
The SafeMode bootpkgs KIP for PCV had "Default CPU Core" changed from 3 to 63.
RomFs changes:
CertStore: "/ssl_TrustedCerts.bdf" updated and "/ssl_TrustedCerts.Ounce.bdf" added.
ErrorMessage: updated
BrowserDll:
"/browser/MediaControlsInline.css" updated
"/browser/MediaControlsInline.js" updated
"/browser/UserCssCore0.dat" added
"/browser/UserCss.dat" updated
"/buildinfo/buildinfo.dat" updated
"/gfxShader/" added, which contains "BrowserOffscreenDrawer.bnsh".
"/lyt/Browse/Page.arc" updated
"/nro/" The various NROs located under here were updated.
Help: "/legallines.htdocs/img/HDMI.png" and "/legallines.htdocs/index.html" were updated.
NgWord: updated.
LocalNews: "/image/LnSupIntro/main_Other.jpg", "/message/EUnl/localNews.msbt.szs", "/message/revision.txt" updated.
Eula: "/KRko/Eula.msbt.szs" and "/revision.txt" updated.
FirmwareDebugSettings: updated
NgWord2: updated. Added "/ac_similar_form_nx" and "/table_similar_form_nx".
NgWordT: "/mars_dirty_words_db" updated
applets: various UI/message/gfx data updated.
web-applets: "/buildinfo/buildinfo.dat" and "/.nrr/modules.nrr" updated.Source: https://switchbrew.org/wiki/16.0.0
Thx for the info! that really helps me to understand the program since it uses the atomic IO a lot. Since the program looks like uses several MMIO addresses to pass data in the decryption, I guess this is the reason that my emulation got wrong. Will try to implement this later.
EDIT: sadly the decrypted value has not changed
Post automatically merged:
Just rechecked this part code, if I'm not wrong, it doesn't matter whether there is extra data following the ID, the rest part of the function 0x1000070C just reads the first 8 bytes from the ID stored in stack and expands it to 265 bytes. The extra data shown in the gdb might be because you use "/s" mode, and gdb tries to read until a terminating zero.
Last edited by KAAAsS,
Yeah first 8 bytes are correct (the ID), but its kinda odd that the additional data appears only when id is injected. Reading full 16 bytes as hex gives first 8 as ID and next 8 as 00 when there is no injection, but after injection last 8 are not 00 anymore
Since 0x20041fa0 is located in stack and didn't get cleared before get_unique_id, I guess those data were written by other functions. The difference between injected and original firmware might be because the injected firmware didn't run the flash_get_unique_id function, so the stack contents become different.
Yes, but that’s not what this thread is about.
Similar threads
- No one is chatting at the moment.
-
-
-
-
-
@
Psionic Roshambo:
@BakerMan, yeah that's about the only reason I would vote for Trump over Biden.+1 -
-
-
@
Veho:
I don't give a fuck about what happens to America but I would like it if your shit didn't spill out on the rest of the world, thank you.+3 -
-
@
AncientBoi:
I give a fuck about what happens to America but I would like it if our shit didn't spill out on the rest of the world, thank you.+2 -
-
@
Psionic Roshambo:
@Veho, didn't need any news. Just going to the store and buying groceries is a constant reminder.
-
-
-
@
Veho:
Reminded that every single price gouging law was blocked by republicans because "muh gubmint overreach"?
-
-
@
Psionic Roshambo:
The problem with X party blocked X bill that would have prevented X is that yes the bill probably would have worked great, buuuttt they put XYZDCBG in said bill as an attempt to sneak things in that tend to be completely unrelated to the original bills intent. It sucks because if they would just do a single thing they could probably get something done...
-
@
Psionic Roshambo:
But congressman X needs to have government funding for his cousins unicycle business
-
-
-
-
-
-
-
Rotflmao