none
Metro Mail Office 365 provider RRS feed

  • Question

  • Hi, I'm trying to pull apart the data transmitted via xmlhttp.

    It appears like wbxml, but its not consistent.  I see multiple wbxml start markers:  03 01 6A. Is it something else?

    WBXML Version 1.3, Unknown Public Id and UTF-8 Marker Found at index

    but then there is a 00 00 FF 45 47.  where the second 00 is I'd expect a code page id.  What is the following FF?

    How can I decode this?  Where is the spec for it?  Nothing in here: http://interoperability.blob.core.windows.net/files/MS-ASWBXML/[MS-ASWBXML].pdf

    Seems to match up.

    The first guid for example: 8DF153AF-CCCB-43DB-AE20-703A920E96C4 What does it mean?  trying to use the Code Page for the bit masked 0x49 (content) gives me 9  None of the code pages with 9 seem to have anything that would be a guid?

    Thanks

    00000000h: 13 7E 53 74 61 72 74 4F 75 74 6C 6F 6F 6B 46 72 ; .~StartOutlookFr
    00000010h: 61 6D 65 7E 2F 01 00 00 22 00 00 00 51 01 00 00 ; ame~/..."...Q...
    00000020h: 03 01 6A 00 00 FF 45 47 C2 00 01 46 C2 01 01 48 ; ..j..ÿEGÂ..FÂ..H
    00000030h: 03 73 79 6E 63 00 01 49 03 38 44 46 31 35 33 41 ; .sync..I.8DF153A
    00000040h: 46 2D 43 43 43 42 2D 34 33 44 42 2D 41 45 32 30 ; F-CCCB-43DB-AE20
    00000050h: 2D 37 30 33 41 39 32 30 45 39 36 43 34 00 01 4D ; -703A920E96C4..M
    00000060h: C2 04 01 4E C2 59 01 4F C2 81 7C 01 59 03 36 35 ; Â..NÂY.O|.Y.65
    00000070h: 45 30 37 33 42 33 2D 41 30 46 30 2D 30 30 30 30 ; E073B3-A0F0-0000
    00000080h: 2D 38 39 34 32 2D 46 32 36 35 46 30 41 30 44 33 ; -8942-F265F0A0D3
    00000090h: 30 31 00 01 16 58 03 31 36 2E 30 2E 38 38 32 37 ; 01...X.16.0.8827
    000000a0h: 2E 32 31 38 35 00 01 5A 03 57 49 4E 44 4F 57 53 ; .2185..Z.WINDOWS
    000000b0h: 00 01 5B 03 57 69 6E 64 6F 77 73 2E 44 65 73 6B ; ..[.Windows.Desk
    000000c0h: 74 6F 70 00 01 5F 03 32 30 35 32 30 36 34 37 30 ; top.._.205206470
    000000d0h: 34 00 01 60 61 62 C2 01 01 63 03 34 46 41 45 43 ; 4..`abÂ..c.4FAEC
    000000e0h: 41 41 36 2D 38 44 37 35 2D 34 35 43 35 2D 39 38 ; AA6-8D75-45C5-98
    000000f0h: 32 36 2D 42 39 41 43 36 46 38 44 33 42 32 37 00 ; 26-B9AC6F8D3B27.
    00000100h: 01 01 61 62 C2 02 01 63 03 74 72 75 65 00 01 01 ; ..abÂ..c.true...
    00000110h: 61 62 C2 03 01 63 03 30 00 01 01 61 62 C2 06 01 ; abÂ..c.0...abÂ..
    00000120h: 63 03 74 72 75 65 00 01 01 61 62 C2 04 01 63 03 ; c.true...abÂ..c.
    00000130h: 74 72 75 65 00 01 01 61 62 C2 08 01 63 03 74 72 ; true...abÂ..c.tr
    00000140h: 75 65 00 01 01 01 66 C2 04 01 65 C2 00 01 01 03 ; ue....fÂ..eÂ....
    00000150h: 01 6A 00 00 0A 66 67 C2 0C 01 67 C2 07 01 67 C2 ; .j...fgÂ..gÂ..gÂ
    00000160h: 81 07 01 67 C2 81 08 01 67 C2 0B 01 67 C2 05 01 ; ..g..gÂ..gÂ..
    00000170h: 01 11 7E 45 6E 64 4F 75 74 6C 6F 6F 6B 46 72 61 ; ..~EndOutlookFra
    00000180h: 6D 65 7E                                        ; me~

    Monday, February 12, 2018 5:26 PM

All replies

  • Hi,

    The MS-AS* ActiveSync specifications do not address Office365 implementations. Only on-premise Exchange scenarios are documented. As such, the Open Specifications Support team does not provide direct support for using the MS-AS* specifications in the Office365 scenario. However a member of the Open Specifications Support team can attempt a comparison to an on-premise installation of Exchange Server and see whether or not the behavior you are seeing in the Office365 scenario is also occurring in the on-premise scenario, and if so we can investigate the issue fully.

    Thanks,

    Edgar

    Monday, February 12, 2018 9:45 PM
    Moderator
  • Hello chupperDG:

    I'm looking into your following query and will get back.

    >>>'The first guid for example: 8DF153AF-CCCB-43DB-AE20-703A920E96C4 What does it mean?  trying to use the Code Page for the bit masked 0x49 (content) gives me 9  None of the code pages with 9 seem to have anything that would be a guid?'

    Thanks


    Tarun Chopra | Escalation Engineer | Open Specifications Support Team

    Tuesday, February 13, 2018 7:19 AM
  • It seems if u base64 decode the auth token that fiddler gave you from earlier request / response you'll see the guids.  I'm starting to think the first section of possible wbxml is more comm / session info than app payload.  But even the second section of wbml (after the second 03 01 6A) doesn't make sense.

    00000140h: 75 65 00 01 01 01 66 C2 04 01 65 C2 00 01 01 03 ; ue....fÂ..eÂ....
    00000150h: 01 6A 00 00 0A 66 67 C2 0C 01 67 C2 07 01 67 C2 ; .j...fgÂ..gÂ..gÂ

    The string table is 00, but then, what is the next 00?  Is the first code page 0A ResolveRecipients ?

    That code page doesn't have anything that high (0x66 - content bit) == 0x26)  (it stops at 1D)

    Thanks


    • Edited by chupperDG Tuesday, February 13, 2018 1:36 PM
    Tuesday, February 13, 2018 12:24 PM
  • Edgar, are you saying that MS is using an API that it doesn't share with the rest of the world?

    The docs state the following is used, and I can see the exchange provider, google, yahoo all use it

    https://docs.microsoft.com/en-us/uwp/api/windows.applicationmodel.email.emailmailbox

    However the office365 provider is not using it, it is using what looks like proprietary invocations to msxmlhttp via these StartOutlookFrame and pseudo wbxml 


    Tuesday, February 13, 2018 12:29 PM
  • Hello chupperDG: 

    I decoded the byte stream '03 01 6A 00 00 0A 66' and can see that we are getting an unknown tag. I reviewed exchange server along with Metro Mail source code and they both have no definition for tag '0x26'.

    <?xml version="1.0" encoding="utf-8"?>
    <resolverecipients:UNKNOWN_TAG_26 xmlns:resolverecipients="ResolveRecipients:" />

    Kindly collect 0365 (refer following link and section 'OWA\ECP method') logs along with fiddler trace and share with us for further analysis. Please send logs to my attention at  - dochelp at Microsoft.com

    Thanks


    Tarun Chopra | Escalation Engineer | Open Specifications Support Team

    Tuesday, February 13, 2018 6:22 PM
  • How do I enable the logging specified in that link against office365?  Isn't that all MS managed?

    Is it even exchange?

    BTW, I'm sure you can repro this in house.  It seems like it is never the spec'd format.

    Thanks

    Wednesday, February 14, 2018 10:13 AM
  • Hello chupperDG - 

    Kindly drop me an email; dochelp at Microsoft.com; and I will walk you through the steps to collect the logs as stated in the link above. Logging has to be initiated by the user and logs will be sent as an email attachment to your inbox.

    We need to analyze both fiddler and 0365 logs to ensure that we are parsing the bytes correctly. As mentioned earlier; I reviewed both exchange server and metro app code and didn't find 0x26 tag for this code page.

    Will look forward to your email to assist further. Once we resolve the issue; we will circle back and update this forum thread with our findings.

    Thanks 


    Tarun Chopra | Escalation Engineer | Open Specifications Support Team

    Wednesday, February 14, 2018 4:53 PM
  • Hi chupperDG,

    I've been trying to implement a client capable of communicating with Office 365 with wbxml. As you also noticed, it really is not using any standard code pages, making it hard to understand what is going on. This is what I've discovered so far.

    Both requests and responses are using the same "standard". What you've presented here is an OutlookFrame. A response may have one or more of these. That is, a response may have more than one OutlookFrame, although there are no indication for that in http headers or in the actual response.

    The frame starts with 0x13 followed by an ascii string ~StartOutlookFrame~ and ends with 0x11 followed by ~EndOutlookFrame~

    The frame can have one or two wbxml entries, which I call blocks. Right after the ~StartOutlookFrame~ there are three little-endia uint32 values indicating the size of the first wbxml block (2F 01 00 00 = 0x012F = 303), the size of the second block (0x22 = 34) and the sum of block sizes (0x0151 = 337). So, the first wbxml block starts at position 0x20 with the normal wbxml start marker, and ends at 0x14E with the last close-tag token 0x01. And the next block starts right after that ending at 0x16F.

    Those wbxml blocks are just normal wbxml files, although, as the codepages and tokens are not revealed you need to guess what those tokens (tags) are. So, a lot of reverse-engineering is needed. 

    I've added some functionality to my AADInternals module (released late Jan 2020) to "parse" these OutlookFrames. As I've not even tried to understand the tags used in these frames, I've simply created the xml tags on-the-fly. The tags are in the form _XX_YY where the XX equals the code page and YY the tag.

    The biggest difference to the "normal" ActiveSync format is that EXT_1 (0xC1) and EXT_2 (0xC2) extensions are used. How these extensions should be handled is not defined nor documented anywhere. Based on my research, EXT_1 is used for UTF-8 strings. The EXT_2 was a bit trickier, as it contains multi-byte encoded integers. However, these integers (in responses) can be so long that they don't fit in any int variable. Therefore, all EXT_2 are simply encoded as hex values. CData can contain binary stuff, so I've Base64 encoded them.

    Here is the human readable xml from your OutlookFrame (I added the frames, frame, and block -tags):

    <frames>
    	<frame>
    		<block>
    			<_FF_05 xmlns="_FF">
    				<_FF_07 xmlns="_FF">
    					<EXT_2>00</EXT_2>
    				</_FF_07>
    				<_FF_06 xmlns="_FF">
    					<EXT_2>01</EXT_2>
    				</_FF_06>
    				<_FF_08 xmlns="_FF">sync</_FF_08>
    				<_FF_09 xmlns="_FF">8DF153AF-CCCB-43DB-AE20-703A920E96C4</_FF_09>
    				<_FF_0D xmlns="_FF">
    					<EXT_2>04</EXT_2>
    				</_FF_0D>
    				<_FF_0E xmlns="_FF">
    					<EXT_2>59</EXT_2>
    				</_FF_0E>
    				<_FF_0F xmlns="_FF">
    					<EXT_2>00FC</EXT_2>
    				</_FF_0F>
    				<_FF_19 xmlns="_FF">65E073B3-A0F0-0000-8942-F265F0A0D301</_FF_19>
    				<_FF_16 xmlns="_FF"/>
    				<_FF_18 xmlns="_FF">16.0.8827.2185</_FF_18>
    				<_FF_1A xmlns="_FF">WINDOWS</_FF_1A>
    				<_FF_1B xmlns="_FF">Windows.Desktop</_FF_1B>
    				<_FF_1F xmlns="_FF">2052064704</_FF_1F>
    				<_FF_20 xmlns="_FF">
    					<_FF_21 xmlns="_FF">
    						<_FF_22 xmlns="_FF">
    							<EXT_2>01</EXT_2>
    						</_FF_22>
    						<_FF_23 xmlns="_FF">4FAECAA6-8D75-45C5-9826-B9AC6F8D3B27</_FF_23>
    					</_FF_21>
    					<_FF_21 xmlns="_FF">
    						<_FF_22 xmlns="_FF">
    							<EXT_2>02</EXT_2>
    						</_FF_22>
    						<_FF_23 xmlns="_FF">true</_FF_23>
    					</_FF_21>
    					<_FF_21 xmlns="_FF">
    						<_FF_22 xmlns="_FF">
    							<EXT_2>03</EXT_2>
    						</_FF_22>
    						<_FF_23 xmlns="_FF">0</_FF_23>
    					</_FF_21>
    					<_FF_21 xmlns="_FF">
    						<_FF_22 xmlns="_FF">
    							<EXT_2>06</EXT_2>
    						</_FF_22>
    						<_FF_23 xmlns="_FF">true</_FF_23>
    					</_FF_21>
    					<_FF_21 xmlns="_FF">
    						<_FF_22 xmlns="_FF">
    							<EXT_2>04</EXT_2>
    						</_FF_22>
    						<_FF_23 xmlns="_FF">true</_FF_23>
    					</_FF_21>
    					<_FF_21 xmlns="_FF">
    						<_FF_22 xmlns="_FF">
    							<EXT_2>08</EXT_2>
    						</_FF_22>
    						<_FF_23 xmlns="_FF">true</_FF_23>
    					</_FF_21>
    				</_FF_20>
    				<_FF_26 xmlns="_FF">
    					<EXT_2>04</EXT_2>
    				</_FF_26>
    				<_FF_25 xmlns="_FF">
    					<EXT_2>00</EXT_2>
    				</_FF_25>
    			</_FF_05>
    		</block>
    		<block>
    			<_0A_26 xmlns="_0A">
    				<_0A_27 xmlns="_0A">
    					<EXT_2>0C</EXT_2>
    				</_0A_27>
    				<_0A_27 xmlns="_0A">
    					<EXT_2>07</EXT_2>
    				</_0A_27>
    				<_0A_27 xmlns="_0A">
    					<EXT_2>0087</EXT_2>
    				</_0A_27>
    				<_0A_27 xmlns="_0A">
    					<EXT_2>0088</EXT_2>
    				</_0A_27>
    				<_0A_27 xmlns="_0A">
    					<EXT_2>0B</EXT_2>
    				</_0A_27>
    				<_0A_27 xmlns="_0A">
    					<EXT_2>05</EXT_2>
    				</_0A_27>
    			</_0A_26>
    		</block>
    	</frame>
    </frames>

    The first GUID <_FF_09> is the deviceId of the client (see the list of mobile clients from the mailbox). <_FF_0E> is the commandID, which is same than sent in http header X-CommandId, but I don't know what this particular command (0x59) is. <_FF_19> seems to be just a random GUID, probably just a requestId. <_FF_18> is the client version and <_FF_1A> the operating system version (with Android devices 5.0.2 or similar). <_FF_1B> is the client type. The tag <_FF_20> contains a number of settings and values I've no idea what they are.

    Hope that this helped a bit.

    I'm also interested to hear which client you've been using, as the OutlookFrame indicates some Windows based client? I thought that this format is only used with mobile clients (Android and iOS).

    BR,

    Nestori


    • Edited by Nestori Monday, January 6, 2020 9:06 AM EXT_2 integers are large only on responses
    Monday, January 6, 2020 9:02 AM