alexkus

It's probably a typo (or copy-and-paste-o) but if your ls -l of the binary with setuid is showing "-rwxr-xr-x" then you're more than likely running a rootkit version of ls that hides setuid info.

From your gist:-

    ls -al /bin/nano       #    -rwxr-xr-x 1 root root 191976 2010-02-01 20:30 /bin/nano
    chmod u+s /bin/nano    # installs the backdoor
    ls -al /bin/nano       #    -rwxr-xr-x 1 root root 191976 2010-02-01 20:30 /bin/nano

What you should see is:-

    # whoami
    root
    # ls -l /tmp/sh
    -rwxr-xr-x 1 root root 109736 2014-01-16 16:20 /tmp/sh
    # chmod u+s /tmp/sh
    # ls -l /tmp/sh
    -rwsr-xr-x 1 root root 109736 2014-01-16 16:20 /tmp/sh
    # chmod u-s /tmp/sh
    # ls -l /tmp/sh
    -rwxr-xr-x 1 root root 109736 2014-01-16 16:20 /tmp/sh

If you've got 'ls --color' then you'll see the filename is different when setuid (white text on red background rather than light green on default background - if colours are the default).

Seems odd, even with the interesting conditions (no hot water or no electricity in some rooms), that with demand allegedly so high the "rents" are still so low.

Not always (as long as you're talking about something they are in possession of, you're right if you mean you can't prove that you don't have some flash drive hidden somewhere but, then again, it need not be encrypted if they don't have access to it).

To start simply, it's certainly possible to prove that a disk installed with a base install of an OS (and then never touched) contains no encrypted volumes if all of the remaining blocks are empty. Every file can be compared to a known good copy and if there's no other data anywhere on the disk then there can't be anything hidden on it.

From there it's a case of proving that each bit of extra data on this disk relates to a file available under the OS or a fragment of such a file (now deleted). This gets progressively harder the more the disk has been used.

It impossible to deny this when you have a GB+ sized area of unpartitioned data (or unmounted partition) containing seemingly random noise. Or a similar GB+ sized file that you cannot demonstrate to be something benign by unpacking/decrypting/etc. "It's a file of random noise I generated" is going to set off the alarm bells.

> People who can't read Wikipedia ask questions on Stackexchange.

Not saying this is an example of this behaviour but there are also groups of people kudos whoring on SE/SO by shill posting questions and then providing very thorough/researched answers shortly afterwards from their real account(s).

Not really, they still make money from someone if they've had a mortgage for a minimum period. They're still making the interest every month until it is paid back, even early. If someone pays back money early then it means they can lend out more (assuming leverage limits are being enforced). And, depending on the initial conditions of the mortgage, they may even get more money because of early repayment fees.

In the UK there are mortgages available for those doing consulting work (i.e. not on a regular salary). They generally have an interest rate about 2% higher than mortgages available for those with salaries.

And trademarked by Barclays Bank in the UK.

Excellent, thank you. I shall ignore the fact that there will be other sized grids that are looking for solutions.

Still, it's always interesting to see if one can develop something to come up with one's own solution.

Gah. Must...resist...getting...sucked...in...

If that's your 1-10 scale I'd say:-

| bog standard, journeymen, CRUD programming in Objective-C | = 3

But programming and maths aren't analogous but they're also not completely orthogonal, so my answer would be in the complex plane somewhere around:-

2.98 + 1/3i

| 2.98 + 1/3i | =~ 3

Tilt shift photography.

True, but having every structure aligned to exactly the same offset into each page is extremely unlikely. Given a page size of 4KB then a whole bunch of 32 byte structures aligned in such a way would represent a huge waste of memory. No sane allocator will allocate things like this.

If your structures happen to be very close to the system's page size it could easily happen, then you'd need to avoid this yourself with your own incremental allocator (or other tricks).

Definitely agree with your last point, I've seen lots of code (in commercial applications) where people are optimising completely the wrong thing.

You can always write your own incremental allocator to provide word aligned (or whatever alignment) blocks of memory (from a large block of memory you obtain via a usual malloc() call) for the individual structures such that their page offsets are spread evenly (and avoid other problems such as spanning pages).

[EDIT] although it is tricky to do optimally given that different processors will have different cache set characteristics (as the article shows).

> Maybe don't reveal the username unless that user has your phone number in their contacts? Sounds good. But how are you going to check? Snapchat would need to store every user's contact list, which HN also considers unacceptable. Hashing is not an effective mitigator here because it's so easy to bruteforce the space of 10-digit numbers.

There's a partial fix to this that minimises what is stored by Snapchat. It does introduce a delay as it requires the other user to be logged in or eventually log in:-

User_A joins and has 10 numbers in his contacts list and Snapchat wants to find if they are friends (i.e. they both have each other's phone number in their contact lists). All 10 numbers are provided to Snapchat, only 5 numbers correspond to existing Snapchat users, the other 5 numbers are discarded by Snapchat. These remaining numbers, now linked to snapchat Usernames, then go into a table:-

    #who, seeking
    User_A, User_B
    User_A, User_C
    ...
    User_A, User_D

When User_B next logs in the app checks for any people seeking connection with them; an API call returns a list of phone numbers which the app should check (i.e. User_B executing this would get the phone number of User_A) to see if they are in the local contact list (rather than uploading their entire contact list to Snapchat). If any numbers are in that list then they can be provided back to Snapchat and the server examines the table to find out which friends can be paired together, upon return of these results all rows for people seeking User_B will be either actioned (in User_B's contact list) or cleared (not in the contact list).

This means only a subset of a user's contact list is stored (the numbers that are known to use Snapchat), and only until the other party logs in, all of which is akin to an automated 'friend request'.

No persistent storage of all users' contact lists required, nor is there any need to store anything else about the contact list other than it contained the phone number of an existing Snapchat user.

Entries in this DB would timeout (pick an appropriate timeout) so they are not retained in perpetuity, new entries would only be created if the other user (i.e. User_B) has been active in Snapchat recently.

The app would also monitor for additions/modifications to the contact list on the phone and attempt new friend discovery by the same method. (This can be done via hashing, for each contact the app stores locally just a hash of the contact's information - name and phone numbers at least - and then on each startup (or at a certain interval) it compares the hashes it knows about with the hashes obtained from the current contact list, the friend discovery is then performed for any contacts relating to new hashes.)

User_A doesn't need to worry about missing users who join subsequently (i.e. one of the 5 numbers that were unknown to Snapchat when they first joined) as these will be handled by the subsequent user joining and going through this same process.

Have done "Live to work". 60+ hour weeks, using vacations to recover from (near) burnout, etc.

Now doing "Work to live". Moved to a 4 day week. 3-day weekends. Any extra hours are my own choice (and rare). 27 vacation days a year[1] giving me 1 week off every ~3 months plus an extra week off around Christmas. Never get near burnout.

Shame it took me so long to realise that "Work to live" is much better than the former.

1. Pro-rated to my reduced hours though. This is the UK so I also get 8 bank-holidays a year.

All true, but some people can be spurred/motivated/whatever into doing things they might not be in the frame of mind to really want to do at that point in time.

Haven't done any specific lifting for years. Having children means spare time disappears (not that I'm complaining; I just look back and wonder WTF I did with all my spare time before having a kid).

There is a bench at the work gym but there's rarely anyone else around when I use it so I'd be wary of doing anything but light weights; with no-one to spot for me I'm not going to try to get back to benching something near my own weight.

But, as I said, a 17kg 4-year-old is a semi-resonable substitute for proper lifting.

1 hour cycle commuting (30 mins each way) 4 days a week, 4000km a year just commuting, usually another 2000km a year on longer leisure/training rides (best year was an extra 6000km of long-distance rides). 5-a-side soccer twice a week (1h and 40m).

Just started back into using the gym at work to go for a run twice a week (starting at 20 minutes, building up to doing a 10k twice a week).

Even days with no specific exercise involve a long walk or other activity with my 4-year-old (lugging her about is quite a good upper body workout!)

(Ignoring the debate about the suitability of BMI for everyone...) My BMI is currently over 30 (92kg, 1.73cm) but I'm quite stockily built and haven't seen it below 25 (76kg) since my teens, not even when I was running cross country half marathons and doing lots of long-distance cycling (rides of 200km+). It's crept up as I'm eating too much and drinking a bit too much. Aiming to get back to 76kg; at a steady/sensible 0.5kg a week that's 30 odd weeks; done it before, it's not tricky. I find the bit from 85kg to 76kg much easier than the first bit from 92kg to 85kg; running is much more unenjoyable (I dislike it at the best of times) when heavier.

I lurch between years of lots of exercise and fallow years, 2014 should be a good year.

Indeed, but his track record isn't absolutely perfect if you remember his misguided analysis of the Bitcoin blockchain, a paper which was subsequently withdrawn[1].

1. https://news.ycombinator.com/item?id=6804440

Closer to $1000, but that's not surprising really.

I believe the "3.5GHz 6-core with 12MB of L3 cache" chip is this one http://ark.intel.com/products/75780 which has an RRP of $583.

The difference in retail prices for those two chips is $2031 (2614-583) but you're paying Apple $3000 for that upgrade.

No, you can prevent unbounded growth by using a pre-allocated cyclic buffer and just write into that.

We have prototypes of this in our software (but not production code yet) with buffers that default to 50MB. That gives a nice amount of debug info in the run up to any errors.

Whenever the buffer is dumped out you simply set the begin/end pointers of the cyclic buffer to be the same so that subsequent errors don't write out an entire copy of the buffer again, only the new log messages since the previous error.

Don't BT end up getting some/most of the line rental money anyway; whether directly passed on or via a Wholesale Line Rental?

(UK at least...)

You couldn't just point blank fire the bottom x% each year based on their ranking, you'd need to give the bottom x% warnings and put them on an improvement plan (so they have a chance to improve) and then, for those that don't, you can sack them.

Even then it may be tricky if you are cutting too deeply. Taking it to the extreme you couldn't use this method to fire the bottom 99% of employees as a tribunal would take that as constructive dismissal.

Firing the bottom 5%, after appropriate warnings/etc, is in the realms of possibility as there's a good chance that the employer can provide documentary proof that the employees fired were performing below expectations should a disgruntled employee take them to tribunal (which, sadly, now costs the dismissed employee £250 to file the claim and £950 if it goes to a hearing.)

But, Bit^H^H^Halt-coins!

> "Even using conservative, realistic estimates... it's still possible that organisms could be swimming around out there in the oceans of Europa," she said.

    ALL THESE WORLDS
    ARE YOURS EXCEPT
         EUROPA
       ATTEMPT NO
     LANDING THERE

Fine, but how would you verify your read-only USB stick or LiveCD before use?

Theoretically someone could sneak and replace the LiveCD with one that looks identical but is infected with the required malware[1].

Carrying it on you, or locking it in the safe in the room[2], might mitigate that I suppose.

1. Sneak in once, steal a copy of the USB/LiveCD contents, go away and create a new version infected with malware, sneak in again and swap them over.

2. Not really safe as one previous link on HN showed.

If you look at the photo it's just three sets of racks that have been mirrored to the other side; the ones with the orange lights and red cables. None of the other racks looked mirrored.

Base64 of the encrypted php malware (after the initial decryption phase but before the XOR decryption): http://pastebin.com/YfcKSLQq

I tidied up the code I used to analyse it and uploaded it here:-

xor.pl: http://pastebin.com/NBhmSu1k

(Focus was on a quick hack not code quality or documentation!)

Oh yes, although too many "alias" commands will mean that it's possible to search for the known plaintext of 'alias'. But the more non-ascii bytes there are the more it will put off my analysis which dependeds on isprint().

Not sure, "define" only appears 10 times but "function" appears 19 times. It's probably because 'e' is more popular in the code and "define" has two of them. Looking at the decrypted code there are much better strings to try; "function_exists" gives the right key first time too.

It could have been made a lot harder by using comments at the end of each line to pad the code with extra characters to equal out the frequency distribution and make this kind of frequency analysis impossible.