wazari972

indeed, I could reproduce it, just force push `master` into a PR, github UI will close the PR, marked it as merged, delete the source branch ... but of course nothing happens in the git repo :/

> To load the rootkit into kernel space, it is necessary to approximately match the kernel version used for compiling; it does not have to be strictly the same.

>> vermagic=2.6.32-696.23.1.el6.x86_64 SMP mod_unload modversions

do you know why they say "approximately match"? I thought it had to match exactly so that the kernel accepts to load the module

Do you have any information about what happened?

(context: my son is DT1) We learn (in France) that hypoglycemia can lead to unconsciousness, but cannot be fatal as the liver will eventually take over and release glucose to the organism, as it always does for healthy persons. Glucagen injection is the way to get this release to happen fast, but it can be delayed if necessary.

exactly,

> Therefore, we can see Git ignores .gitignore because its in .gitignore, which means it didn’t ignore .gitignore for instructions.

> Is any of this informative, surprising, or useful? … Absolutely.

it's interesting to notice, but nothing surprising. git isn't supposed to ignore it for instructions

Native French speaker here,

same, I woulnd't pronounce "debt" the same way I would pronounce "dette" in French, and likewise for "doubt", which would turn in French "doute" ...

> But starting from that, can we implement what seemed to be the initial goal stated in the government's document ?

why not simply having 2 QR codes, one full, one light ... ?

what about "git cherry-pick <commit>"?

with this command you don't import a snapshot, but only the diff between <commit~>..<commit>, so the model parent+diff makes sense to me

I'm personally a big fan of vanilla GDB, at least for plain C debugging. Disclaimer: I spent >5years on a PhD work searching how to extend GDB for parallel and embedded programming.

    I can't easily see the surrounding code

I have Emacs on the side window, so I use GDB to see the immediately surrounding code, and Emacs to see the rest of the function. I do exactly the same for Python debbuging with PDB

    I have to manually request information rather than just glancing at the display

I just print the variables I want to see, there are not so many of them I'm actually interested in while debugging

    I have to remember syntax rather than just clicking on things
    ...and in this case, it took me a few tries to correctly deref this pointer to an fixed-size array

those are the tradeoff between flexibility and ease. You can access any memory locations, and cast it in many different ways, examine the assembly to precisely understand the next steps, examine the bits to precisely understand the storage (only endianness issues remained tricky to follow)

Author here.

As I mentioned above, I will rewrite this sentence to include dedicated special instructions. It was a wording mistake not to mention it!

Author here.

I will rewrite this sentence, "invalid instruction" is too limited. It should be something like "an instruction that traps, and which isn't already used for another purpose". Syscalls trap but they are already used; and INT3/CC are valid instructions.

Last commit on master: Dec 30, 2013. Maybe a [2013] tag could be added in the title!

I'm not sure to agree: if/as *nix systems do not use the extension to know the filetype, then `file`-like heuristics is the only other way to know the file nature, or do I miss someting?

very related blog post: f-string debugging in Python 3.8 [0]

which says that Python 3.8 will allow this kind of output:

    >> print(f"{name = }")
    name = 'karthikeyan'
    >>> print(f"{name.upper() = }")
    name.upper() = 'KARTHIKEYAN'

0: https://tirkarthi.github.io/programming/2019/05/08/f-string-...

if ever you already know LaTeX, you can use the simple programming constructs (if/then/else) to generate different CVs by switching flags

actually, in Linux, I used file links (multiple filename pointing to the same file content) to active different booleanflags, eg cv-paper.tex, cv-anonymous.tex, ...

very nice timeline, I'm curious to see how the sources look like! That kind of page could be easily templated, with something like a yaml file describing the content, and what ever being to generate the static website!

  8 years ago:
    what: Our first date
    where: Auckland, NZ
    photos:
      Camping trip: ...
      Roadtrip: ...

nice and easy ! I remember that the piping functionality was discussed in GDB mailing list long ago, but I guess it never got accepted!

it would have allowed writing

    (gdb) disas | grep mov

instead of

    (gdb) shell-pipe disas | grep mov

> It would be good not have any of that damned Python monkey business involved in this.

please, GDB internals are open source, you can do all of that in plain C :D That's what I did initially, to give GDB the ability to distinguish user-level threads (see libthread_db).

Having a high-level language / interface to GDB is a great again of time !

this is not particularly hard to do with the Python interface: you define structures that are known by the process and the Python module + global variables, then you set an internal (silent) breakpoint on a given 'event' function. In the program you fill the structure with some queries, and in the Python breakpoint callback, you process it as you need. This is the way multi-thread debugging work (used to at least), shared library detection as well...

Nice name ;-) For those not speaking familiar french, pignouf is something like dumb-ass (and champi is champignon, mushroom)

I'm not convinced that the double ptrace is really stronger than the first one, a simple GDB.py script let you bypass it:

    first = True
    class ptraceBPT(gdb.Breakpoint):
        def stop(self):
            global first
            gdb.execute("return (long int) {}".format("0" if first else "-1"))
            first = False

    ptraceBPT("ptrace")

what would be interesting is an actual use of ptrace, something like:

    int i = 10;
    int read = ptrace(PTRACE_USER_PEEK, &i, sizeof(i));
    if (read != i) printf("ptrace error");

although it still would be hard to write a GDB breakpoint that mimics it: everything ptrace can do, GDB can do it as well :)

Connected from France, Firefox in english, default was °F

> Mind asking a few things?

sure! nothing and nothing ;-) they were just leads I was trying. `target` was for:

    void **target; *target = *mov_addr; // move sizeof((void *) bits

I've updated the gist.

> Also, even though mprotect() succeeds, I got a segfault.

try in GDB something like:

    (gdb) disassemble main
    ...
    0x00000000004005dd <+64>:	mov    %rax,%rdi
    0x00000000004005e0 <+67>:	callq  0x400566 <checksum>
    0x00000000004005e5 <+72>:	mov    %rax,-0x8(%rbp)
    0x00000000004005e9 <+76>:	cmpq   $0xad4,-0x8(%rbp)
    ....
    (gdb) break passme.c:62
    (gdb) continue # should ends up *after* the memcpy
    (gdb) disassemble main
    ...
    0x00000000004005dd <+64>:	mov    %rax,%rdi
    0x00000000004005e0 <+67>:	movl   $0xad4,-0x8(%rbp)
    0x00000000004005e7 <+74>:	nop
    0x00000000004005e8 <+75>:	nop
    0x00000000004005e9 <+76>:	cmpq   $0xad4,-0x8(%rbp)

and in both disassemblies, look around 0x4005e0 (<main+67>) to see how instructions have been overwritten. In the second disassembly, if you see strange-looking instructions (eg clc), there was a problem with the copy / the instruction copied. Let me know !

I played the game another way, without reverse engineering but with execution tricks:

> https://gist.github.com/kpouget/d13b6328dd6ad8489affb3d24ad8...

1/ a simple GDB.py trick: `make debug` (passme.py ) 2/ a not-so-easy-in-the-end LD_PRELOAD trick: `make run` (passme.c)

I thought that these HW 'breakpoint' registers were (only) used to implement watchpoint, that is, read/write operations on data. Can they be used to implement 'instruction breakpoints'?

It would be interesting if the words from the different islands came from existing languages, for instance (and for myself) I would put French, Portuguese and English, to have the ability to understand how they get mixed

GDB development is driven mostly by Redhat and Mentors Graphics (ex Code Sourcery), and both of them often add new functionnalities, fix bugs and maintain GDB. But maybe their work is at too low level for most people to notice?

I still wonder what's missing in GDB. I got quite proficient with this tool, and never had access to VS. I personnally don't count GUIs built on top of GDB, as they don't provide new capabilities, just 'fancier' interfaces that GDB's CLI.

>> let's me inspect common data types without jumping through hoops?

could you elaborate on what's missing in GDB? data-types are written in the binary by the compiler (dwarf format), and GDB does nothing more / nothing less than parsing it and giving access to it through it user interface.

GDB has no knowledge about your code or it's library in itself (at least in C, Python extentions now include libc++ data-type-specific pretty-printers)

(as a French speaker,) I'm not sure to agree with the comments that associate "mise en abyme" with recursivity.

For me, examples of mise en abyme is a film shot in a movie, or story read from a book in a book. In CS, it means a function called from another function ... which is not necessarily recursivity :)

I think I wouldn't mind doing some whiteboard pseudo-coding, to brainstorm on an algorithm for instance. To design an algorithm or sketch an architecture, I don't need Internet access.

Of course I wouldn't accept any critic on syntactic mistakes or even coding style, but I could explain out loud how I construct the initial steps of a program.

I would also let explicit comments like "//google a solution for that" or "//find a library that does this"

Interesting idea, I'll give it a try tomorrow! Did you have any particular reason not to use GDB and its Python interface?

I guess that the trick is to set a breakpoint on *alloc/free, and inc/decrement a counter on breakpoint hit? I'll try to implement it in my own tool, but in Python!