Python for Reverse Engineering 1: ELF Binaries
icyphox.sh
icyphox.sh
It’s because you passed a constant string to printf, so the compiler decided it was not worth making the call and used puts instead.
> Also many python tutorials and books fails to mentioned how to manipulate binary data
DBFReader.py [1], which is part of my xtopdf toolkit [2] is a program that uses struct.unpack() multiple times to decode the fields in a DBF (XBASE) file.
[1] https://bitbucket.org/vasudevram/xtopdf/src/default/DBFReade...
[2] http://slides.com/vasudevram/xtopdf
I had first written a Pascal program to read and dump DBF file data after reverse-engineering the DBF format, based on some sketchy info I had access to, years ago. Later wrote the same program in C, and later still in Python, i.e. DBFReader.py .
And so long as I'm asking for ponies, it would also be nice if they handled complex numbers gracefully.
Edit: Spelling
Windows, macOS and Linux are all supported.
Also, besides security aspect (eg intrusion/virus detection), I was looking at these frameworks as a 'higher-level than assembler, and less hardware architecture dependent than LLVM IR) -- is there an angle where reverse engineering tools, have a separate live an better-than-assembler toolchain for low level programming?
And your second question, I'm not sure I understand what you're attempting to convey.
[1] bonus point: for what kind of alignment? (The minimum is quite well specified, for C standards)
"The address of a block returned by malloc or realloc in GNU systems is always a multiple of eight (or sixteen on 64-bit systems)."
I was about to say, "what if they're on a 32-bit system and so were only allocated one 8-byte block?" but then realized that since they'd requested 9 bytes, they'd be given two 8-byte blocks, or one 16-byte block on a 64-bit system. Is that right?
It tells you where something can't be, and because virtual memory is allocated in whole pages the "padding" so to speak will always be accessible.
There's also the obvious truism that if you can access something in a cache line, all addresses in the cache line are safe to access. (Vectorized algorithms frequently implicitly rely on this for short reads, IOW there is no way reading a 128 or 256 bit vector can fault if just reading the first lane would not fault).
This is extremely processor-dependent and you should not be writing C if you’re relying on this.
No, it's not.
> you should not be writing C if you’re relying on this.
Luckily you are in no position to tell anyone what they should or shouldn't do.
Or you enable more strict build settings and BAM! You have to go back and deal with all the places your code allows you to write off the end of a buffer because you just didn't give a damn before.
You can see some similar code I wrote in Rust here: https://github.com/monocasa/exeutils
But yeah, this stuff is good content but doesn't have much reach.
https://damng.github.io/hackernews-rss-with-inlined-content/...
Content will be made readable and inlined into the feed.
Anyway VC funding doesn't necessarily equate to being interesting.
There is a pattern where highly specialized technical posts don't get as many comments, relative to votes. Possibly reverse engineering and other security-related specialties fall into this. One can see the same thing in e.g. articles about type theory: people are interested, but don't necessarily feel qualified to add to the discussion. That's probably good if it prevents the dumb sorts of comment from getting posted, but maybe the threads would be more valuable if more users would ask questions. Then the users who know could explain, and more learning would take place.