Nuke the entire site fom orbit

By: Nameless Voice

2435   23   680282

Uploaded on 03/24/2009

It's the only way to be sure.

Clip from Aliens (1986)

Comments (6):

By anonymous    2017-09-20

You've basically got the right idea, you want to turn one branch into two: a branch with the stuff that's ready to go, and a branch on top of that which is the incomplete changes. For example, a branch might contain a bunch of refactoring and bug fixes interleaved with incomplete features.

A - B - C - D [master]
         \
          R1 - B1 - F1 - R2 - B2 - F2 [feature]

R1 and R2 are refactoring changes. B1 and B2 are bugfix changes. F1 and F2 are incomplete features. What you want is this:

A - B - C - D [master]
         \
          R1 - B1 - R2 - B2 [fixes]
                           \
                            F1 - F2 [feature]

There's two steps there, reordering the commits and declaring the new branch. Reorder the commits with git rebase -i. This will present something like:

pick f37beee Refactor 1
pick 7f238ea Bugfix 1
pick d100dd2 Feature 1
pick aa1124b Refactor 2
pick beadbee Bugfix 2
pick 0123abc Feature 2

Then you literally reorder them in the editor.

pick f37beee Refactor 1
pick 7f238ea Bugfix 1
pick aa1124b Refactor 2
pick beadbee Bugfix 2
pick d100dd2 Feature 1
pick 0123abc Feature 2

Git will rebuild the branch by applying those patches in the new order. You might have to resolve conflicts. For more info, see Rewriting History in Pro Git.

Then you need to declare a new branch. That's just git branch fixes beadbee to declare the fixes branch starting at the last commit you want.

Merge fixes into master normally, and rebase feature on top of master.


But often the commits are not so neatly split out. If you had a commit which contains multiple changes and you only want some of them, you can turn it into multiple commits.

Use git rebase -i as before, but set the commit you want to split up as edit instead of pick.

pick f37beee Refactor 1
pick 7f238ea Bugfix 1
pick aa1124b Refactor 2
pick beadbee Bugfix 2
edit beacd4a Messy commit
pick d100dd2 Feature 1
pick 0123abc Feature 2

Then Git will stop on that commit and allow you to edit it how you like. Use git add -p to add only pieces of the change to the staging area (where you build a commit) and git commit only the partial changes. Do this until each change has its own commit. For example, maybe it changes the name of a method, fixes a bug, but also changes an unrelated method. You'd split those into three commits: one to change the name, one to fix the bug, and one to change the unrelated method.

You can read more about that in Interactive Staging.


I'm not quite an expert in filter-branch or rebase and it looks like I can quite seriously damage the history be misusing them.

Yes, but you can reverse those mistakes, and nothing will affect anyone else unless you git push it. Git doesn't rewrite history, it writes new history and pretends it was that way all along. The old history is still there, for a while, and you can go back to it using things like ORIG_HEAD and git reflog.

Worst case scenario, delete your local repository and clone a new one.

Original Thread

By anonymous    2017-09-20

My apologies for lack of clarity in my comment.

It is impossible to reliably separate data based solely on the packet in which it arrived. Disabling Nagle's Algorithm with TCP_NODELAY may greatly improve the likelihood of getting the desired behaviour but nothing can guarantee it.

For example:

Message A is written and sent immediately
Message B is written and sent immediately
Message A is delayed on the network (too many possible reasons to list)
Message B arrives at receiver
Message A arrives at receiver  
Receiver makes Messages A and B available

recv will read everything from the buffer, Message A and Message B, up to the maximum number of bytes requested. Without some method of telling Message A from Message B, you cannot proceed.

OK, but you know the length of Message A and Message B, 6 bytes, so you simply recv 6 bytes. Right?

Almost. For a number of reasons, the sender may not be able to send the whole message in one packet and a recv for 6 bytes only returns, say, 2.

The only way to be sure, other than nuking the site from orbit, is to loop on recv until all 6 bytes have been read.

bool receiveAll(int sock, 
                char * bufp, 
                size_t len)
{
    int result;
    size_t offset = 0;

    while (len > 0)
    { // loop until we have all of our data
        result = recv(sock, &bufp[offset], len, 0);
        if (result < 0)
        { // Socket is in a bad state 
            // handle error
            return false;
        }
        else if (result == 0)
        { // socket closed
            return false;
        }
        len -= result;
        offset += result;
    }
    return true;
}

Usage:

while(receiveAll(clientSocket, buffer 6)) {
    printf("%s ",buffer);
}

This will keep looping until the socket is closed or an error forces the loop to exit. No waiting is required, recv waits for you.

What it doesn't have is a good mechanism for a polite shutdown of the client while the server is still running.

This allows the sender to remain stupid. Otherwise the sender needs to do something similar making sure that it only ever sends full messages, and no messages ever straddle multiple packets. This is significantly more effort to get right than the loop in the receiveAll function. See Akash Rawal's answer for hints on how to do this.

Original Thread

By anonymous    2018-02-12

Looks like your system is compromised. If you have a forensics team, you want to get them involved now. Tools like rkhunter can't always keep up with the malware, and trying to investigate a compromised system from inside the system is a losing battle. If you can, take a snapshot of the disk and investigate using guestfish.

Operationally, it's time to nuke it from orbit — as Ripley says, it's the only way to be sure. There's no sure way to clean up from a situation like this. You need to reinstall.

Original Thread

By anonymous    2018-08-06

@JackDeeth , [Listen to the expert.](https://www.youtube.com/watch?v=aCbfMkh940Q)

Original Thread

Popular Videos 46

Microsoft Cloud Platform

Submit Your Video

If you have some great dev videos to share, please fill out this form.