Macster Posted September 1, 2009 Author Share Posted September 1, 2009 (edited) @cdobScript output:call === MontedDevices as readcall === convert MountedDevices, adjust RomovableMediawarning: MountedDevices does not contain RemovabledMedia#7fixing S: to RemovableMedia#7copying 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 2E: DVDF: Partition 3 (Hidden)U: ThumbThanks 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 September 1, 2009 by Macster Link to comment Share on other sites More sharing options...
cdob Posted September 1, 2009 Share Posted September 1, 2009 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 assumedS: 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 More sharing options...
ilko_t Posted September 2, 2009 Share Posted September 2, 2009 ...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 assumedT: RemovableMedia adjusted: counter set to zero: RemovableMedia#?&*&0S: RemovableMedia adjusted: counter set to zero and 7 set: RemovableMedia#7&*&0Thanks 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 More sharing options...
cdob Posted September 3, 2009 Share Posted September 3, 2009 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 More sharing options...
ilko_t Posted September 3, 2009 Share Posted September 3, 2009 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 More sharing options...
jaclaz Posted September 4, 2009 Share Posted September 4, 2009 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 Link to comment Share on other sites More sharing options...
ilko_t Posted November 9, 2009 Share Posted November 9, 2009 ...I seek and prefer a ParentIDPrefix explanation still...Here is a bit more information:http://bbs.driverdevelop.com/read.php?tid=96099http://translate.google.com/translate?hl=e...GGGL_en___GB229The first three, said the device inside the device tree in the whole level. He was in the third graderoot是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 bridgeHere is good explanation of the device tree:http://msdn.microsoft.com/en-us/library/aa489660.aspxOsronline 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=97About 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=104426Can 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 More sharing options...
jaclaz Posted November 11, 2009 Share Posted November 11, 2009 I seem not able to connect to the autoit place. And of course I do not understand the C code. Anyway keep going. jaclaz Link to comment Share on other sites More sharing options...
cdob Posted November 11, 2009 Share Posted November 11, 2009 (edited) 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&*&0Driver stack: 1 ntoskrnl.exe, hal.dll2&daba3ff&0 acpi.sys3 pci.sys - no ParentIdPrefix4&11cdd0bd&0 usbehci.sys5&38c8e674&0 usbhub.sys6 usbstor.sys - no ParentIdPrefix7&776bc3a&1 disk.sysNext 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&*&0However 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 November 11, 2009 by cdob Link to comment Share on other sites More sharing options...
ilko_t Posted November 12, 2009 Share Posted November 12, 2009 You've got a lovely knowledgeable crystal ball, I have no doubts Link to comment Share on other sites More sharing options...
jaclaz Posted November 13, 2009 Share Posted November 13, 2009 (edited) 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_tToday 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 Edited November 13, 2009 by jaclaz Link to comment Share on other sites More sharing options...
ilko_t Posted November 13, 2009 Share Posted November 13, 2009 @ilko_tToday 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? jaclazNot 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=findposthttp://www.msfn.org/board/index.php?act=at...st&id=26992And BTW- not only theoretically capable, practically as well Link to comment Share on other sites More sharing options...
jaclaz Posted November 13, 2009 Share Posted November 13, 2009 (edited) @ilko_tToday 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? jaclazNot 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=findposthttp://www.msfn.org/board/index.php?act=at...st&id=26992And 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=8that 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 November 13, 2009 by jaclaz Link to comment Share on other sites More sharing options...
ilko_t Posted November 14, 2009 Share Posted November 14, 2009 Say string="abs"1. Uppercase it2. Put the ASCII code for each symbol in an array3. 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 More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now