Random Rant about Canon (again)

I wanted to scan some documents in MP Navigator 3.0 and generate a PDF. I typed a longer than usual name for the file name. Here's the message box I received:

---------------------------
MP Navigator
---------------------------
Le nom de fichier est trop long.La longueur maximale est de 32 caractères d’un octet.
---------------------------
OK
---------------------------

It roughly means: « The file name is too long. The maximum length is 32 characters of one byte. » (!?!)

Hummm welcome in 2007!

And I still haven't talked about my problem with the intelligent chipset on the color inkjet cartridge that stops working and that force you to buy a new cartridge even if yours is still almost full!

And forget about Canon's support. I tried. The only thing I received from them is *2* surveys to know if I'd buy Canon branded hardware again.

How to make MP Navigator 3.0 work with a MP800 on a x64 OS

Well, sometime it worked, sometime not. I found the solution on a forum. (sorry no reference) The fix is really simple. Add « C:\WINDOWS\twain_32\MP800 » to your %PATH% environment variable. That fixed the problem for MP Navigator 2 and 3 instantantly.

Keywords: W2K3, XP, Windows Server 2003, Vista

ALPC

It means "Advanced Local Procedure Call". It seems like a light-weight RPC or if you prefer a heavy-weight LPC.

You won't find a lot of documentation on this one. Mark quickly refered to it in Inside the Windows Vista Kernel: Part 3. Microsoft has been granted a patent which infers to look for UMDF documentation. (I have to admit I still haven't read it) But the WDK is silent about this subject. It seems to be implemented in msrpc.sys (and not in the kernel like LPC). Microsoft documented references to ALPC for Event Tracing and for their new Wait Chain Traversal (which seems great).

More on this later.

LG FM20

Here's some comments on a small and nice MP3 player: LG FM20

It got everything I want:
- Usable as a standard usb key *MUST*
- Can get back the music files from the player to the computer *MUST*
- Use standard USB cable *MUST*
- No need to install any software to make it work *MUST*
- FM tuning
- Record: voice (internal mic), line-in (thru custom wire usb -> 1/8" jack, included), FM
- Record as MP3 (96/128/192 user selectable) *MUST* (if recording is supported)
- Long lasting and light lithium battery
- Plays OGG & WAV files
- Includes strange short songs. I really needed those! :)

When you unplug the usb cable, it scan all the files and reconstruct the ID3 database. That's simple and it works great. I hate to use custom software (like iTune or Windows Media Player) to upload my songs. To make it work this way you have to set it to be in MSC mode. You you want to save some space you have to connect to a computer with Windows Media Player 10 (i.e. not W2K3) to remove the funky music included by default and format the device to reclain space. The player include some strange music like "LG Song", kind of Korean pop. I find myself singing "Saya gey yo, Saya gey yo LG!". 1:40 of pure attrocity. I'll try to better understand Asian culture someday.

The player can read the files of both MSC and MTP mode. But you can't access the files from "the other mode" on the computer. That's not a big deal.

The only issue I have is that there is a high pitched tone that is independant of the user volume. It's only audible with good earphones when the sound volume is set to less than half but for the price I'll sustain this.

Update: You can update the player firmware to v2.02 but I haven't seen any difference. I had 1.06 before.

Update 2: In fact, I have seen a difference. The code page has been reset to the default one which is Korean. Fortunately, the 1.06 firmware package on the web site contains all your favorite code page file for the device. Just put the right .TBL in the CONFIG\ folder and you're set.

How to make MP Navigator 3.0 work with a MP800

[Directly skip to the last update section]

This post is a note to me. Skip to conclusion if you don't have a Canon MP800 nor a Creative Live! Cam Voice.

I bought a MP800 8 months ago. One of the main reasons I bought this model was that it supported Windows x64, which at the time was pretty scarce. I have a x64 server which I connected my printer to it so I can print wirelessly with my laptop. It works very well in fact.

I bought the Live! Cam for the same reason: x64 support.

A while ago I started having problems with the included software, MP Navigator 2.0. I mainly use it for scanning photos and negative film. So I looked at the Canon's web site to see if there was an updated version of this software. I found out that there was the 3.0 for the MP810 but it was not available for the MP800.

The way to make the 3.0 version works with MP800 is to copy the mp810.ini to mp800.ini and replace the values in the [Device] section:
Replace 171A to 170D.
Replace 810 to 800.

That's it. There must really have a technical reason to not support the MP800. :)

By the way, the reason the old version stopped working was because I had enabled DEP for every program. It made Canon and Creative software go havoc. I think it is related to a crappy video filter that gets loaded but I couldn't pinpoint which one. I manually disabled DEP for each of their executable and it now works well.

Conclusion: it's a sad thing to have to disable DEP to make consumer-grade software work.

[Update 2007-07-21] It wasn't clear. The file to copy for MP Navigator 3.02 is located at C:\Program Files\Canon\MP Navigator 3.0\Device and there is 2 times 171A and 6 times 810 that needs to be changed.

[Update 2009-11-13] From Canon USA web site, you can grab MP990's version of MP Navigator EX v3.04 and MP800's version of MP Navigator v2.02. Copy C:\Program Files (x86)\Canon\MP Navigator 2.0\Device\mp800.ini to C:\Program Files (x86)\Canon\MP Navigator EX 3.0\Device\mp800.ini . Voilà!
Greetings to Canon folks for not including the file.

Québec has a different culture

Usually I'll refrain from rants but this one was too good to pass by.

---

Let's face it, Québec's culture is different. Here's a sample that shows it in it's most intricate way:

How to pay your deduction at source (as an employer, which I am) for Federal (Canada) and Provincial (Québec) governments

Federal way

a. Only once: you had to enter your company's number into your bank account invoices list. No big deal here.

1. Calculate how much you retained for federal taxes and IE from your employee's salary for the month. Just retain the whole summation, not indivual numbers.

2. Login into your bank account

3. Write the amount and click "Pay".

Provincial way

a. Only once: you had to register your account on ClicNet (which shouldn't be a problem but it is: you need the serial number of the last taxes-related document that the provincial government sent you)

1. Do the summation of how much you retained for each of those amounts: provincial taxes, RRQ, RQAP and FSS from your employee's salary for the month. You need the individual amounts.

2. Login to ClicNet


3. Follow through eight secured, slow web pages visibly done in ASP.NET by a teenager to enter each separate amounts

4. Specifically ask that you want to pay at your bank's web site, and which bank

5. Finally receive a 19 digits confirmation number after dismissing useless window that pop up. Sometimes the web server goes down so you have to do the whole thing again later.

6. Login into your bank account

7. Enter the 19 digits confirmation number

8. Enter the summation of provincial taxes, RRQ, RQAP and FSS (you hadn't calculated it before) and click "Pay"


The subtility here is that the provincial government wants to know how much you give to each of their internal accounts right now, not at the end of the year. As an employer it's the least of your business but the government wants you to know.

I need to add that the provincial step only needs to be done in Québec province, as I am aware of. Employers based in other province only need to do the payment to the federal government. Also, don't be fooled, the province's bureaucracy is not that bad, well, just sometimes, and the province is actually a great place to live!

Rationale behind UAC

I don't have any "insight" knowledge. Everything written in this post is directly coming from my head. This is what I think is the rationale behind UAC. All terms and acronyms have been explained in previous posts. It is not a pledge to Microsoft's design and implementation; it is simply an analysis of its behaviour and a deduction of the intended solutions.

Why MIC?
MIC permits a separation of access to object, either live or permanent. This comes in two parts.

First, the permanent objects with higher level will be protected from low level process, for a write-only perspective. You may say that it is not secure. It's true, except that it is at least enough secure for the protected audio process. Coupled with dual-token, MIC actually helps security. The reason is that it is an orthogonal layer of protection compared to token's SID. Think of it as a multiplicator for your SID privileges. Why didn't they leverage group SIDs to simply define a group SID for every level and use deny group SID for higher levels on DACL? In a way, it is actually explained this way: the SACL contains an SID with a variable end that is the IL. The only difference between the "variable" SID and defining specific IL group SID is that every higher level would have to be denied, not only setting a "level". MIC's design permits a much higher level of granularity that group SID; 6 levels are currently defined, but there are 0x6000 levels in total. Deny group SID wouldn't scale that well...

The second part is that permanent objects get an intrinsic IL too. This permits the "protection" that is necessary for registry/file system on Vista. The dual-token scheme (explained later) is non-persistent; ILs are. You can view it as a dynamic remapping of your access rights of the resources. On Windows, there's already some generic restriction that is done per-user. In Terminal Services (fast user switching), \??\ is remapped by session but there is no granularity per-process. MIC permits a more granular distinction even for one token with the same group SIDs in it and in the same session.

Why MIC does not cross computer boundary?
MIC can't cross computer boundary since I think SMB/NTLM does not implement it and I think it is not part of the token. (In fact, I'm not sure; it's maybe part of the token, TBV) It is part of the active process.
It's part of objects too, but since the re-created token on the server isn't the same as the client's token, the MIC can't be determined.

MIC can't cross computer boundary for a very simple reason. IL on the token (or active process, whatever) is set for this process and can only be lowered. When you access a remote resource, your token is not duplicated; you are network logged in on the remote computer so your token is actually different. Since there's no IL concept in the login procedure, that IL is inherited and lowered by the parent process, the network logon is always at high IL. Furthermore, network shares are entirely executed in kernel space, and if Process Explorer is right that ILs is a process property and not a token property, there's no MIC concept there either. (I'm not 100% sure about this, it needs verification. I finally think the IL is in fact a token's attribute even if documentation let think that it's a process' attribute.)

Why dual-token?
MIC is not a true security scheme. It is not sufficient alone to really protect from processes running as standard user. This is because it is an inheritance-only scheme. Dual token alone is not sufficient either because a process running as a standard user still have access to other process running as the same user (object ownership is the key here). The same apply to permanents objects too. Dual-token doesn't protect from shatter attacks. So the dual-token helps in having a personality that can be upgraded. It's not possible in MIC. IL can only be lowered, not increased. With dual-token, your level can be increased by gaining access to your original token. This original token is used to do the DACL verification when consent.exe has been executed.

The original token is really the normal token you'd get when UAC is off. The secondary token is a token with many privileges removed and with a Administrator Deny-only SID added. What it means is that if there is a resource that explicitly denies access to administrator, you won't be able to access resource denied to administrators even with your standard user equivalent token. This has been done to make sure administrators continue to be correctly denied resources they were already being denied (user's secrecy, I personally deny access to files for SYSTEM to make AVs stop bothering me, when I'm stuck with an AV, which doesn't happen often).

I talked about remapping in MIC. Well with dual-token, the global \??\ root is actually different for each token, like if they were on a different session. What it means in practice is that if you map a remote drive with the standard version of your token, you won't see it in the administrative version of your token. It's to complete the security of namespace. It will also bother people.

Why dual-token cross computer boundary?
Because of two things. Remember that when you access a network resource, you are actually network logged on. Since a logon is done, UAC still kicks in. UAC kicks in on the server, not on the client. So if UAC is disabled on the server, you will get your normal administrator token. Network logon could have been exempted from this scheme but it wasn't for a good reason. An old trick is the file:////localhost/c$ access (Note: I hate blogger's automatic reformating). If a user can chain thru local share to get back administrative access to the file system, there would be no point to dual token. This is another point where MIC couldn't have handled this alone.

Why UAC?
UAC is mainly the UI to make MIC and dual-token work. It's bothering, and the whole thing mainly done to make ISVs follow the "recommended" behaviour. In fact, this is a good thing; forcing ISV's hand, not bothering users.

Why virtualization?
That's a solution to the previous solutions' problems. Microsoft wanted to make legacy apps run better on Vista at the same time. If they wouldn't use virtualization, users would have been hammered with more popups that you can even imagine. Since virtualization may activates when you are on standard user token, the Admin-only resources look like they're allowed and UAC don't kick in. This behaviour will cause troubles to many people, but I think Microsoft felt obliged to do this because otherwise it would have been unmanageable for users running with the standard user token. Since Microsoft's goal is to force ISVs to make their application well behave in standard user environment, UAC was a must for them and virtualization was an obliged patch.

Note that applications with a correct manifest and x64 executable won't get virtualized. This is to stop virtualization somewhere. So what if virtualization is a problem for your app or you want to stop having virtualization for a specific third-party application? Simply place a correct manifest beside the executable, if the executable doesn't have a manifest already embedded in it. Otherwise, it will simply not work, i.e. you have to update the embedded manifest with some resource editing tool like VS2005. It is the trustInfo section that needs to be added, yes, the section that used to BSOD Windows XP. :)

I'd like to thank an anonymous friend for pointing out some errors before posting, but since he's not confident in what I'm saying, he'll remain anonymous. :)