Jump to content

ParentIDPrefix 8& vs. "normal" 7&


Macster

Recommended Posts

@cdob

Script output:

call === MontedDevices as read

call === convert MountedDevices, adjust RomovableMedia

warning: MountedDevices does not contain RemovabledMedia#7

fixing S: to RemovableMedia#7

copying file to the XP install .~bt forder.

Well I got U: (with NTFS) this time. Interesting?

Cause my current topology was (before running the XP install):

C: Partition 1 (XP)

D: Partition 2

E: DVD

F: Partition 3 (Hidden)

U: Thumb

Thanks to the file that ilko_T gave me.

I am wondering if it has anything to do with the ambient topology. Whether the install is reading some of the registry (or the partition tables on the HD) as far as the placing of particians and such? Cause before I was getting D: for the thumb when the thumb was already set at D:.

Edit:

Well I tried changing the drive reference to the USB to Z: in Windows, reran the script, and it still came up with U: during the install, so it would appear that it is fixed.

Edited by Macster
Link to comment
Share on other sites


Well I got U: (with NTFS) this time. Interesting?

Thanks, U: was expected at your machine.

Remember ParentIdPrefix 8&35debb9c&0 is used at current running windows and new installed windows.

U: MountedDevices as read from current running windows, XP style assumed

S: should work at cases, if a change is required.

Compare http://www.msfn.org/board/http-msfn-org-bo...p;view=findpost

Link to comment
Share on other sites

...

Added 2:

Overall there is a new approach, set up to three letters. Thanks to ilko_t.

U: MountedDevices as read from current running windows, XP style assumed

T: RemovableMedia adjusted: counter set to zero: RemovableMedia#?&*&0

S: RemovableMedia adjusted: counter set to zero and 7 set: RemovableMedia#7&*&0

Thanks cdob.

Maybe add W: with 8&*&0 for cases when stick is prepared on machine using 7&*&0, and installed on machine using 8&*&0.

Link to comment
Share on other sites

Maybe add W: with 8&*&0 for cases when stick is prepared on machine using 7&*&0, and installed on machine using 8&*&0.

Actually I dislike the current work around, that's not a nice solution.

I seek and prefer a ParentIDPrefix explanation still.

I addition searching the net I found further hints:

a digital camera and MP3 player use ParentIDPrefix&6.

Even some memory sticks seems to use ParentIDPrefix&6.

Do we support install XP from a digital camera?

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

I realy, realy like to get a ParentIDPrefix explanation.

I prefer to get some further custom reposts. Sorry, therefore I won't add W: currently.

Any clean solution is highly welcome, has to support running Winwos 2000, XP, Vista and 7.

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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: :whistle::

  • U:
  • V:
  • W:

Yes :thumbup , 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. ;)

:P

jaclaz

Link to comment
Share on other sites

  • 2 months later...
...I seek and prefer a ParentIDPrefix explanation still...

Here is a bit more information:

http://bbs.driverdevelop.com/read.php?tid=96099

http://translate.google.com/translate?hl=e...GGGL_en___GB229

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.microsoft.com/en-us/library/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.com/article.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.autoitscript.com/forum/index.php?showtopic=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?

Link to comment
Share on other sites

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 :whistle:

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&*&*.

Edited by cdob
Link to comment
Share on other sites

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? :w00t:

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

@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? :w00t:

jaclaz

Not sure which one you have in mind, but is it the attachmen t in post #97? :whistle:

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 ;)

Link to comment
Share on other sites

@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? :w00t:

jaclaz

Not sure which one you have in mind, but is it the attachmen t in post #97? :whistle:

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

Edited by jaclaz
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...