[jaclaz]

ilko_t, on Sep 4 2009, 12:53 AM, said:

cdob, on Sep 3 2009, 03:18 PM, said:

This would require ParentIDPrefix 6 7 8 and all possible combinations. Seems redicilous.

You are right, as always. Clean explanation would be nice.
However, wouldn't 6,7 and 8 & ParentIDPrefix & 0 cover all possible cases when USB/memory stick is prepared on 2k/xp/2k3 machine? This means 3 letters...

And maybe it would also solve the "racism" issue about letter V: :

• U:
  
• V:
  
• W:

Yes , I do like it better than:

• U:
  
• W:

And the "Association for the promotion of a wider use of letter V in drive assignments" will probably stop nagging me.




jaclaz

[ilko_t]

cdob, on Sep 3 2009, 02:18 PM, said:

...I seek and prefer a ParentIDPrefix explanation still...

Here is a bit more information:
http://bbs.driverdev...d.php?tid=96099
http://translate.google.com/translate?hl=e...GGGL_en___GB229

Quote

The first three, said the device inside the device tree in the whole level. He was in the third grade
root是0,root下面是acpi再下面是pci root bridge.这个设备就直接在root bridge下面 root is 0, root following are acpi and then following is pci root bridge. this device directly below the root bridge

Here is good explanation of the device tree:
http://msdn.microsof...y/aa489660.aspx


Osronline have a nice program DevTree, which can display tree from PNP manager perspective, free registration is required for download link:
http://www.osronline....cfm?article=97

About the algorithm calculating the hash- in AutoIt forum helped with it and provided similar code to calculate it in AutoIt, now I can understand the C macro used to calculate it:
http://www.autoitscr...howtopic=104426

Can you figure out why exactly the level changes in some occasions? Which one is the missing "hop"? How an internal card reader for example would move one hop up, getting level 6 for example?

[jaclaz]

I seem not able to connect to the autoit place.
And of course I do not understand the C code.

Anyway keep going.

jaclaz

[cdob]

ilko_t, on Nov 9 2009, 06:47 PM, said:

Can you figure out why exactly the level changes in some occasions? Which one is the missing "hop"? How an internal card reader for example would move one hop up, getting level 6 for example?

I'm a human only and the crystal ball is empty

Well maybe another kernel, hal or ACPI configuration does interfere too?

Device tree is a good explanation in general: does match in most cases.

Of coure there exeptions.

Given removable USB Stick direct attached to USB port: ParentIdPrefix 7&*&0

Driver stack:
1 ntoskrnl.exe, hal.dll
2&daba3ff&0 acpi.sys
3 pci.sys - no ParentIdPrefix
4&11cdd0bd&0 usbehci.sys
5&38c8e674&0 usbhub.sys
6 usbstor.sys - no ParentIdPrefix
7&776bc3a&1 disk.sys

Next remove USB Stick, attach a USB hub. And insert USB Stick to the USB hub.
Device tree is one step deeper: I expected ParentIdPrefix 8&*&0
However ParentIdPrefix stays at 7&*&0.
A double usbhub.sys dosn't matter, driver is loaded and used once.

I recogiced strange behaviour using a USB controller without a SerialNumber.
This is a fixed USB hard disk. MountedDevies does NOT use ParentIdPrefix.

Windows PNP the hard disk for each USB port.

 
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\Vid_05e3&Pid_0702\5&38c8e674&0&2]
"Service"="USBSTOR"
"ParentIdPrefix"="6&27caf906&2"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\Vid_05e3&Pid_0702\5&38c8e674&0&5]
"Service"="USBSTOR"
"ParentIdPrefix"="6&28d260fd&2"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses\{53f56307-b6bf-11d0-94f2-00a0c91efb8b}\##?#USBSTOR#Disk&Ven_SAMSUNG&Prod_HM160HC&Rev_0811#6&27caf906&2#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}]
"DeviceInstance"="USBSTOR\\Disk&Ven_SAMSUNG&Prod_HM160HC&Rev_0811\\6&27caf906&2"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses\{53f56307-b6bf-11d0-94f2-00a0c91efb8b}\##?#USBSTOR#Disk&Ven_SAMSUNG&Prod_HM160HC&Rev_0811#6&28d260fd&2#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}]
"DeviceInstance"="USBSTOR\\Disk&Ven_SAMSUNG&Prod_HM160HC&Rev_0811\\6&28d260fd&2" 

Recogince the main difference:
USB hard disk, ParentIdPrefix 6&28d260fd&2 usbstor.sys. (6th driver in stack)
USB stick, ParentIdPrefix 7&776bc3a&1 disk.sys (7th driver in stack)

Idea:
Drive SerialNumber and relating windwos configuration (GlobalDisableSerNumGen, IgnoreHWSerNum*) may be importand.

A USB stick with a serial number get ParentIdPrefix 7&*&0 at the same USB port.

I don't pocess a USB stick without a serial number and can't test this.


Finally: yes, the driver stack does set ParentIdPrefix N&*&*.
Windows may connect ParentIdPrefix to different drivers. True reason is unkown.


Added, more ideas:
A addional (non windows default) driver in stack may cause ParentIdPrefix 8&*&*.
A default windows installation set ParentIdPrefix 7&*&0.
A end user install some addional USB driver into driver stack: ParentIdPrefix is changed to 8&*&*.

This post has been edited by cdob: 11 November 2009 - 04:42 PM

[ilko_t]

You've got a lovely knowledgeable crystal ball, I have no doubts

[jaclaz]

cdob, on Nov 11 2009, 11:33 PM, said:

I don't pocess a USB stick without a serial number and can't test this.

Well, just post some details of the USB sticks you have handy as seen by Chipgenius and I can surely give you a link to a manufacturer tool for at least one of them with which you can zero out the serial number.

@ilko_t
Today I was able to reach the Autoit forum link, so you have something theoretically capable of generating the hashes and you are keeping it for yourself?

jaclaz

This post has been edited by jaclaz: 13 November 2009 - 09:39 AM

[ilko_t]

jaclaz, on Nov 13 2009, 07:37 AM, said:

@ilko_t
Today I was able to reach the Autoit forum link, so you have something theoretically capable of generating the hashes and you are keeping it for yourself?

jaclaz

Not sure which one you have in mind, but is it the attachmen t in post #97?
http://www.msfn.org/board/solved-usbstick-...p;view=findpost
http://www.msfn.org/board/index.php?act=at...st&id=26992

And BTW- not only theoretically capable, practically as well

[jaclaz]

ilko_t, on Nov 13 2009, 05:47 PM, said:

jaclaz, on Nov 13 2009, 07:37 AM, said:

@ilko_t
Today I was able to reach the Autoit forum link, so you have something theoretically capable of generating the hashes and you are keeping it for yourself?

jaclaz

Not sure which one you have in mind, but is it the attachmen t in post #97?
http://www.msfn.org/board/solved-usbstick-...p;view=findpost
http://www.msfn.org/board/index.php?act=at...st&id=26992

And BTW- not only theoretically capable, practically as well

I must have read it wrongly, in there, which is here :
http://www.msfn.org/board/solved-usbstick-...80-page-96.html
(stoopid board software is still working, or better NOT working on a random base)
You said you had a C program which you couldn't translate to AutoIT.
On the AutoIt board you posted an AutoIt program:
http://www.autoitscript.com/forum/index.ph...104426&st=8

that seemingly has glitches in it, as seen in later posts.

So I will try to rephrase :
Have you got now a fully working AutoIt program?
If yes, you should also have understood the algorithm behind it, which is what I would be interested in, NOT into the CODE (C or AutoIt or whatever) that implements the algorithm.

jaclaz

This post has been edited by jaclaz: 13 November 2009 - 12:39 PM

[ilko_t]

Say string="abs"

1. Uppercase it
2. Put the ASCII code for each symbol in an array
3. For each element in the array calculate $iHash = 37 * $iHash + $Array[$i]
4. Output is the hexadecimal value of the modal of the positive(abs) result of (314159269 * $iHash) divided by 1000000007.

Apparently in the above calculations C value types uint and int should be used to store results in, or values get different presentation. Still can't quite figure out this part, despite all the reading the last couple of days.