<Guest0>
dumped 2097152 bytes in 19.743622s (103.730 KiB/s)
<Guest0>
oh, ok i found it. it was under: /usr/share/openocd/scripts
<Guest0>
ok one more question :) does this article help us to dump the flash memory or firmware (software source codes) ?
<Guest0>
i can see the values in variables i defined, in flashdump.bin file; however I can not see the function names and passed parameters. how can i see the passed parameter value to my function?
<braunr>
it's only the binary result
<braunr>
unless it's an interpreted script, you cannot "dump source code"
<Guest0>
binary of what? of the flash memory?
<braunr>
of the compilation
Guest0 has quit [Quit: Client closed]
Guest0 has joined #openocd
<braunr>
mhm
<braunr>
Guest0: ah, welcome back
<Guest0>
umm, so it is a similar output of compiled source code? so is it an ASM dump?
<Guest0>
sorry for connection lost :)
<braunr>
yes but in raw binary form
<Xogium>
you cannot see source code of programs, since that doesn't get flashed... You can only see the binary
<braunr>
Xogium: oh hey :)
<braunr>
modern programs are built in a complex format with different areas
<Guest0>
aha, thank you! if it is the ASM dump, so how can I dump the flash memory or RAM memory?
<Xogium>
its not asm
<braunr>
one for the code, one for the data, one for debugging symbols, etc..
<braunr>
like ELF
<braunr>
but a raw binary program is the most simple form of machine code (not ASM actually) there can be
<braunr>
it's just the sequential data that a processor can process
<Xogium>
yep, 0's and 1's all over the place
<Guest0>
ahh okay, it is not ASM or source code; it is just a basic form of things to execute o.O
<braunr>
and not indication of what it actually is, you have to infer it all by yourself
<braunr>
machine code in raw sequential form, yes
<Guest0>
<3
<Guest0>
so, how can I read the flash memory or RAM memory? because I want to see the value I passed as a parameter to a function...
<Xogium>
ELFs can't get flashed directly though, right ? That's why there's the ELF file and the bin file
<braunr>
your question doesn't make sense
<braunr>
the dump in your article correctly describes how to read flash or ram
<braunr>
but that doesn't allow you to know the parameters passed to a function
<braunr>
not directly, and doing it from that is hard
<braunr>
if you want to debug a program in binary form, it's best if you have the complex form (on linux, ELF), and of course the source code
<braunr>
you could then set a break point on that function, and let the debugger show you the parameters
<braunr>
assuming optimizations still allow it
<Xogium>
I actually don't see how you could do this. Gdb, maybe ? Hmm. I only ever used openocd to try to debug a hung kernel on cortex-a and it turns out it wasn't even something gdb could have told me. Missing low power clock source support. Woops
<braunr>
gdb through openocd, yes
<braunr>
actually, when debugging, you want to disable stuff like wait-for-interrupts
<Guest0>
so, should i research "how to use gdb with openocd" to see the passed parameters?
<braunr>
Guest0: that's a start
<Xogium>
aw man that one was nasty. I spent like 10 hours bisecting a working .config with a non working .config
<braunr>
but the skill set to comfortably do it is larger
<braunr>
take your time
<Guest0>
umm, okay. i will research on it more, thank you so much!
<Xogium>
turns out that migrating to kernel 5.15 from 5.10, kconfig went a bit soft in the head and disabled this critical setting
<braunr>
learn by doing
<Guest0>
last question: is it an ELF file? the "flashdump.bin" file ?
<braunr>
no it's not
<Xogium>
nup
<braunr>
Xogium: what setting ?
<Xogium>
its made *from* the ELF though
<Guest0>
is there a specific name for this file? :D what did i get after dump_image command?
<Xogium>
braunr: support for low power source clock on stm32mp1
<braunr>
Guest0: there isn't, that's what i called raw binary form earlier
<braunr>
Xogium: i see
<braunr>
i only debugged the cm4 on stm32mp1
<Xogium>
kernel was going no further than, enabled earlycon0, I was like, what the actual freaking hell
<Xogium>
:D
<braunr>
Guest0: you literally got what's on the flash
<Xogium>
hmm, still haven't played with that one. I wonder what I could have it performing
<braunr>
the process to produce that stuff is usually : source code -> formatted executable (like ELF) -> raw binary form
<Guest0>
oh ok, so it is the full dump of the flash?
<braunr>
the first transformation is through a compiler, the second through a tool like objcopy
<braunr>
not necessary full
<braunr>
usually you request a range
<braunr>
the range can be the full range or a subset
<Xogium>
I want to make a clapper device. Y'know, use a sound sensor, clap your hands, start music. Clap again and it stops music. But that runs on the cortex-a, as a linux app. The music player, that is. Still, would be fun to do this, just for fun. Challenging myself
<braunr>
Xogium: the cm4 is only really there for real-time stuff
<Guest0>
my flash is 2mb and i entered 0x00000000 - 0x200000 as range
<braunr>
that's the full range then
<Xogium>
yeah I'm probably not needing that to use the sound sensor
<braunr>
probably not :)
<Guest0>
one more question:D sorry im really ignorant on this
<Xogium>
no worries, we all started somewhere
<Guest0>
i am using STM32CudeIDE to write my apps into flash. so, why can not I see all the source codes clearly?
<braunr>
Guest0: well if you write your apps, you have the source code somewhere, don't you ?
<Guest0>
i have in my computer, but i am trying to reverse it like a 3rd person
<braunr>
Guest0: then that's normal
<braunr>
20:11 < braunr> the process to produce that stuff is usually : source code -> formatted executable (like ELF) -> raw binary form
<braunr>
the source code isn't included in the formatted executable, and there is even more information loss at the last stage
<braunr>
it's not called reverse engineering for nothing
<Guest0>
hmm, as i understand: the flash never contains the full source codes and the processor runs the raw binary form in the flash? right?
<braunr>
yes
<Guest0>
yess! thank you sir
nerozero has quit [Ping timeout: 245 seconds]
<braunr>
have fun
<Guest0>
so, today i learned how to dump flash memory, so what about the RAM?
<braunr>
same stuff
<Guest0>
is this dump already includes the RAM content?
<braunr>
no, it's only the flash range
<braunr>
you need to learn about device memory mapping
<braunr>
the flash, the ram, the registers of the various devices are mapped in one memory space
<Guest0>
its okay, but i used this command to extract the flash: "halt; dump_image flashdump.bin 0x00000000 0x200000"
<Guest0>
is there another command for dumping the RAM content?
<braunr>
the same, at another memory range
<Xogium>
which is often SoC specific if I'm not dumb ^^
<braunr>
well, sometimes, depending on the device, the jtag and the cpu may not have the whole memory space
<braunr>
yes
<braunr>
well the cpu normally has full access, but the jtag may not
<Guest0>
hmm, if I change 0x00000000 and 0x200000 - will i get the RAM content?
<braunr>
don't guess
<braunr>
find out
<braunr>
get the manual for the microcontroller/SoC and find out
<Xogium>
gotta read SoC datasheet and reference
<braunr>
yes it's normally the datasheet
<braunr>
but for quite a few stm32 uc, it's directly in the manual
<Guest0>
a few days ago, i inspected a variable and it was storing at 0x20000334 address
<Guest0>
1) so, does it mean it stored in the RAM?
<braunr>
that sounds like ram
<braunr>
again you're guessing
<braunr>
go find the manual, it's publically and freely available
<Guest0>
2) how can i edit the command (range) to access the value in this address?
<braunr>
well you edit the command .. :)
<braunr>
the first address is the start of the range, and the second the end
<PaulFertser>
Normally code runs from directly from flash. Initial variable values are copied from flash to RAM on startup. const variables are stored in flash directly.
<PaulFertser>
Guest0: it's too short of a string, and probably it's a constant so not going into RAM ever.
<Guest0>
yes, because i can see the value of a char variable in the RAM
<PaulFertser>
Guest0: when linking your project you can ask the linker to generate a "map" file, you can see the exact offset of each variable in there.
<PaulFertser>
3 isn't even a string literal in your code, it's just a constant, and likely is encoded as immediate argument to some assembly instruction.
<braunr>
PaulFertser: he wants to reverse from the binary content, as someone who doesn't have access to the code
<Guest0>
yes, exactly
<PaulFertser>
braunr: then Guest0 obviously needs to start with disassembling the binary dumped from flash :)
<Guest0>
how could an hacker reveal that key (3) ?
<braunr>
Guest0: learn about assembly and calling conventions
<braunr>
PaulFertser: obviously :)
<braunr>
Guest0: he wouldn't learn all he needs to do it in an hour :p
<braunr>
it takes much more time
<PaulFertser>
Guest0: by disassembling, and e.g. in radare2 you have "aaa" command that can find and annotate functions for you. But it's not a magic decompiler to see the source code.
<PaulFertser>
Guest0: I suggest you start with some "crackme" tutorials. They're for x86 usually, but the idea is the same.
<braunr>
i don't know someone who doesn't have a strong grasp of machine code / assembly, calling conventions, C, etc.. can effectively use something like radare2
<Guest0>
ok, i will start with learning Assembly ^^
<braunr>
err, i don't think*
<Guest0>
my last question: if I would pass a long string like "hahacrackme" as a key, then could i see it in the memory dump?
<PaulFertser>
braunr: absolutely impossible, especially with radare2 :)
<PaulFertser>
Guest0: not likely in memory dump but likely in flash dump.
<Guest0>
hmm
<braunr>
the compiler would generate a call to the function, passing the address of the string as an argument
<PaulFertser>
BTW, radare2 was forked recently, and probably the new tool is a bit more friendly.
<PaulFertser>
Rizin is the name of the fork.
<Guest0>
ok, i am so thankful for your helps, really appreciated ^^
<PaulFertser>
The team also offers Cutter as the GUI to it.
<Guest0>
have a good day <3
<PaulFertser>
Guest0: you too, have fun.
<PaulFertser>
Guest0: "crackme" is the keyword
<Guest0>
i will exactly take a look at it, buummmm!! :)
Guest0 has quit [Quit: Client closed]
_whitelogger has joined #openocd
kraiskil_ has joined #openocd
kraiskil_ has quit [Ping timeout: 252 seconds]
wingsorc__ has joined #openocd
sbach has quit [Read error: Connection reset by peer]
sbach has joined #openocd
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #openocd
akaWolf has quit [Ping timeout: 268 seconds]
akaWolf has joined #openocd
Steffanx has quit [Read error: Connection reset by peer]
Steffanx has joined #openocd
Bugies has quit [Ping timeout: 252 seconds]
Xogium has quit [Quit: Leaving.]
Xogium has joined #openocd
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #openocd
crabbedhaloablut has quit [Remote host closed the connection]