Older blog entries for mcr (starting at number 59)

28 Mar 2010 (updated 8 Apr 2010 at 21:07 UTC) »

Online Fraud

My MPP, Yasir Naqvi has been in the news complaining that someone "stole" his identity, and sent out an email mis-representing his views. Nevermind what his views are.

http://www.yasirnaqvimpp.ca/pressreleases.aspx?id=61

http://www.ontla.on.ca/web/members/members_detail.do?locale=en&ID=7097

Mr. Naqvi's identity was not stolen --- he is clearly still him. If it was stolen, then he would no longer have it.

His email account was not "hacked" --- someone simply set up a new identity on gmail claiming to him. But really, there are dozens of higher-tech ways to impersonate him. In fact, ANYONE CAN IMPERSONATE ANYONE on the Internet.

The press have repeatedly written the story wrong. http://www.vancouversun.com/news/politician+livid+after+fake+mail+sent+list/2732203/story.html

"On the Internet, nobody can tell you are a dog", was the comic from over a decade ago.

The real question is, why, in 2010, 12 years after S/MIME became a standard (1998) and 14 years after PGP was documented (1996), our governments and representatives are still completely in the dark about what it means to be online.

http://www.rfc-editor.org/info/rfc1991 http://www.rfc-editor.org/info/rfc2311

And there are lots and lots of further documents about PGP, OpenPGP, and S/MIME. My email has been signed with PGP since about 1994. Think about this: I've been signing my email longer than the kid serving you at McDonald's has been alive.

"Poor planning on your part does not constitute an emergency on my part".

You were warned. MANY MANY MANY TIMES.

Provincial governments and federal governments have very clear, centralized IT support and services, and they could trivially roll out email security.

Have they done so? Why haven't they? It seems like NEGLIGENCE to me.

I documented above when the standards were written, but in fact that is 3-8 years after the technology became available --- so it's more like 20 years since you could have started using PGP.

It's not like S/MIME is not ubiquitous --- it's one of the major reasons that I've been told that government organizations HAVE to run Outlook: Nothing else has been evaluated by the CSE for use in government work. (Why that is, is another rant)

SO WHY ARE THEY NOT USING IT?

This is not a rhetorical question. I want to know. What part of "email is not secure" did they not get? Maybe they were not there that day in class.

Shame on you Mr. Naqvi. Go do some learning and start asking some real questions.

Syndicated 2010-03-28 12:36:00 (Updated 2010-04-08 21:07:51) from Michael's musings

Thing I saw at Active Surplus

I was in Toronto at the AGM for http://www.EspressoCode.com/. I had to stop at Active Surplus for switches and what-not for my model railroad. I certainly the a "what-not"

Check it out:

[[http://www.sandelman.ca/mcr/humour/2010-02-04-10-46-whatnot.jpg][Some kind of Pumpy Thing]]

Syndicated 2010-02-08 01:40:00 from Michael's musings

8 Feb 2010 (updated 8 Feb 2010 at 02:11 UTC) »

Thing I saw at Active Surplus

I was in Toronto at the AGM for http://www.EspressoCode.com/. I had to stop at Active Surplus for switches and what-not for my model railroad. I certainly the a "what-not"

Check it out:

[[http://www.sandelman.ca/mcr/humour/2010-02-04-10-46-whatnot.jpg][Some kind of Pumpy Thing]]

Syndicated 2010-02-07 20:02:00 (Updated 2010-02-08 02:11:25) from Michael's musings

Sharp microwaves

My Samsung microwave died last March. It makes sparks from the magnetron. I tried a bit to see if I could get a new one, but it's annoyingly difficult, since the magnetron is half the cost of the unit.

I'd really like to buy a microwave not-made-in-China. Sharp is reported to make them in Japan, assemble them in the USA.

But, I can not find a store that sells them. I'd really like to touch one before I buy it.

Syndicated 2010-02-02 00:44:00 from Michael's musings

Sharp microwaves

My Samsung microwave died last March. It makes sparks from the magnetron. I tried a bit to see if I could get a new one, but it's annoyingly difficult, since the magnetron is half the cost of the unit.

I'd really like to buy a microwave not-made-in-China. Sharp is reported to make them in Japan, assemble them in the USA.

But, I can not find a store that sells them. I'd really like to touch one before I buy it.

Syndicated 2010-02-01 19:44:00 from Michael's musings

no-op instructions for ARM

At http://www.credil.org/ we had to deal with some code that was not yet GPL compliant, fixing bugs (removing features!) from a .so file that we had. We had some of the source code, but not enough to recompile it.

We needed to disable certain calls, so we disassembled the object file with objdump -d. We then reviewed the code, looked for the calls we wanted to remove, which are "bl" instructions.

../../prebuilt/linux-x86/toolchain/arm-eabi-4.3.1/bin/arm-eabi-objdump -d libmyso.so >libmyso.S

All branch instructions are conditional, but one valid condition is "branch always" (and link, which means it's a subroutine). See: http://www.peter-cockerell.net/aalp and http://www.peter-cockerell.net/aalp/html/frames.html, section C which is at: http://www.peter-cockerell.net/aalp/html/app-c.html

Just look, if we change 'e' to 'f', it becomes Branch Never! We tried that.

Oops, this doesn't work. Peter Cockerell's book (from 1987) documents ARMv3, and we are up to ARMv9. It seems that his bit pattern now means to branch, and change to THUMB mode... The clue that this is what happens is that when we disassembled the result we saw "blx", but the real clue was that the offset was no longer "place", instead was "place+2". Thumb instructions are 16-bit big.

See http://www.keil.com/support/man/docs/armasm/armasm_cihfddaf.htm for details of BLX.

So, how to create a NOP? We didn't see an official one. Some googling revealed that "MOV R0 R0" is a good choice.

http://www.keil.com/support/man/docs/armasm/armasm_cjafcggi.htm

To assemble this:

First nibble is 0b1110 (15, 0xE) for "Always".

Second nibble is 0b0001 (1, 0x1), for 00, Immediate bit = 0, first bit of opcode is 1. (The Opcode is 0b1101 (14, 0xD) for MOV)

Third nibble is 0b1010 (10, 0xA), three bits of opcode, S bit set to 0.

Fourth nibble is 0x0000 (R0), and Fifth nibble is 0x0000 (R0).

The last 12 bits are 0.

The result is: 0b1110 0001 1010 0000 0000 0000 0000 0000. Or 0xE1A00000.

We didn't realize that the Android phones are in big-endian mode, so when we searched for the right instructions to change, we did not find them.

When you objdump a .so file, it's mapped directly, so the offsets that objdump products are actual file offsets.

Syndicated 2010-01-06 03:11:00 from Michael's musings

no-op instructions for ARM

At http://www.credil.org/ we had to deal with some code that was not yet GPL compliant, fixing bugs (removing features!) from a .so file that we had. We had some of the source code, but not enough to recompile it.

We needed to disable certain calls, so we disassembled the object file with objdump -d. We then reviewed the code, looked for the calls we wanted to remove, which are "bl" instructions.

../../prebuilt/linux-x86/toolchain/arm-eabi-4.3.1/bin/arm-eabi-objdump -d libmyso.so >libmyso.S

All branch instructions are conditional, but one valid condition is "branch always" (and link, which means it's a subroutine). See: http://www.peter-cockerell.net/aalp and http://www.peter-cockerell.net/aalp/html/frames.html, section C which is at: http://www.peter-cockerell.net/aalp/html/app-c.html

Just look, if we change 'e' to 'f', it becomes Branch Never! We tried that.

Oops, this doesn't work. Peter Cockerell's book (from 1987) documents ARMv3, and we are up to ARMv9. It seems that his bit pattern now means to branch, and change to THUMB mode... The clue that this is what happens is that when we disassembled the result we saw "blx", but the real clue was that the offset was no longer "place", instead was "place+2". Thumb instructions are 16-bit big.

See http://www.keil.com/support/man/docs/armasm/armasm_cihfddaf.htm for details of BLX.

So, how to create a NOP? We didn't see an official one. Some googling revealed that "MOV R0 R0" is a good choice.

http://www.keil.com/support/man/docs/armasm/armasm_cjafcggi.htm

To assemble this:

First nibble is 0b1110 (15, 0xE) for "Always".

Second nibble is 0b0001 (1, 0x1), for 00, Immediate bit = 0, first bit of opcode is 1. (The Opcode is 0b1101 (14, 0xD) for MOV)

Third nibble is 0b1010 (10, 0xA), three bits of opcode, S bit set to 0.

Fourth nibble is 0x0000 (R0), and Fifth nibble is 0x0000 (R0).

The last 12 bits are 0.

The result is: 0b1110 0001 1010 0000 0000 0000 0000 0000. Or 0xE1A00000.

We didn't realize that the Android phones are in big-endian mode, so when we searched for the right instructions to change, we did not find them.

When you objdump a .so file, it's mapped directly, so the offsets that objdump products are actual file offsets.

Syndicated 2010-01-05 22:11:00 from Michael's musings

4 Jan 2010 (updated 6 Jan 2010 at 04:05 UTC) »

An open Letter to Shaw Direct

Dear Jim,

You write, "Over the last 8 years, we have seen huge advances in the technology of our receivers without an impact on the MRF. Effective Feb. 1, 2010, the monthly rate for MRF (multiple receiver fee) will increase by $1/month to $5.99/month"

Over the past 8 years this is simply not true.

When I signed up in the summer of 2001, there was no multiple receiver fee. So, the MRF fee has in fact gone up by $5 over the last 8-9 years.

Meanwhile, my receiver is still the same VERY SLOW piece of crap motorola receiver you made me buy in 2001. I've seen no improvement in technology at all, and I'm locked into buying crappy, closed source, proprietary receivers if I want to receive your signal. You make me pay for the equipment, and then prevent me from using it the way I want.

When I first signed up, you gave me this "credit" on programming, but you made me spend it on your premium package, rather than on the basics package that I wanted, which meant that the receiver really cost me 2x as much as I was lead to believe.

The packages are such that I get hundreds of channels I do not want, and I can not get the two or three channels that I want without huge expense.

Meanwhile, the number of Pay-per-vue channels continues to decrease (and most of them are porn), I guess because you never bothered to offer your loyal customers an upgrade to the oval dish, and I can only see one of the two satellites.

If hulu.com opens in Canada, you can kiss my business goodbye.

If any local TV stations disappear from my dial, you can kiss my business goodbye. If you pass on any local TV tax to me, then I can assure that I will simply cut my bill by that same amount, or give up, and just watch DVDs.

Syndicated 2010-01-04 15:35:00 (Updated 2010-01-06 04:05:25) from Michael's musings

IPv6 with mcast UserModeLinux backends

I am doing some work with IPv6. (see http://bluerose.sandelman.ca/projects/show/unstrung )

I have a test network shown at: http://bluerose.sandelman.ca/repositories/changes/unstrung/doc/network-1.png

In automated testing I would normally use the daemon mode, with uml_netjig. In casual use, I was using the mcast backend, because it has fewer moving parts.... but my network interfaces kept remaining in state "tentative" and I could not send packets.

What was the problem, I debugging for awhile through the IPv6 code, and finally thought that it had something to do with the UserModeLinux network interface never providing low-level LINK "UP" signal, and so it never did Duplicate Address Discovery, and remove the tentative mark.

5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 fe80::1000:ff:fedc:bcff/64 scope link tentative
       valid_lft forever preferred_lft forever
6: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 fe80::1000:ff:fe64:6423/64 scope link tentative
       valid_lft forever preferred_lft forever

Note that it says "tentative".

NO! DAD was occuring just fine, but it FAILS. Why? Because it thinks it has a duplicate... finally I noticed

eth0: duplicate address detected!
eth1: duplicate address detected!

Why is this? It's because the mcast interface gets a copy of the packets that are output. I.e. it hears itself. DAD should work even when that happens, I think.

I need to look at whether the mcast interface should be fixed (remember it's own packets and ignore them? Drop packets that originate from it's own MAC address?), or should DAD be fixed?

Syndicated 2009-12-27 03:08:00 from Michael's musings

IPv6 with mcast UserModeLinux backends

I am doing some work with IPv6. (see http://bluerose.sandelman.ca/projects/show/unstrung )

I have a test network shown at: http://bluerose.sandelman.ca/repositories/changes/unstrung/doc/network-1.png

In automated testing I would normally use the daemon mode, with uml_netjig. In casual use, I was using the mcast backend, because it has fewer moving parts.... but my network interfaces kept remaining in state "tentative" and I could not send packets.

What was the problem, I debugging for awhile through the IPv6 code, and finally thought that it had something to do with the UserModeLinux network interface never providing low-level LINK "UP" signal, and so it never did Duplicate Address Discovery, and remove the tentative mark.

5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 fe80::1000:ff:fedc:bcff/64 scope link tentative
       valid_lft forever preferred_lft forever
6: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 fe80::1000:ff:fe64:6423/64 scope link tentative
       valid_lft forever preferred_lft forever

Note that it says "tentative".

NO! DAD was occuring just fine, but it FAILS. Why? Because it thinks it has a duplicate... finally I noticed

eth0: duplicate address detected!
eth1: duplicate address detected!

Why is this? It's because the mcast interface gets a copy of the packets that are output. I.e. it hears itself. DAD should work even when that happens, I think.

I need to look at whether the mcast interface should be fixed (remember it's own packets and ignore them? Drop packets that originate from it's own MAC address?), or should DAD be fixed?

Syndicated 2009-12-26 22:08:00 from Michael's musings

50 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!