Windows 8.1 Build 9600.16610 DISM Now Can Work On ESD

Love you man.

 

Thanks, now i can use these cmds on there own.

Code:

mkdir c:\esd

cd c:\

esddecrypt install.esd

dism /get-wiminfo /wimfile:c:\install.esd

dism /export-image /sourceimagefile:c:\install.esd /sourceIndex:4 /destinationimagefile:c:\esd\install.esd /compress:maximum

Tested and working.

 

Latest wimlib-imagex matches and slightly faster than dism in converting esd2wim:

Spoiler

Code:

32-bit:

wimlib
15:48:00.59 - 16:03:48.80 ~ 16m

dism 9860.0
15:30:07.76 - 15:47:01.84 ~ 17m

dism 9600.17031
16:06:33.28 - 16:23:15.90 ~ 17m

===

64-bit:

wimlib
20:06:24.02 - 20:19:19.90 ~ 13m

dism 9860.0
20:19:54.60 - 20:34:03.48 ~ 14m

dism 9600.17031
19:51:13.03 - 20:05:24.17 ~ 14m

do you think it's better to use it in our script, or stick with dism?

 

I don't know man. I have no idea if there are pre-requisites for it like there are for dism.
It seems like it would be better to use wimlib-imagex if it works on all the OS versions.

 

You need to login to view this posts content.

 

You need to login to view this posts content.

 

I think supporting decryption of ESD is not so hard and it's technically possible.
But I cannot guess whether it's suitable to implement in wimlib.
Please ask the author directly if you think it's worth doing so.

As for the decryption in the Store upgrade process, it's the setup
program itself that decrypts the downloaded ESDs.
As far as I know, neither dism nor wimgapi has such transparent support
for encrypted ESDs in itself.

 

thanks guys for the update

 

Hi,

I've updated my post with wimlib 1.7.3 official release.
I don't think there is much difference from BETA but I think it's better to compile from officially released source.

Thanks

 

Btw

.....

 

You need to login to view this posts content.

 

I'm not sure about what he meant by "only whole streams can be encrypted" and about whether there are some restrictions.
But, as synchronicity says, it seems any regions except for WIM header and embedded xml/integrity table can be encrypted in any length so you should examine the whole of the file beforehand to decrypt it, I think.
Also the RSA key (and even the encryption algorithm itself) can be changed every new release so it would be better to keep decryption and other functions separated for maximum flexibility.
What I thought of when Atari800XL asked me was adding the decryption function to wimlib as a new command like:

Code:

wimlib-imagex decrypt foo.esd --crypto-key=<key> --crypto-algo=<aes256 or win8>

and I didn't take "on-the-fly decryption" into account.

And to the latter question, the algorithm is standard AES-256 with NULL initial vector for current Win8/Win10TP ESDs.
The AES session key is placed within embedded xml as an RSA encrypted, and then base64 encoded string.
The RSA key for decrypting the session key itself is in another xml (i.e. products.xml on the MS upgrade notification site).
But I don't know the purpose of the encryption, either. It actually makes using the original ESDs a bit harder but all information that is needed to reproduce the plaintext is easily accessible to everyone

I hope this could be helpful for him.

Thanks

 

Found a compiler similar to GImageX. Might appeal to some users. I haven't tested it yet.
Use at your own risk.

Windows command line compiler for wimlib-imagex 1.7.3

****://reboot.pro/files/file/485-wimlib-imagex-clc-beta/

 

This seals the deal i guess

as s1ave77 said, the current status is ideal in my opinion

thanks qad for giving us the opportunity to play with ESDs

 

How did you get this Base64 string? (the BwIAAAC...)

 

It's from here: ht*ps://wscont.apps.microsoft.com/winstore/OSUpgradeNotification/products.xml

 

You need to login to view this posts content.

 

is there correct key work? please share to me ,thank you very much,