That is not the kind of bug I see everyday
1- calling convention db is loaded
2- function cc types is initialized by project file, that string is only
one copy across the whole database for memory efficiency.
3- The db is reloaded due to change in arch or what ever, Old strings
are freed and new one is created with totally new address. Most cases it
just reload the same database.
4- Addresses in function cc types are not updates, they are already
freed at reloading db step
Solution implemented at db reloading step:
1- create new temp db with all possible available calling conventions and
the adresses in memory of these calling conventions
2- once db is reloaded, grab adress of cc from function, match it with
the name in the new temp db, then replace it with the constant value
from the newly loaded db
- POPFD and POPFQ were not counted
- POPCNT is not a stack operation but counts the '1' bits in a word.
Not sure where POPCNT belongs with it was wrong here.
the diff corrects a logic error in `__WINDOWS__ && !__CYGWIN__` case, as
r_sandbox_open() will return `-1` on error.
and it makes a sandbox check before calling truncate(2) syscall.
As the comment says, we need to pretend to satisfy the caller. For some reason
I also restored the breakpoints here. I cannot for the life of me figure out
why since it should be ok with in all cases.
For swstep=false, the step will stop right away (regardless of any breakpoints)
and thus need to remove breakpoints anyway.
For swstep=true, a breakpoint is created on the next instruction and would stop
too and thus need to remove breakpoints anyway.
So yeah, don't do this. Thanks for the report skuater!
* Bad Trap on MIPS ADDI ESIL
added $$ to TRAP as per ES_TRAP_DS
* Fixed ADDI logic
Based on QEMU, overflow occurs when the operands have the same sign, but the sign of the result is different.
add anon nested struct help and fix tests
fix tests
minor changes
add support for unsigned and signed char, short, int and long long
add help
cleanup
minor fix
- Generation of zignatures were to specific to be useful. They were
generated by getting the first 128 bytes of the functions defined,
as is. Now, it generates more generic signatures by getting the
whole function bytes and masking out all the operands.
- New z. command, that performs zignature match by function. It
works for a given offset with @ addr, so with @@ fcn* it can be
run against all detected functions of the bin.
* Adding types documentation
* refactoring and optimizing types databases
All based on docs
* fixing r_core_types_init
Basically we needed to try all possible 7 combinatios of file name,
I am not sure if there is a way to do that automatically.
one extra thing, since this is init subroutine we should make sure
that the db is already empty, when reloading this function
(by changing env vars), it will be reloaded thus it needs a reset first.
* Fixes: 5540 (now i386 will not complain in case they're missing GETREGSET)
* Fixup: Owner set to Linux for NT_PRXFPREG
* Fixup: Now extra section hdr is being written with the right offset
* Fixup: Bug with multithread cfg fixed
* Add: Now r2 is able to generate coredumps on ARM platforms
Valgrinding to get exp. Testing with "r2 -Aqcq /bin/ls"
Before:
definitely lost: 22,735 bytes in 250 blocks
indirectly lost: 23,542 bytes in 605 blocks
possibly lost: 2,464 bytes in 7 blocks
still reachable: 3,876,216 bytes in 80,761 blocks
After:
definitely lost: 25,216 bytes in 58 blocks
indirectly lost: 24,830 bytes in 739 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 20,105 bytes in 34 blocks
The "goto beach" (named like that for consistency) change resulted in
freeing most of the "still reachable" stuff on quit, which also moved
stuff out of "possibly lost", so.. it looks like it's leaking more now.
Yay.
This was originally used to cause a seek to the next block prior to
reading such that successive calls to r_core_block_read() would progress
through memory one block at a time. This was broken, though, by commit
452669d941 ("more cleanup in r_core_block_read") when when it used
`next' to directly calculate the offset rather than via a seek.
Only one call site remains that attempts to read the next block instead
of the current, and this probably was not even observable due to the
"hacky fix" added in commit 3bfa61946e ("Cleaner pvj, fix tinype load,
and honor 'ao N's").
The current of semantics of `next' appear to be broken and there is very
little dependence on it. If the original behavior should be restored
anywhere, it would be much better to add a new function, or just do the
seek explicitly, rather than parameterizing r_core_block_read() on it.
Commit 57b199789d ("Reread block after undo seek. Fixes dbg.status
issue") reads the *next* block into the buffer rather than the current.
This breaks backwards seeking as can be seen in the following example:
$ r2 -N malloc://0x4000
[0x00000000]> b 64
[0x00000000]> wb 38
[0x00000000]> s 64
[0x00000040]> wb deadbeef
[0x00000040]> s-32
[0x00000020]> px
- offset - 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
0x00000020 dead beef dead beef dead beef dead beef ................
0x00000030 dead beef dead beef dead beef dead beef ................
0x00000040 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00000050 0000 0000 0000 0000 0000 0000 0000 0000 ................
[0x00000020]> s+16
[0x00000030]> px
- offset - 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
0x00000030 3838 3838 3838 3838 3838 3838 3838 3838 8888888888888888
0x00000040 dead beef dead beef dead beef dead beef ................
0x00000050 dead beef dead beef dead beef dead beef ................
0x00000060 dead beef dead beef dead beef dead beef ................
The first block to a string of ASCII '8' bytes and the second to
0xdeadbeef. We then seek backwards 32 bytes from our current 64 byte
offset but a dump at the resulting offset shows data from half way into
the second block (i.e., offset 0x60.) Dumping again after seeking 16
bytes forward shows the expected last bit of the first block. Clearly
the intent was to reread the current block, not the next block, after an
undo or backward seek.
NOTE: The above example will only work after applying the previous
commit as rereading the buffer when displaying the prompt hides this
bug.
Additionally, since the commit intended to reread the buffer only after
an undo seek, do not do this at all on a backward seek.
Commit 3bfa61946e ("Cleaner pvj, fix tinype load, and honor 'ao N's
help") added a hack to reread the current block when printing the
prompt. This has the drawback of causing scripts loaded via the `-i'
command line option to potentially behave differently than reading the
commands via stdin. Remove the hack and fix the bugs.
This is an empty file because I (DanTheColoradan) was unable to
obtain any ordinal information. I tried two versions:
- 9.0.30729.1
- 9.0.30729.6161
Both were downloaded from dll-files.com. I also tried a version
from MS Windows 10, but I don't know what version it was.
This change should close#5486.
