Kitsu's Life

snaury@gmail.com — Wed, 04 Nov 2009 13:48:05 GMT

Yay! I just got a free DaisyDisk license. ;)

From MacHeist via TUAW...

snaury@gmail.com — Tue, 03 Nov 2009 21:35:16 GMT

I've been studying how some program works, and while protection was really poor, one particularly interesting part turned out to be how it stores trial information. By setting breakpoints on the usual RegQueryValueEx I was quickly able to spot the interesting value that it reads/sets in the registry. And it protects that value by setting permissions on the key that deny access to Everyone, which regedit doesn't show in any way (as if that key is blank)... made me scratch my head how it reads the value that I can't see. ;) But as turned out today it was just a decoy, because the real info was stored somewhere else. :)

I went with regmon/filemon (and even more recent procmon), which of course I was filtering by the executable name, but no matter how hard I tried to look all I was seeing is the same value I already found before. More scratching my head, because this was getting interesting! How can a program can store some data, which is not in the registry, and not in some file? Finally I removed filtering by the executable name and save a huge log to dig thru it around the time program is initializing (what if it injected itself into some other process?). And when I was going thru it I spotted that lsass.exe was accessing a key HKLM\SECURITY\Policy\Secrets that was way too similar to the name I found earlier. Wait, what is this HKLM\SECURITY\Policy\Secrets?

As it turns out Windows has an LsaRetrievePrivateData API that can store computer local data (names prefixed with L$) in an encrypted/secure way. And that won't be catched by procmon/regmon if you are filtering by an executable name. Come to think of it, it's an ideal place for trial programs to "hide" data (and I spotted that I have quite a few L$ keys in there), but of course nothing you do is ever completely hidden. So if you study some program and don't know where the hell it gets its data, try hooking LsaRetrievePrivateData, or looking what lsass.exe is doing, maybe you'll find it. ;)

snaury@gmail.com — Sun, 01 Nov 2009 20:17:32 GMT

Third time's a charm:

I'm back to 2GB and lots and lots of swapping.

Damn. :(

snaury@gmail.com — Sun, 01 Nov 2009 19:16:49 GMT

So I bought 2x2GB Samsung a week ago, and today seen my first freeze. Then, after adding -v debug=0x100 to Boot.plist I got kernel panic shortly thereafter. Interesting. I wonder what the hell is going on. There were reports some people had troubles even with Samsung (and I found some photos of original Apple Samsung 2GB planks and it matches what I have), but forum posts imply they were supposed to be fixed by some firmware update or something like that.

Anyway, cleared nvram, popped memory out and then back in, maybe it will hold up (seems to for half a day), otherwise I'll see how it behaves. I'd really like to think this is not how some people say that 9400M can't work right with 4GB no matter the brand. And mixed inconclusive reports all over the 'net are really frustrating. Can't know if any shit is true or not. :-/

P.S. Maybe I really should have waited and bought Hynix, but it seemed to be really hard to come by (even those two Samsung planks were hard to find, bought them at some overpriced oem shop, where they didn't even have any boxing). Though even if I could find it I wouldn't buy it: can't be sure if it works, and getting a collection of 2x2Gb kits of all major brands is not something I want to do. Oh well... I so passively hate nvidia. Even though they are supposed to be the good guys. :(

snaury@gmail.com — Sat, 24 Oct 2009 19:24:31 GMT

WTF? You need to notify the Bureau before publishing cryptographic code on the internetz, even if it's just md5? I pity you Americans. Your government is crazy. All those algorithms became public knowledge a long time ago, so why even bother?

snaury@gmail.com — Thu, 15 Oct 2009 05:23:00 GMT

If you ever leave videos converting to iPhone in QuickTime or iTunes, and get error -9459, that's not because videos are damaged or convertor sucks. It's because your display went to sleep at the wrong moment. :)

In short, use Caffeine. :) You can even turn brightness to the minimum, just prevent display from sleeping.

P.S. I've been puzzled by this for soooo long. The most puzzling was that some videos converted successfully in iTunes, but not in QuickTime, and vice versa.

snaury@gmail.com — Sat, 10 Oct 2009 17:40:19 GMT

Today I found that trying to watch vesti.ru with Flip4Mac causes both Safari and Firefox to freeze. It doesn't even matter what version of Flip4Mac I install (the oldest version I had in my Downloads was 2.2.1.11 which definitely worked back then). Makes me wonder what's happening. :-/

snaury@gmail.com — Sat, 19 Sep 2009 13:24:41 GMT

So Kingston memory I bought recently has finally showed its face: it freezed twice in a row. Which kinda freaked me out, since I use FileVault and it's really easy to break with bad shutdowns (and lose all your data as a result). So I'll go with Hynix, and I hope it will go well.

snaury@gmail.com — Thu, 17 Sep 2009 20:39:20 GMT

Went to Moon the Movie today. Was pleasantly surprised by the original English version. Apparently theatre on Novy Arbat has one of rooms that shows untranslated movies only, so cool!

snaury@gmail.com — Wed, 09 Sep 2009 06:04:33 GMT

On a station not that far away:

snaury@gmail.com — Tue, 08 Sep 2009 21:07:44 GMT

Recently I've tried msysGit and was pleasantly surprised with the result. I'm a long time git user, and was primarily using it via cygwin. Despite cygwin being ridiculously slow, git was still much faster than bzr, and extremely powerful. Too bad some people don't understand it.

Example: there was a time that I had to convert some mercurial repository to git just to make sense of all the intertwined merges and what changes they are really bring in. The hgk (a mercurial fork of gitk) wasn't helping at all, yet after converting to git, gitk just showed relevant information nicely grouped together and merge commits didn't stand in the way as impenetrable noise. Worse, mercurial's rebase didn't work at all, so I couldn't linearize history either, yet a git converted repo didn't have any problems with rebase. Power? Extreme power!

In that recent ruby debate on migrating to git, some people tried saying that using subversion is perfectly ok, and people should just use a git mirror of ruby. Seems like these people don't know joys of using gitk as their primary analysis/change tracking tool. Let's try looking what has been going on in ruby 1.8.7 branch lately. Huh? "Merge revision(s)"? That surely tells us a lot! Thank you very much!

I guess I got side tracked and let's go back to msysGit. I was pleasantly surprised to see how well it works now, as well as to see the blazing speed improvements! (compared to cygwin) That's extremely cool! The only bad thing is that it is launched with a .cmd file, and Windows' cmd.exe is a horrible-horrible beast that really annoys me a lot (like if you call git from a batch file your batch file will just end... for obscure compatibility reason you need to use call, and exit /b %ErrorLevel% just ignores the error code, stuff like that, grrh), but perhaps I'll just cook up yet another wrapper executable. Oh, and of course it needs some patching here and there. But overall, it's really good, maybe they should stop calling it preview and start giving out betas. :)

snaury@gmail.com — Mon, 07 Sep 2009 18:14:00 GMT

Today I found out about RedHat's mingw libraries and among them Readline 5.2. When I went to download it, I found that there's already Readline 6.0, so I downloaded that, and quick check showed that all of RedHat's patches are included, sweet! With just two patches I was able to really build it with mingw and compile ruby 1.8.6 against it, so that even tests work. Uber sweet! But something was nagging me in the back of my mind... I thought, if it builds so well, why invent rb-readline, plus I heard something bad along the lines of Ruby and Readline.

And sure enough when I came home I looked in the COPYING file and my heart sank. It's GPLv3.

I hate FSF. Already we had a mess like GPL doesn't mix with OpenSSL and stuff like that. Now GPL programs can't even be used with GPL libraries. Truly GNU Readline must die. :(

snaury@gmail.com — Sat, 05 Sep 2009 19:27:44 GMT

Also I wanted to purchase Snow Leopard upgrade today and went to re:Store in Savelovsky Complex today. They call themselves Apple Premium Reseller, btw. So I came there today, and asked if they have Snow Leopard, "No" they say, "We had it yesterday, but today they're out of stock."

Ok, so far so good, it can happen right? But right after that they say "But if you want it, I could burn you an iso..."

WTF?!? I fucking came to fucking premium reseller to fucking purchase a licensed version and you fucking offer me to pirate it? If I wanted to pirate it, I'd fucking download it already! What country am I living in? Of course there's piracy in almost every corner in Russia, but to hear something like that in a Premium Reseller store is way to blatant! :-/

I really should have told them all that right in the face though, but I went away silently instead, so disappointed I was that I couldn't buy Snow Leopard. :(

Looks like I'd have to order it electronically with shipment. It's slightly more expensive, but oh well, whatever...

snaury@gmail.com — Sat, 05 Sep 2009 19:17:46 GMT

Today I went out to buy an upgrade for my macbook's memory. Initially I thought of buying Samsung memory since I initially had it installed, but that didn't really seem to be available anywhere, so I bought Kingston KVR1066D3D7/2G. Reports on the net are mixed: some say it works perfectly, some say it causes freezing, just like anything else does, but while for other types of memory (like OCZ) there were like 90% complaints, googling for "macbook KVR1066D3D7/2G" didn't show much of the bad stuff, so I decided to take a risk.

When I came home however, I noticed that the exact part number is 9905428-001.B00LF, and googling for "macbook 9905428-001.B00LF" showed that there was there was some kind of scandal when Kingston was selling KTA-MB1066 with that part number and it seems that it was causing freezes, so it suggests that the memory I bought is not compatible? I hope not, but of course time will tell.

Now for the fun part. Of course I grabbed some old Ubuntu 9.04 cds and ran memtest (2.1 or something like that) off that. The first pass completed almost perfectly, until there were several strange errors in the middle. I thought that my memory is indeed incompatible, but I left it running for some more time and nothing was found for the rest of the pass, so at the end I pressed Esc to reboot. Bam! Lots of reds. I press Esc again - and bam! - lots more. Turns out that every time I press a key while memtest is running it causes it to find errors. And indeed, in the middle of the test I pressed CapsLock because it was lit up and I found it strange.

Memtest issue? Indeed, internets suggest that this is common to have false positives on ubuntu's memtest on a macbook, so I went to memtest86.com and downloaded a fresh iso, burned it, restarted... Freeze! Ok, let me try another time: power off, power up, another option... christmas time! - my macbook's various lights light up as if its lid closed or something like that. Several attempts was the same, so memtest 3.5 (or 3.4 for that matter) don't work at all... must be something wrong with BootCamp's emulation or something like that...

But when I rebooted one of my usb ports stopped working! Looked as if it was fried, the only strange part was that it was still giving out power, and my iPhone was "sensing" it, but OSX didn't see it, EFI didn't see it either, and resetting nvram didn't help too. :( I popped the bottom lid open in search for any obvious signs of burning, but didn't find any, and when I assembled it back it magically "unfried" back. ;) Looks like memtest did something REALLY funny when it was lighting up lights like that, good thing macbook forgot it like a nightmare after reassembly, popping buttery must have reset something.

So in the end it seems that those errors were false positives and my memory seems stable for now. I certainly hope so and will stay on Kingston, 4GB is much better than 2GB. ;)

snaury@gmail.com — Thu, 20 Aug 2009 19:51:05 GMT

I always wondered what will happen if a repository on github that is a root of a network disappears. Apparently _why taught us exactly that. Even though whymirror is trying to bring repos back, the network is increasingly disconnected, and you can't see a complete picture of who forked what and when, and what people are working on on right now. :-/ Some projects are not damages very much (e.g. shoes seems to have a relatively big network right now). Others (e.g. hacketyhack) have exactly zero nodes, and what's worse, sometimes github can show you incomplete cached network, but as soon as you refresh it disappears. :-/

I hope that's just some kind of github bug in network calculation and it will be fixed or something...

snaury@gmail.com — Thu, 20 Aug 2009 14:47:34 GMT

Apparently _why decided to disappear from the internets, taking a lot of his accounts down. The theory is that this is because someone found out his real name.

This sucks. :(

And what happens to Hackety and Shoes now?
Those websites are down too... :(((

snaury@gmail.com — Thu, 20 Aug 2009 12:53:11 GMT

There's one annoyance in mingw's gcc+ld that makes it generate lots of dll imports for every ruby data symbol, which looks like this (how many times do you need to reimport rb_eRuntimeError?). What's even worse is that lookup tables themselves are repeated that many times. This screenshot doesn't show too many, but I've seen hundreds of reimports for some extensions, looks really ugly.

And what's even worse is that only the first import is "correct" (though unneeded), others are pure hacks. Here's excerpt using SEN's edump for eventmachine's fastfilereaderext.so compiled with gcc:

  Original thunk: 0004D21C
       Timestamp: 00000000 
 Forwarder chain: 00000000
            Name: 0004DA3C msvcrt-ruby18.dll
           Thunk: 0004D3A4

   Thunk     RVA   OrgThunk Orig RVA  Hint  Name
 -------- -------- -------- -------- ------ ---------------------------------
 0004D3A4 0004D7C4 0004D21C 0004D7C4    170 rb_cObject
 0004D3A8 0004D7D4 0004D220 0004D7D4    193 rb_check_type
 0004D3AC 0004D7E4 0004D224 0004D7E4    238 rb_data_object_alloc
 0004D3B0 0004D7FC 0004D228 0004D7FC    248 rb_define_class_under
 0004D3B4 0004D814 0004D22C 0004D814    254 rb_define_method
 0004D3B8 0004D828 0004D230 0004D828    256 rb_define_module
 0004D3BC 0004D83C 0004D234 0004D83C    257 rb_define_module_function
 0004D3C0 0004D858 0004D238 0004D858    275 rb_eException
 0004D3C4 0004D868 0004D23C 0004D868    403 rb_int2inum
 0004D3C8 0004D878 0004D240 0004D878    517 rb_num2long
 0004D3CC 0004D888 0004D244 0004D888    570 rb_raise
 0004D3D0 0004D894 0004D248 0004D894    639 rb_str_new
 0004D3D4 0004D8A4 0004D24C 0004D8A4    658 rb_string_value_ptr

  Original thunk: 0004D254
       Timestamp: 00000000 
 Forwarder chain: 00000000
            Name: 0004DA3C msvcrt-ruby18.dll
           Thunk: 00002069

   Thunk     RVA   OrgThunk Orig RVA  Hint  Name
 -------- -------- -------- -------- ------ ---------------------------------
 00002069 6EB0D3C0 0004D254 0004D858    275 rb_eException

  Original thunk: 0004D254
       Timestamp: 00000000 
 Forwarder chain: 00000000
            Name: 0004DA3C msvcrt-ruby18.dll
           Thunk: 000020CF

   Thunk     RVA   OrgThunk Orig RVA  Hint  Name
 -------- -------- -------- -------- ------ ---------------------------------
 000020CF 6EB0D3C0 0004D254 0004D858    275 rb_eException

  Original thunk: 0004D254
       Timestamp: 00000000 
 Forwarder chain: 00000000
            Name: 0004DA3C msvcrt-ruby18.dll
           Thunk: 0000211C

   Thunk     RVA   OrgThunk Orig RVA  Hint  Name
 -------- -------- -------- -------- ------ ---------------------------------
 0000211C 6EB0D3C0 0004D254 0004D858    275 rb_eException

  Original thunk: 0004D254
       Timestamp: 00000000 
 Forwarder chain: 00000000
            Name: 0004DA3C msvcrt-ruby18.dll
           Thunk: 000023DF

   Thunk     RVA   OrgThunk Orig RVA  Hint  Name
 -------- -------- -------- -------- ------ ---------------------------------
 000023DF 6EB0D3C0 0004D254 0004D858    275 rb_eException

  Original thunk: 0004D25C
       Timestamp: 00000000 
 Forwarder chain: 00000000
            Name: 0004DA3C msvcrt-ruby18.dll
           Thunk: 00002147

   Thunk     RVA   OrgThunk Orig RVA  Hint  Name
 -------- -------- -------- -------- ------ ---------------------------------
 00002147 6EB0D3A4 0004D25C 0004D7C4    170 rb_cObject

  Original thunk: 0004D25C
       Timestamp: 00000000 
 Forwarder chain: 00000000
            Name: 0004DA3C msvcrt-ruby18.dll
           Thunk: 00002167

   Thunk     RVA   OrgThunk Orig RVA  Hint  Name
 -------- -------- -------- -------- ------ ---------------------------------
 00002167 6EB0D3A4 0004D25C 0004D7C4    170 rb_cObject

As you can see, the first import of rb_eException points to the correct thunk, that's where address of rb_eException is linked to (note that rb_eException is a VALUE, which is essentially unsigned long). The others? Hackish. They specify the location in code (e.g. 0x2069) where code is reading from thunk, where an address of the symbol is linked, e.g. 0x6eb0d3c0 (that's where rb_eException address is placed when there are no fixups, 0x6eac0000[image base] + 0x4d3c0[thunk]). But what does code really expect? It looks, for example, like this:

        mov eax, [rb_eException thunk offset]

But gcc, when compiling code like that, actually means there should be address of rb_eException in there (direct linking), not the address of location where address of rb_eException is placed (thunk, indirect linking). While msvc usually generates more code immediately afterwards:

        mov ecx, [eax]

That's because eax at this time (in msvc) is address of rb_eException (read from thunk), so one more dereference is needed. And gcc? It expects that eax will immediately receive the value of rb_eException, so that later "one function at a time" imports do the actual job of placing correct address for them. But then what the hell the first import of rb_eException is for, and why does address in that mov points there? (when in reality it doesn't mean that) :-/ Import tables like this look really ugly to me, they are confusing to the human eye (although they are helping a little in hiew, as it doesn't show pure data imports in its assembly view, this way it can at least display something like mov eax, rb_eException for me, even though it's really mov eax, [rb_eException]), and add unnecessary bloatware.

...or was it done for compatibility with preexisting .o/.a files?...

snaury@gmail.com — Wed, 19 Aug 2009 20:21:50 GMT

Wow!

snaury@gmail.com — Tue, 18 Aug 2009 22:26:42 GMT

Suppose that you have a perl hash, which is better?

$hash{lc $_}

$hash{(lc)}

snaury@gmail.com — Sun, 16 Aug 2009 19:20:13 GMT

Magnetic Movie via Physics Buzz... wow!

snaury@gmail.com — Sun, 16 Aug 2009 17:22:25 GMT

Found somewhere about KeyPassX... Cool!

I mean, I already used to TrueCrypt + text files, but this is much much better. And since KeyPassX is open source I built a version myself, don't trust official binaries (especially when they are so fat, compiled with static Qt). So far so good. :)

snaury@gmail.com — Fri, 14 Aug 2009 22:16:03 GMT

def nil.empty?
  true
end

I wonder why this isn't in the language.
Tired of something.nil? || something.empty?

snaury@gmail.com — Fri, 14 Aug 2009 16:35:02 GMT

Deprecate my ass...

diff --git a/magick/image.c b/magick/image.c
index 1abd8ac..fe71f8c 100644
--- a/magick/image.c
+++ b/magick/image.c
@@ -1186,8 +1186,8 @@ MagickExport ImageInfo *CloneImageInfo(const ImageInfo *image_info)
   clone_info->temporary=image_info->temporary;
   clone_info->adjoin=image_info->adjoin;
   clone_info->antialias=image_info->antialias;
-  clone_info->scene=image_info->subimage;
-  clone_info->number_scenes=image_info->subrange;
+  clone_info->scene=image_info->scene;
+  clone_info->number_scenes=image_info->number_scenes;
   clone_info->depth=image_info->depth;
   if (image_info->size != (char *) NULL)
     (void) CloneString(&clone_info->size,image_info->size);

If you deprecate something (image_info->subimage and image_info->subrange in this case), then don't overwrite new members with deprecated members. Some libraries (like RMagick) actually follow your deprecations, it's not nice when they suddenly break. :-/

I spent a lot of time thinking that it was psd module not supporting number_of_scenes (which it does, at least for scene=0 number_of_scenes=1 case). Turns out it affected everything, so this patch fixes the issue.

Now I wonder who do I post it to? I couldn't find any mention of any bug tracker in sources archive or on ImageMagick website. x_x

snaury@gmail.com — Thu, 13 Aug 2009 21:00:11 GMT

District 9 was awesome. The audience was even applauding, something rare to see.

snaury@gmail.com — Thu, 13 Aug 2009 15:30:35 GMT

A little something I cooked up today:

class TimeStampedFile < File
  def write(text)
    text = text.to_s
    return super(text) if text.empty?
    count = 0
    lines = text.split("\n",-1)
    lines[0...-1].each do |line|
      super("[#{Time.now.to_s}] ") unless @line_in_progress
      count += super(line)
      count += super("\n")
      @line_in_progress = nil
    end
    line = lines[-1]
    unless line.empty?
      super("[#{Time.now.to_s}] ") unless @line_in_progress
      count += super(line)
      @line_in_progress = true
    end
    count
  end
end

Updated, it's a little bit better now...